Re: Handle infinite recursion in logical replication setup

Peter Smith <smithpb2250@gmail.com>

From: Peter Smith <smithpb2250@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-05-02T00:18:59Z
Lists: pgsql-hackers
Thanks for updating the patches for all my prior feedback.

For v12* I have only minor feedback for the docs.

======
V12-0001

no comments

======
V12-0002

1. Commit message

In another thread using the terminology "multi-master" seems to be
causing some problems. Maybe you should choose different wording in
this commit message to avoid having the same problems?

~~~

2. doc/src/sgml/logical-replication.sgml

These are all similar minor wording suggestions to split the sentences.
Wording: ", here copy_data is specified as XXX ..." -> ". Use
copy_data specified as XXX ..."

Also:
Wording: "... to subscribe the changes from nodeXXX..."
-> "... to subscribe to the changes from nodeXXX... " (add "to")
-> "... to subscribe to nodeXXX."  (or I preferred just remove the
whole "changes" part)

2a.
Create a subscription in node3 to subscribe the changes from node1,
here copy_data is specified as force so that the existing table data
is copied during initial sync:

SUGGESTION
Create a subscription in node3 to subscribe to node1. Use copy_data
specified as force so that the existing table data is copied during
initial sync:

2b.
Create a subscription in node1 to subscribe the changes fromnode3,
here copy_data is specified as force so that the existing table data
is copied during initial sync:

SUGGESTION
Create a subscription in node1 to subscribe to node3. Use copy_data
specified as force so that the existing table data is copied during
initial sync:

2c.
Create a subscription in node2 to subscribe the changes from node3,
here copy_data is specified as force so that the existing table data
is copied during initial sync:

SUGGESTION
Create a subscription in node2 to subscribe to node3. Use copy_data
specified as force so that the existing table data is copied during
initial sync:

2d.
Create a subscription in node3 to subscribe the changes from node1,
here copy_data is specified as force when creating a subscription to
node1 so that the existing table data is copied during initial sync:

SUGGESTION
Create a subscription in node3 to subscribe to node1. Use copy_data
specified as force when creating a subscription to node1 so that the
existing table data is copied during initial sync:

2e.
Create a subscription in node3 to subscribe the changes from node2,
here copy_data is specified as off as the initial table data would
have been copied in the earlier step:

SUGGESTION (this one has a bit more re-wording than the others)
Create a subscription in node3 to subscribe to node2. Use copy_data
specified as off because the initial table data would have been
already copied in the previous step:

~~~

3. doc/src/sgml/logical-replication.sgml

31.11.2. Adding new node when there is no data in any of the nodes
31.11.3. Adding new node when data is present in the existing nodes
31.11.4. Adding new node when data is present in the new node

Minor change to the above heading?

Wording: "Adding new node ..." -> "Adding a new node ..."

------
[1] https://www.postgresql.org/message-id/flat/CAHut%2BPuwRAoWY9pz%3DEubps3ooQCOBFiYPU9Yi%3DVB-U%2ByORU7OA%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia



Commits

  1. Improved CREATE SUBSCRIPTION message for clarity

  2. Fix the test case introduced by commit 8756930190.

  3. Raise a warning if there is a possibility of data from multiple origins.

  4. Add wait_for_subscription_sync for TAP tests.

  5. Bump catversion for commit d8cd0c6c95c0120168df93aae095df4e0682a08a.

  6. Allow users to skip logical replication of data having origin.

  7. Improve two comments related to a boolean DefElem's value

  8. doc: Fix man page whitespace issues