From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Handle infinite recursion in logical replication setup |
Date: | 2022-06-01 17:57:36 |
Message-ID: | CALDaNm2Uz=bBOH-Zqr=GMe9nB5iGNVrqafd1_jYimqC5QS237g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 27, 2022 at 2:08 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Fri, May 27, 2022 at 5:04 PM shiy(dot)fnst(at)fujitsu(dot)com
> <shiy(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> > On Wed, May 25, 2022 7:55 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > >
> > > The attached v16 patch has the changes for the same.
> > >
> >
> > Thanks for updating the patch.
> >
> > Some comments for the document in 0002 patch.
> >
> > 1.
> > + <para>
> > + Lock the required tables in <literal>node1</literal> and
> > + <literal>node2</literal> till the setup is completed.
> > + </para>
> > +
> > + <para>
> > + Create a publication in <literal>node1</literal>:
> > +<programlisting>
> > +node1=# CREATE PUBLICATION pub_node1 FOR TABLE t1;
> > +CREATE PUBLICATION
> > +</programlisting></para>
> >
> > If the table is locked in the very beginning, we will not be able to create the
> > publication (because the locks have conflict). Maybe we should switch the order
> > of creating publication and locking tables here.
> >
>
> I agree. It seems some of the locking instructions in the earlier
> sections 31.11.1 - 31.11.4 are contradictory to the later "generic"
> steps given in "31.11.5. Generic steps to add a new node to the
> existing set of nodes". I'm assuming the generic steps are the
> "correct" steps
>
> e.g. generic steps say get the lock on new node tables AFTER the
> publication of new node.
> e.g. generic steps say do NOT get a table lock on the node one you are
> (first) joining to.
Yes, the generic steps are correct. modified
> ~~~
>
> Furthermore, the generic steps are describing attaching a new N+1th
> node to some (1 ... N) other nodes.
>
> So I think in the TWO-node case (section 31.11.1) node2 should be
> treated as the "new" node that you are attaching to the "first" node1.
> IMO the section 31.11.1 example should be reversed so that it obeys
> the "generic" pattern.
> e.g. It should be doing the CREATE PUBLICATION pub_node2 first (since
> that is the "new" node)
In generic steps we mention the publication must be created in a new
node and we don't say about the existing nodes, because the
publication would be existing already. I feel the existing order of
publication creation in the TWO-node case (section 31.11.1) is ok.
Thanks for the comments, the v17 patch attached at [1] has the changes
for the same.
[1] - https://www.postgresql.org/message-id/CALDaNm1rMihO7daiFyLdxkqArrC%2BdtM61oPXc-XrTYBYnJg3nw%40mail.gmail.com
Regards,
Vignesh
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2022-06-01 17:58:20 | Re: silence compiler warning in brin.c |
Previous Message | Tom Lane | 2022-06-01 17:55:52 | Re: silence compiler warning in brin.c |