From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com> |
Cc: | Japin Li <japinli(at)hotmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Forget close an open relation in ReorderBufferProcessTXN() |
Date: | 2021-05-19 02:29:38 |
Message-ID: | CAA4eK1+NQXTXR7M9m6NU1-9ENHz837c1oTssbYbNjicR-pfoiw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 18, 2021 at 5:29 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, May 18, 2021 at 1:29 PM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Monday, May 17, 2021 6:45 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > We allow taking locks on system catalogs, so why prohibit
> > > user_catalog_tables? However, I agree that if we want plugins to acquire the
> > > lock on user_catalog_tables then we should either prohibit decoding of such
> > > relations or do something else to avoid deadlock hazards.
> > OK.
> >
> > Although we have not concluded the range of logical decoding of user_catalog_table
> > (like we should exclude TRUNCATE command only or all operations on that type of table),
> > I'm worried that disallowing the logical decoding of user_catalog_table produces
> > the deadlock still. It's because disabling it by itself does not affect the
> > lock taken by TRUNCATE command. What I have in mind is an example below.
> >
> > (1) plugin (e.g. pgoutput) is designed to take a lock on user_catalog_table.
> > (2) logical replication is set up in synchronous mode.
> > (3) TRUNCATE command takes an access exclusive lock on the user_catalog_table.
> > (4) This time, we don't do anything for the TRUNCATE decoding.
> > (5) the plugin tries to take a lock on the truncated table
> > but, it can't due to the lock by TRUNCATE command.
> >
>
> If you skip decoding of truncate then we won't invoke plugin API so
> step 5 will be skipped.
>
I think you were right here even if skip step-4, the plugin might take
a lock on user_catalog_table for something else. I am not sure but I
think we should prohibit truncate on user_catalog_tables as we
prohibit truncate on system catalog tables (see below [1]) if we want
plugin to lock them, otherwise, as you said it might lead to deadlock.
For the matter, I think we should once check all other operations
where we can take an exclusive lock on [user]_catalog_table, say
Cluster command, and compare the behavior of same on system catalog
tables.
[1]
postgres=# truncate pg_class;
ERROR: permission denied: "pg_class" is a system catalog
postgres=# cluster pg_class;
ERROR: there is no previously clustered index for table "pg_class"
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-05-19 02:33:09 | Re: Forget close an open relation in ReorderBufferProcessTXN() |
Previous Message | Peter Geoghegan | 2021-05-19 01:59:49 | Re: MaxOffsetNumber for Table AMs |