Re: Handle infinite recursion in logical replication setup - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Handle infinite recursion in logical replication setup
Date
Msg-id CAHut+PtinkWsPPA8RN2jWTuhTSYj0sbRT9A7_ZeM0ezKNNSa6g@mail.gmail.com
Whole thread Raw
In response to RE: Handle infinite recursion in logical replication setup  ("shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>)
Responses Re: Handle infinite recursion in logical replication setup
List pgsql-hackers
On Mon, Aug 1, 2022 at 3:27 PM shiy.fnst@fujitsu.com
<shiy.fnst@fujitsu.com> wrote:
>
> On Fri, Jul 29, 2022 1:22 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> >
> > Thanks for the comments, the attached v41 patch has the changes for the
> > same.
> >
>
> Thanks for updating the patch.
>
> I wonder in the case that the publisher uses PG15 (or before), subscriber uses
> PG16, should we have this check (check if publication tables were also
> subscribing from other publishers)? In this case, even if origin=none is
> specified, it doesn't work because the publisher doesn't filter the origin. So
> maybe we don't need the check for initial sync. Thoughts?
>

IIUC for the scenario you've described (subscription origin=none and
publisher < PG16) the subscriber can end up getting extra data they
did not want, right?

So instead of just "don't need the check", maybe this combination
should throw ERROR, or at least a log a WARNING?

------
KInd Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Inconvenience of pg_read_binary_file()