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

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: 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 06:23:29
Message-ID: CAA4eK1KwMv+SvXBnrSwSmNPuCEmCUbedxLt9ViGNc3FCLZoPOg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 20, 2021 at 9:28 AM osumi(dot)takamichi(at)fujitsu(dot)com
<osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
>
> 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."
>

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-06-20 07:38:50 Re: pgbench logging broken by time logic changes
Previous Message Thomas Munro 2021-06-20 04:52:32 Re: pgbench logging broken by time logic changes