Re: Handle infinite recursion in logical replication setup

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Handle infinite recursion in logical replication setup
Дата
Msg-id CAA4eK1+cQ-qC8cSrajO5ULhi1Qn-8o7iWKyknZn9M5dJbjau8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Handle infinite recursion in logical replication setup  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: Handle infinite recursion in logical replication setup  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers
On Mon, Aug 1, 2022 at 1:32 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> 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?
>

Yes, because publishers won't have 'filtering based on origin' functionality.

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

I am not sure if doing anything (ERROR or WARNING) would make sense
because anyway later during replication there won't be any filtering.

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Inconvenience of pg_read_binary_file()
Следующее
От: Japin Li
Дата:
Сообщение: Typo in pg_db_role_setting.h