Re: Handle infinite recursion in logical replication setup
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
Euler Taveira <euler@eulerto.com>, Euler Taveira <euler@timbira.com.br>, Peter Smith <smithpb2250@gmail.com>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-01T17:49:03Z
Lists: pgsql-hackers
On Fri, May 27, 2022 at 7:54 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > 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. I have changed it to origin = local/any. 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
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