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
|
Список | 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 по дате отправления: