Re: Handle infinite recursion in logical replication setup - Mailing list pgsql-hackers

From vignesh C
Subject Re: Handle infinite recursion in logical replication setup
Date
Msg-id CALDaNm1h-9UNi_Jo_K+PK34tXBmV7fhj5C_nB8YzGA9rmUwHEA@mail.gmail.com
Whole thread Raw
In response to RE: Handle infinite recursion in logical replication setup  ("shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>)
Responses Re: Handle infinite recursion in logical replication setup
RE: Handle infinite recursion in logical replication setup
List pgsql-hackers
On Mon, Jun 20, 2022 at 9:22 AM shiy.fnst@fujitsu.com
<shiy.fnst@fujitsu.com> wrote:
>
> On Thu, Jun 16, 2022 6:18 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > Thanks for the comments, the attached v21 patch has the changes for the
> > same.
> >
>
> Thanks for updating the patch. Here are some comments.
>
> 0002 patch
> ==============
> 1.
> +          publisher to only send changes that originated locally. Setting
> +          <literal>origin</literal> to <literal>any</literal> means that that
> +          the publisher sends any changes regardless of their origin. The
> +          default is <literal>any</literal>.
>
> It seems there's a redundant "that" at the end of second line.

Modified

> 2.
> +    <row>
> +      <entry role="catalog_table_entry"><para role="column_definition">
> +       <structfield>suborigin</structfield> <type>text</type>
> +      </para>
> +      <para>
> +       Possible origin values are <literal>local</literal> or
> +       <literal>any</literal>. The default is <literal>any</literal>.
> +       If <literal>local</literal>, the subscription will request the publisher
> +       to only send changes that originated locally. If <literal>any</literal>
> +       the publisher sends any changes regardless of their origin.
> +      </para></entry>
> +     </row>.
>
> A comma can be added after "If any".

Modified

> 3.
> @@ -4589,6 +4598,8 @@ dumpSubscription(Archive *fout, const SubscriptionInfo *subinfo)
>         if (strcmp(subinfo->subdisableonerr, "t") == 0)
>                 appendPQExpBufferStr(query, ", disable_on_error = true");
>
> +       appendPQExpBuffer(query, ", origin = %s", subinfo->suborigin);
> +
>         if (strcmp(subinfo->subsynccommit, "off") != 0)
>                 appendPQExpBuffer(query, ", synchronous_commit = %s", fmtId(subinfo->subsynccommit));
>
> Do we need to append anything if it's the default value ("any")? I saw that some
> other parameters, they will be appended only if they are not the default value.

Modified

> 0003 patch
> ==============
> 1.
> in create_subscription.sgml:
>           (You cannot combine setting <literal>connect</literal>
>           to <literal>false</literal> with
>           setting <literal>create_slot</literal>, <literal>enabled</literal>,
>           or <literal>copy_data</literal> to <literal>true</literal>.)
>
> In this description about "connect" parameter in CREATE SUBSCIPTION document,
> maybe it would be better to change "copy_data to true" to "copy_data to
> true/force".

Modified

> 2.
> +       appendStringInfoString(&cmd,
> +                                                  "SELECT DISTINCT N.nspname AS schemaname,\n"
> +                                                  "                            C.relname AS tablename,\n"
> +                                                  "                            PS.srrelid as replicated\n"
> +                                                  "FROM pg_publication P,\n"
> +                                                  "     LATERAL pg_get_publication_tables(P.pubname) GPT\n"
> +                                                  "     LEFT JOIN pg_subscription_rel PS ON (GPT.relid =
PS.srrelid),\n"
> +                                                  "     pg_class C JOIN pg_namespace N ON (N.oid =
C.relnamespace)\n"
> +                                                  "WHERE C.oid = GPT.relid AND P.pubname IN (");
>
> "PS.srrelid as replicated" can be modified to "PS.srrelid AS replicated".
>
> Besides, I think we can filter out the tables which are not subscribing data in
> this SQL statement, then later processing can be simplified.
>
> Something like:
> SELECT DISTINCT N.nspname AS schemaname,
>                                 C.relname AS tablename
> FROM pg_publication P,
>          LATERAL pg_get_publication_tables(P.pubname) GPT
>          LEFT JOIN pg_subscription_rel PS ON (GPT.relid = PS.srrelid),
>          pg_class C JOIN pg_namespace N ON (N.oid = C.relnamespace)
> WHERE C.oid = GPT.relid AND P.pubname IN ('pa') AND PS.srrelid IS NOT NULL;

Modified

> 0004 patch
> ==============
> 1. Generic steps for adding a new node to an existing set of nodes
>
> +    Step-2: Lock the required tables of the new node in EXCLUSIVE mode until
> +    the setup is complete. (This lock is necessary to prevent any modifications
>
> +    Step-4. Lock the required tables of the existing nodes except the first node
> +    in EXCLUSIVE mode until the setup is complete. (This lock is necessary to
>
> Should "in EXCLUSIVE mode" be modified to "in <literal>EXCLUSIVE</literal>
> mode"?

Modified

> 2. Generic steps for adding a new node to an existing set of nodes
>
> +    data. There is no need to lock the required tables on
> +    <literal>node1</literal> because any data changes made will be synchronized
> +    while creating the subscription with <literal>copy_data = force</literal>).
>
> I think it would be better to say "on the first node" here, instead of "node1",
> because in this section, node1 is not mentioned before.

Modified

Thanks for the comment, the v22 patch attached has the changes for the same.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [BUG] Panic due to incorrect missingContrecPtr after promotion
Next
From: vignesh C
Date:
Subject: Re: Handle infinite recursion in logical replication setup