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>,
Euler Taveira <euler@eulerto.com>, Euler Taveira <euler@timbira.com.br>
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-05-27T02:24:02Z
Lists: pgsql-hackers
On Wed, Apr 6, 2022 at 9:36 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > 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. > I still don't have a very clear answer for the usability aspect but it seems this was discussed in PGCon-Unconference [1] (Section: Origin filter) and there also it was suggested to allow users to specify multiple origin names. So, probably Ashutosh's idea makes sense and we should use "origin = publisher/any or origin=local/any". Among these, I would prefer later. Note: I don't have email-id of Julian Markwort who has raised this topic in Unconference. Euler, if you know, it might be better to add him here, so that he is aware of what is going on and share his opinion if he wishes to. [1] - https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference -- With Regards, Amit Kapila.
Commits
-
Improved CREATE SUBSCRIPTION message for clarity
- 1e7ca1189ccc 17.0 landed
- 842b65905046 16.0 landed
-
Fix the test case introduced by commit 8756930190.
- 032465157347 16.0 landed
-
Raise a warning if there is a possibility of data from multiple origins.
- 875693019053 16.0 landed
-
Add wait_for_subscription_sync for TAP tests.
- 0c20dd33db16 16.0 cited
-
Bump catversion for commit d8cd0c6c95c0120168df93aae095df4e0682a08a.
- 5f858dd3bebd 16.0 cited
-
Allow users to skip logical replication of data having origin.
- 366283961ac0 16.0 landed
-
Improve two comments related to a boolean DefElem's value
- 8445f5a21d40 16.0 cited
-
doc: Fix man page whitespace issues
- d7ab2a9a3c0a 15.0 cited