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 CAA4eK1+co4hRncuXHx1=46DeqkbyYvJAp9BoiZoC7i=geRcsGw@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 Thu, Jun 17, 2021 at 8:41 AM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Wednesday, June 16, 2021 7:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Mon, Jun 14, 2021 at 5:33 PM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@fujitsu.com> wrote:
> > >
> > > On  Friday, June 11, 2021 2:13 PM  vignesh C <vignesh21@gmail.com>
> > wrote:
> > >
> > > Attached the patch-set that addressed those two comments.
> > >
> >
> > Few minor comments:
> > 1.
> > +      <listitem>
> > +       <para>
> > +        Clustering <structname>pg_class</structname> in a transaction.
> >
> > Can we change above to: Perform <command>CLUSTER</command> on
> > <structname>pg_class</structname> in a transaction.
> Looks better.
>
> >
> > 2.
> > +      <listitem>
> > +       <para>
> > +        Executing <command>TRUNCATE</command> on user catalog
> > table
> > in a transaction.
> > +       </para>
> >
> > Square brackets are missing for user.
> Thanks for catching it. You are right.
>
>
> > 3.
> > +    <indexterm>
> > +     <primary>Overview</primary>
> > +    </indexterm>
> > ..
> > ..
> > +    <indexterm>
> > +     <primary>Caveats</primary>
> > +    </indexterm>
> >
> > Why are these required when we already have titles? I have seen other places
> > in the docs where we use titles for Overview and Caveats but they didn't have
> > similar usage.
> Sorry, this was a mistake. We didn't need those sections.
>
>
> > 4.
> > <para>
> > +        Performing <command>PREPARE TRANSACTION</command>
> > after
> > <command>LOCK</command>
> > +        command on <structname>pg_class</structname> and logical
> > decoding of published
> > +        table.
> >
> > Can we change above to: <command>PREPARE
> > TRANSACTION</command> after <command>LOCK</command>
> > command on <structname>pg_class</structname> and allow logical
> > decoding of two-phase transactions.
> >
> > 5.
> > +       <para>
> > +        Clustering <structname>pg_trigger</structname> and decoding
> > <command>PREPARE
> > +        TRANSACTION</command>, if any published table have a trigger
> > and any
> > +        operations that will be decoded are conducted.
> > +       </para>
> >
> > Can we change above to: <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.
> Yeah, I needed the nuance to turn on logical decoding of two-phase transactions...
> Your above suggestions are much tidier and more accurate than mine.
> I agree with your all suggestions.
>

Pushed!

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Fix for segfault in logical replication on master
Next
From: Nitin Jadhav
Date:
Subject: Re: when the startup process doesn't