Re: Handle infinite recursion in logical replication setup

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>
Subject: Re: Handle infinite recursion in logical replication setup
Date: 2022-07-14 13:12:11
Message-ID: CAFiTN-tcSvk8kE3x0u+8V5rfoXO-Uy5-5AX_jXSB1ZjodfPdtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 14 Jul 2022 at 6:34 PM, vignesh C <vignesh21(at)gmail(dot)com> wrote:

> On Thu, Jul 14, 2022 at 11:26 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com>
> wrote:
> >
> > On Wed, Jul 13, 2022 at 4:49 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com>
> wrote:
> > >
> > > On Tue, Jul 12, 2022 at 2:58 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > > >
> > > > On Tue, Jul 12, 2022 at 9:51 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> > >
> > > I find one thing confusing about this patch. Basically, this has two
> > > option 'local' and 'any', so I would assume that all the local server
> > > changes should be covered under the 'local' but now if we set some
> > > origin using 'select pg_replication_origin_session_setup('aa');' then
> > > changes from that session will be ignored because it has an origin id.
> > > I think actually the name is creating confusion, because by local it
> > > seems like a change which originated locally and the document is also
> > > specifying the same.
> > >
> > > + If <literal>local</literal>, the subscription will request the
> publisher
> > > + to only send changes that originated locally. If
> <literal>any</literal>,
> > >
> > > I think if we want to keep the option local then we should look up all
> > > the origin in the replication origin catalog and identify whether it
> > > is a local origin id or remote origin id and based on that filter out
> > > the changes.
> >
> > On the other hand if we are interested in receiving the changes which
> > are generated without any origin then I think we should change 'local'
> > to 'none' and then in future we can provide a new option which can
> > send the changes generated by all the local origin? I think other
> > than this the patch LGTM.
>
> Thanks for the comment. The attached v33 patch has the changes to
> specify origin as 'none' instead of 'local' which will not publish the
> data having any origin.

I think the ‘none’ might have problem from expand ability pov? what if in
future we support the actual origin name and than what none mean? no origin
or origin name none? Should we just give origin name empty name ‘’? Or is
there some other issue?

>

Dilip

> --
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2022-07-14 14:02:58 Re: Problem about postponing gathering partial paths for topmost scan/join rel
Previous Message vignesh C 2022-07-14 13:04:02 Re: Handle infinite recursion in logical replication setup