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 OSBPR01MB4888AEDC4866414BB77C22ABED359@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: locking [user] catalog tables vs 2pc vs logical rep  (vignesh C <vignesh21@gmail.com>)
Responses RE: locking [user] catalog tables vs 2pc vs logical rep
List pgsql-hackers
On Thursday, June 10, 2021 1:14 PM vignesh C <vignesh21@gmail.com>
> On Wed, Jun 9, 2021 at 12:03 PM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> >
> > On Wednesday, June 9, 2021 12:06 PM Amit Kapila
> <amit.kapila16@gmail.com> wrote:
> > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C <vignesh21@gmail.com> wrote:
> > > >
> > > > Thanks for the updated patch.
> > > >
> > > > I have few comments:
> > > > 1) Should we list the actual system tables like
> > > > pg_class,pg_trigger, etc instead of any other catalog table?
> > > > User has issued an explicit LOCK on pg_class (or any other catalog
> > > > table)
> > > >
> > >
> > > I think the way it is mentioned is okay. We don't need to specify
> > > other catalog tables.
> > Okay.
> >
> >
> > > > 2) Here This means deadlock, after this we mention deadlock again
> > > > for each of the examples, we can remove it if redundant.
> > > > This can happen in the following ways:
> > I think this sentence works to notify that commands described below
> > are major scenarios naturally, to the readers. Then, I don't want to remove
> it.
> >
> > If you somehow feel that the descriptions are redundant, how about
> > unifying all listitems as nouns. like below ?
> >
> > * An explicit <command>LOCK</command> on
> > <structname>pg_class</structname> (or any other catalog table) in a
> > transaction
> > * Reordering <structname>pg_class</structname> by
> > <command>CLUSTER</command> command in a transaction
> > * Executing <command>TRUNCATE</command> on user_catalog_table
> >
> 
> This looks good to me. Keep the 2PC documentation patch also on the same
> lines.
Yeah, of course. Thanks for your confirmation.


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Next
From: Amit Kapila
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety