Re: row filtering for logical replication

On Wed, Dec 15, 2021 at 1:52 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> On Wed, Dec 15, 2021 at 5:25 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > > "If a subscriber is a pre-15 version, the initial table
> > > synchronization won't use row filters even if they are defined in the
> > > publisher."
> > >
> > > Won't this lead to data inconsistencies or errors that otherwise
> > > wouldn't happen?
> > >
> >
> > How? The subscribers will get all the initial data.
> >
>
> But couldn't getting all the initial data (i.e. not filtering) break
> the rules used by the old/new row processing (see v46-0003 patch)?
> Those rules effectively assume rows have been previously published
> with filtering.
> So, for example, for the following case for UPDATE:
> old-row (no match) new row (match) -> INSERT
> the old-row check (no match) infers that the old row was never
> published, but that row could in fact have been in the initial
> unfiltered rows, so in that case an INSERT gets erroneously published
> instead of an UPDATE, doesn't it?
>

But this can happen even when both the publisher and subscriber are
from v15, say if the user defines filter at some later point or change
the filter conditions by Alter Publication. So, not sure if we need to
invent something new for this.

> > > Should such subscriptions be allowed?
> > >
> >
> > I am not sure what you have in mind here? How can we change the
> > already released code pre-15 for this new feature?
> >
>
> I was thinking such subscription requests could be rejected by the
> server, based on the subscriber version and whether the publications
> use filtering etc.
>

Normally, the client sends some parameters to the server like
(streaming, two_pc, etc.) based on which server can take such
decisions. We may need to include some such thing which I am not sure
is required for this particular case especially because that can
happen otherwise as well.

--
With Regards,
Amit Kapila.