Re: Handle infinite recursion in logical replication setup

On Mon, Aug 29, 2022 at 8:24 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Fri, Aug 26, 2022 at 9:52 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > IMHO, since the user has specifically asked for origin=NONE but we do
> > not have any way to detect the origin during initial sync so I think
> > this could be documented and we can also issue the WARNING. So that
> > users notice that part and carefully set up the replication. OTOH, I
> > do not think that giving an error is very inconvenient because we are
> > already providing a new option "origin=NONE" so along with that lets
> > force the user to choose between copy_data=off or copy_data=force and
> > with that, there is no scope for mistakes.
>

Initially, I also thought that giving an error should be okay in this
case but later multiple people voted against that idea primarily
because we won't be able to detect whether the initial sync data
contains data from multiple origins. Consider that even though the
publisher is subscribed to some other publisher but it may not have
gotten any data from it by the time we try to subscribe from it. Also,
one might have removed the subscription that led to data from multiple
origins on the publisher, in this case, may be one can say that we can
consider that the data is now owned by the publisher but I am not
sure. So, considering this, I think giving a WARNING and documenting
how to set up replication correctly sounds like a reasonable way
forward.

> Since Jonathan also had suggested to throw a warning as in [1] and
> Hou-san also had suggested to throw a warning as in [2],
>

Agreed that multiple seems to be in favor of that approach. We can
always promote it to ERROR later if others and or users felt so.

--
With Regards,
Amit Kapila.