RE: locking [user] catalog tables vs 2pc vs logical rep

From: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>
Cc: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
Subject: RE: locking [user] catalog tables vs 2pc vs logical rep
Date: 2021-06-20 03:58:15
Message-ID: OSBPR01MB4888F0A6D137ACE1B1CBBB37ED0B9@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday, June 19, 2021 6:51 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jun 18, 2021 at 2:25 PM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Friday, June 18, 2021 11:41 AM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-06-20 04:52:32 Re: pgbench logging broken by time logic changes
Previous Message Alvaro Herrera 2021-06-20 03:18:35 Re: pgbench logging broken by time logic changes