Re: Handle infinite recursion in logical replication setup

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Peter Smith <smithpb2250(at)gmail(dot)com>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Handle infinite recursion in logical replication setup
Date: 2022-06-01 17:49:03
Message-ID: CALDaNm2A2wpxMY1FOUPYXSuVoCbuF-Wgdq+d3towjjivjVd0rQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 27, 2022 at 7:54 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Apr 6, 2022 at 9:36 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Tue, Apr 5, 2022 at 7:06 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > >
> > > On Tue, Apr 5, 2022 at 6:21 AM Peter Smith <smithpb2250(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2022-06-01 17:53:15 Re: Handle infinite recursion in logical replication setup
Previous Message vignesh C 2022-06-01 17:48:07 Re: Handle infinite recursion in logical replication setup