RE: locking [user] catalog tables vs 2pc vs logical rep - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: locking [user] catalog tables vs 2pc vs logical rep
Date
Msg-id OSBPR01MB4888F0A6D137ACE1B1CBBB37ED0B9@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: locking [user] catalog tables vs 2pc vs logical rep  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: locking [user] catalog tables vs 2pc vs logical rep
List pgsql-hackers
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."


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pgbench logging broken by time logic changes
Next
From: Thomas Munro
Date:
Subject: Re: pgbench logging broken by time logic changes