Re: row filtering for logical replication - Mailing list pgsql-hackers
From | Peter Smith |
---|---|
Subject | Re: row filtering for logical replication |
Date | |
Msg-id | CAHut+PtB01N=LdGHw0z1Vw53eYDy7rDWAw3Wp+J_x1CO4pBwew@mail.gmail.com Whole thread Raw |
In response to | RE: row filtering for logical replication ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
List | pgsql-hackers |
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
pgsql-hackers by date: