Re: Handle infinite recursion in logical replication setup

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>, vignesh C <vignesh21@gmail.com>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-06T04:06:52Z
Lists: pgsql-hackers
On Tue, Apr 5, 2022 at 7:06 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Apr 5, 2022 at 6:21 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > Below are some other name ideas. Maybe they are not improvements, but
> > it might help other people to come up with something better.
> >
> > subscribe_publocal_only = true/false
> > origin = pub_only/any
> > adjacent_data_only = true/false
> > direct_subscriptions_only = true/false
> > ...
>
> FWIW, The subscriber wants "changes originated on publisher". From
> that angle origin = publisher/any looks attractive. It also leaves
> open the possibility that the subscriber may ask changes from a set of
> origins or even non-publisher origins.
>

So, how are you imagining extending it for multiple origins? I think
we can have multiple origins data on a node when there are multiple
subscriptions pointing to the different or same node. The origin names
are internally generated names but are present in
pg_replication_origin. So, are we going to ask the user to check that
table and specify it as an option? But, note, that the user may not be
able to immediately recognize which origin data is useful for her.
Surely, with some help or advice in docs, she may be able to identify
it but that doesn't seem so straightforward. The other point is that
such an option won't be applicable for initial sync as we can't
differentiate between data from a local or remote node.

-- 
With Regards,
Amit Kapila.



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