Re: Handle infinite recursion in logical replication setup

Peter Smith <smithpb2250@gmail.com>

From: Peter Smith <smithpb2250@gmail.com>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: vignesh C <vignesh21@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>
Date: 2022-07-26T02:18:05Z
Lists: pgsql-hackers
On Tue, Jul 26, 2022 at 11:43 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
...
> That said, this introduces a new restriction for this particular
> scenario that doesn't exist on other scenarios. Instead, I would
> advocate we document how to correctly set up the two-way replication
> scenario (which we have a draft!), document the warnings around the
> conflicts, perhaps include Vignesh's instructions on how to remediate a
> conflict on initial sync, and consider throwing a WARNING as you suggested.
>
> Thoughts?

Perhaps a WARNING can be useful if the SUBSCRIPTION was created with
enabled=false because then the user still has a chance to reconsider,
but otherwise, I don't see what good a warning does if the potentially
harmful initial copy is going to proceed anyway; isn't that like
putting a warning sign at the bottom of a cliff?

------
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