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: 'vignesh C' <vignesh21(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(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-11 01:27:40
Message-ID: OSBPR01MB48883AE7D8F74331EAAFBBA4ED349@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, June 10, 2021 1:30 PM I wrote:
> On Thursday, June 10, 2021 1:14 PM vignesh C <vignesh21(at)gmail(dot)com>
> > On Wed, Jun 9, 2021 at 12:03 PM osumi(dot)takamichi(at)fujitsu(dot)com
> > <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> > >
> > > On Wednesday, June 9, 2021 12:06 PM Amit Kapila
> > <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C <vignesh21(at)gmail(dot)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.
Hi, attached the updated patch-set.

I've conducted some updates.

(1) Added commit messages for all patches
(2) Sorted out the descriptions of listitem to make them look uniform
(3) Removed PG11-specific patch and unified the patch from PG11 to PG13,
which will keep the documents cleanliness for future back-patching, if any.

(4) Removed unnecessary space after 'id'

In v04, there was an unneeded space like below. Fixed.
In the same logicaldecoding.sgml doc, there is no space after 'id' for sec2.

+ <sect2 id ="logicaldecoding-synchronous-caveats">
+ <title>Caveats</title>

(5) Fixed the reference accurately by replacing link tag with xref tag.

In v04, I let the reference be inaccurate, because the linkend points to the caveats
but the link word was "Synchronous Replication Support for Logical Decoding".

+ [user] catalog tables exclusively. To avoid this users must refrain from
+ having locks on catalog tables (e.g. explicit <command>LOCK</command> command)
+ in such transactions.
+ (See <link linkend="logicaldecoding-synchronous-caveats">Synchronous
+ Replication Support for Logical Decoding</link> for the details.)

So, in v05, I've fixed this to point out the caveats directly.

+ [user] catalog tables exclusively. To avoid this users must refrain from
+ having locks on catalog tables (e.g. explicit <command>LOCK</command> command)
+ in such transactions.
+ (See <xref linkend="logicaldecoding-synchronous-caveats"/> for the details.)

Kindly have a look at the patch-set.

Best Regards,
Takamichi Osumi

Attachment Content-Type Size
HEAD_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 4.7 KB
HEAD_with_2PC_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 2.5 KB
PG10_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 4.6 KB
PG11_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 4.6 KB
PG12_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 4.6 KB
PG13_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 4.6 KB
PG96_deadlock_documentation_of_logical_decoding_v05.patch application/octet-stream 4.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-06-11 01:37:47 Re: Logical replication keepalive flood
Previous Message Jeff Davis 2021-06-11 01:26:56 Replication protocol doc fix