Re: locking [user] catalog tables vs 2pc vs logical rep - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: locking [user] catalog tables vs 2pc vs logical rep |
Date | |
Msg-id | CAA4eK1KwMv+SvXBnrSwSmNPuCEmCUbedxLt9ViGNc3FCLZoPOg@mail.gmail.com Whole thread Raw |
In response to | RE: locking [user] catalog tables vs 2pc vs logical rep ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>) |
Responses |
RE: locking [user] catalog tables vs 2pc vs logical rep
|
List | pgsql-hackers |
On Sun, Jun 20, 2021 at 9:28 AM osumi.takamichi@fujitsu.com <osumi.takamichi@fujitsu.com> wrote: > > On Saturday, June 19, 2021 6:51 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Jun 18, 2021 at 2:25 PM osumi.takamichi@fujitsu.com > > <osumi.takamichi@fujitsu.com> wrote: > > > > > > On Friday, June 18, 2021 11:41 AM osumi.takamichi@fujitsu.com > > <osumi.takamichi@fujitsu.com> wrote: > > > > > > Simon, I appreciate your suggestions and yes, if the user catalog > > > > table is referenced by the output plugin, it can be another cause of the > > deadlock. > > > > > > > > I'm going to post the patch for the those two changes, accordingly. > > > Hi, I've made the patch-set to cover the discussion above for all-supported > > versions. > > > Please have a look at those. > > > > I have slightly modified your patch, see if the attached looks okay to you? This > > is just a HEAD patch, I'll modify the back-branch patches accordingly. > Thank you for updating the patch. > The patch becomes much better. Yet, I have one suggestion. > > * doc/src/sgml/logicaldecoding.sgml > <itemizedlist> > <listitem> > <para> > Issuing an explicit <command>LOCK</command> on <structname>pg_class</structname> > - (or any other catalog table) in a transaction. > + (or any other [user] catalog table) in a transaction. > </para> > </listitem> > > <listitem> > <para> > - Perform <command>CLUSTER</command> on <structname>pg_class</structname> in > - a transaction. > + Perform <command>CLUSTER</command> on <structname>pg_class</structname> (or any > + other [user] catalog table) in a transaction. > </para> > </listitem> > > <listitem> > <para> > <command>PREPARE TRANSACTION</command> after <command>LOCK</command> command > - on <structname>pg_class</structname> and allow logical decoding of two-phase > - transactions. > + on <structname>pg_class</structname> (or any other [user] catalog table) and > + allow logical decoding of two-phase transactions. > </para> > </listitem> > > <listitem> > <para> > <command>PREPARE TRANSACTION</command> after <command>CLUSTER</command> > - command on <structname>pg_trigger</structname> and allow logical decoding of > - two-phase transactions. This will lead to deadlock only when published table > - have a trigger. > + command on <structname>pg_trigger</structname> (or any other [user] catalog > + table) and allow logical decoding of two-phase transactions. This will lead > + to deadlock only when published table have a trigger. > > > Now we have the four paren supplementary descriptions, > not to make users miss any other [user] catalog tables. > Because of this, the built output html gives me some redundant > impression, for that parts. Accordingly, couldn't we move them > to outside of the itemizedlist section in a simple manner ? > > For example, to insert a sentence below the list, > after removing the paren descriptions in the listitem, which says > "Note that those commands that can cause deadlock apply to not only > explicitly indicated system catalog tables above but also any other [user] catalog table." > Sounds reasonable to me. /but also any other/but also to any other/, to seems to be missing in the above line. Kindly send an update patch. -- With Regards, Amit Kapila.
pgsql-hackers by date: