RE: locking [user] catalog tables vs 2pc vs logical rep
Takamichi Osumi (Fujitsu) <osumi.takamichi@fujitsu.com>
From: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
To: 'vignesh C' <vignesh21@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Markus Wanner <markus.wanner@enterprisedb.com>
Date: 2021-06-11T01:27:40Z
Lists: pgsql-hackers
Attachments
- HEAD_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
- HEAD_with_2PC_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
- PG10_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
- PG11_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
- PG12_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
- PG13_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
- PG96_deadlock_documentation_of_logical_decoding_v05.patch (application/octet-stream) patch v5
On Thursday, June 10, 2021 1:30 PM I wrote: > 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. 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
Commits
-
Doc: Update caveats in synchronous logical replication.
- 4be39ef9cbc5 9.6.23 landed
- f365151a5392 10.18 landed
- e00e5db22d79 11.13 landed
- a73bd49c69e1 12.8 landed
- 7a4ecefe9d77 13.4 landed
- c66fb78ebb4f 14.0 landed
-
Document a few caveats in synchronous logical replication.
- acdb523cb642 9.6.23 landed
- ff33be61f212 10.18 landed
- 5a456034b84e 11.13 landed
- 9f7bba2629cf 13.4 landed
- eb231dbd80d2 12.8 landed
- 3cb828dbe260 14.0 landed
-
Update the docs and comments for decoding of prepared xacts.
- b4e3dc7fd420 14.0 landed
-
Allow decoding at prepare time in ReorderBuffer.
- a271a1b50e9b 14.0 cited
-
Documentation for logical decoding.
- 49c0864d7ef5 9.4.0 cited