Re: Handle infinite recursion in logical replication setup

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.

Regards,
Vignesh