Re: Handle infinite recursion in logical replication setup

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.

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