Re: row filtering for logical replication

On Thu, Dec 9, 2021 at 1:37 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, December 8, 2021 7:52 PM Ajin Cherian <itsajin@gmail.com>
> > On Tue, Dec 7, 2021 at 5:36 PM Peter Smith <smithpb2250@gmail.com> wrote:
> > >
> > > We were mid-way putting together the next v45* when your latest
> > > attachment was posted over the weekend. So we will proceed with our
> > > original plan to post our v45* (tomorrow).
> > >
> > > After v45* is posted we will pause to find what are all the
> > > differences between your unified patch and our v45* patch set. Our
> > > intention is to integrate as many improvements as possible from your
> > > changes into the v46* etc that will follow tomorrow’s v45*. On some
> > > points, we will most likely need further discussion.
> >
> >
> > Posting an update for review comments, using contributions majorly from
> > Peter Smith.
> > I've also included changes based on Euler's combined patch, specially changes
> > to documentation and test cases.
> > I have left out Hou-san's 0005, in this patch-set. Hou-san will provide a rebased
> > update based on this.
> >
> > This patch addresses the following review comments:
>
> Hi,
>
> Thanks for updating the patch.
> I noticed a possible issue.
>
> +                               /* Check row filter. */
> +                               if (!pgoutput_row_filter(data, relation, oldtuple, NULL, relentry))
> +                                       break;
> +
> +                               maybe_send_schema(ctx, change, relation, relentry);
> +
>                                 /* Switch relation if publishing via root. */
>                                 if (relentry->publish_as_relid != RelationGetRelid(relation))
>                                 {
> ...
>                                         /* Convert tuple if needed. */
>                                         if (relentry->map)
>                                                 tuple = execute_attr_map_tuple(tuple, relentry->map);
>
> Currently, we execute the row filter before converting the tuple, I think it could
> get wrong result if we are executing a parent table's row filter and the column
> order of the parent table is different from the child table. For example:
>
> ----
> create table parent(a int primary key, b int) partition by range (a);
> create table child (b int, a int primary key);
> alter table parent attach partition child default;
> create publication pub for table parent where(a>10) with(PUBLISH_VIA_PARTITION_ROOT);
>
> The column number of 'a' is '1' in filter expression while column 'a' is the
> second one in the original tuple. I think we might need to execute the filter
> expression after converting.
>

Fixed in v46* [1]

------
[1] https://www.postgresql.org/message-id/CAHut%2BPtoxjo6hpDFTya6WYH-zdspKQ5j%2BwZHBRc6EZkAkq7Nfw%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia