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 OSBPR01MB48884E232F654A88C6E050DCED369@OSBPR01MB4888.jpnprd01.prod.outlook.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>)
List pgsql-hackers
On Tuesday, June 8, 2021 5:04 PM I wrote:
> On Monday, June 7, 2021 6:22 PM Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> > On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila <amit.kapila16@gmail.com>
> > wrote:
> > >
> > > One more comment is that for HEAD, first just create a patch with
> > > synchronous replication-related doc changes and then write a
> > > separate patch for prepared transactions.
> >
> > I noticed that docs for "Synchronous replication support for Logical Decoding"
> > has been introduced by commit
> > 49c0864d7ef5227faa24f903902db90e5c9d5d69 which goes till 9.6. So, I
> > think you need to create a patch for 9.6 as well unless one of the
> > existing patches already applies in 9.6.
> OK. I could apply PG10's patch to 9.6.
> Also, I've made a separate patch for 2PC description.
> 
> On the other hand, I need to mention that there are some gaps to cause failures
> to apply patches between supported versions.
> (e.g. applying a patch for HEAD to stable PG13 fails)
I scrutinized this POV and checked the gaps between supported versions.
In terms of the section where the patch want to fix,
there are only 2 major gaps between PG10 and PG11 - [1]
and between PG13 and HEAD - [2]. In other words,
the patch-set should be 4 types.

* patch for HEAD
* additional patch for HEAD based on 2PC patch-set
* patch for from PG11 to PG13
* patch for PG9.6 and PG10

> To address the gaps between the versions, I needed to conduct some manual
> fixes.
> Therefore, please note that the content of patch between PG12 and PG13 are
> almost same like PG9.6 and PG10, but, I prepared independent patches for
> HEAD and PG11, in order to make those applied in a comfortable manner.
Therefore, I was wrong.
I didn't need the specific independent patch for PG11.
I'll fix the patch-set accordingly in the next version.


[1] how we finish xref tag is different between PG10 and PG11

--- logicaldecoding.sgml_PG11   2021-06-09 04:38:18.214163527 +0000
+++ logicaldecoding.sgml_PG10   2021-06-09 04:37:50.533163527 +0000
@@ -730,9 +698,9 @@
     replication</link> solutions with the same user interface as synchronous
     replication for <link linkend="streaming-replication">streaming
     replication</link>.  To do this, the streaming replication interface
-    (see <xref linkend="logicaldecoding-walsender"/>) must be used to stream out
+    (see <xref linkend="logicaldecoding-walsender">) must be used to stream out
     data. Clients have to send <literal>Standby status update (F)</literal>
-    (see <xref linkend="protocol-replication"/>) messages, just like streaming
+    (see <xref linkend="protocol-replication">) messages, just like streaming
     replication clients do.
    </para>

[2] in HEAD, we have a new sect1 after "Synchronous Replication Support for Logical Decoding"

--- logicaldecoding.sgml_PG13   2021-06-09 05:10:34.927163527 +0000
+++ logicaldecoding.sgml_HEAD   2021-06-09 05:08:12.810163527 +0000
@@ -747,4 +1089,177 @@
      </para>
    </note>
   </sect1>
+
+  <sect1 id="logicaldecoding-streaming">
+   <title>Streaming of Large Transactions for Logical Decoding</title>
+
+   <para>
+    The basic output plugin callbacks (e.g., <function>begin_cb</function>,
...


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Race condition in recovery?
Next
From: Tomas Vondra
Date:
Subject: Re: Fdw batch insert error out when set batch_size > 65535