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 CALDaNm01kX44F4=Nk9paNiLAPs1Vjb+WxUkOdsgnDoZ8HYW=6g@mail.gmail.com
Whole thread Raw
In response to Re: Handle infinite recursion in logical replication setup  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Handle infinite recursion in logical replication setup
RE: Handle infinite recursion in logical replication setup
Re: Handle infinite recursion in logical replication setup
Re: Handle infinite recursion in logical replication setup
List pgsql-hackers
On Sat, Jul 2, 2022 at 12:12 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jun 30, 2022 at 9:40 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Thu, Jun 30, 2022 at 9:17 AM shiy.fnst@fujitsu.com
> > <shiy.fnst@fujitsu.com> wrote:
> > >
>
> The first patch that adds a test case for existing functionality looks
> good to me and I'll push that early next week (by Tuesday) unless
> there are more comments on it.
>
> Few minor comments on 0002
> ========================
> 1.
> + /* FIXME: 150000 should be changed to 160000 later for PG16. */
> + if (options->proto.logical.origin &&
> + PQserverVersion(conn->streamConn) >= 150000)
> + appendStringInfo(&cmd, ", origin '%s'",
> + options->proto.logical.origin);
>
> ...
> ...
> + /* FIXME: 150000 should be changed to 160000 later for PG16. */
> + if (fout->remoteVersion >= 150000)
> + appendPQExpBufferStr(query, " s.suborigin\n");
> + else
> + appendPQExpBuffer(query, " '%s' AS suborigin\n", LOGICALREP_ORIGIN_ANY);
> ...
> ...
> + /* FIXME: 150000 should be changed to 160000 later for PG16 */
> + if (pset.sversion >= 150000)
> + appendPQExpBuffer(&buf,
> +   ", suborigin AS \"%s\"\n",
> +   gettext_noop("Origin"));
>
> All these should now change to 16.

Modified

> 2.
> /* ALTER SUBSCRIPTION <name> SET ( */
>   else if (HeadMatches("ALTER", "SUBSCRIPTION", MatchAny) &&
> TailMatches("SET", "("))
> - COMPLETE_WITH("binary", "slot_name", "streaming",
> "synchronous_commit", "disable_on_error");
> + COMPLETE_WITH("binary", "origin", "slot_name", "streaming",
> "synchronous_commit", "disable_on_error");
>   /* ALTER SUBSCRIPTION <name> SKIP ( */
>   else if (HeadMatches("ALTER", "SUBSCRIPTION", MatchAny) &&
> TailMatches("SKIP", "("))
>   COMPLETE_WITH("lsn");
> @@ -3152,7 +3152,7 @@ psql_completion(const char *text, int start, int end)
>   /* Complete "CREATE SUBSCRIPTION <name> ...  WITH ( <opt>" */
>   else if (HeadMatches("CREATE", "SUBSCRIPTION") && TailMatches("WITH", "("))
>   COMPLETE_WITH("binary", "connect", "copy_data", "create_slot",
> -   "enabled", "slot_name", "streaming",
> +   "enabled", "origin", "slot_name", "streaming",
>     "synchronous_commit", "two_phase", "disable_on_error");
>
> Why do you choose to add a new option in-between other parameters
> instead of at the end which we normally do? The one possible reason I
> can think of is that all the parameters at the end are boolean so you
> want to add this before those but then why before slot_name, and again
> I don't see such a rule being followed for other parameters.

I was not sure if it should be maintained in alphabetical order,
anyway since the last option "disable_on_error" is at the end, I have
changed it to the end.

Thanks for the comments, the attached v27 patch has the changes for the same.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PSA: Autoconf has risen from the dead
Next
From: Nathan Bossart
Date:
Subject: Re: O(n) tasks cause lengthy startups and checkpoints