On Fri, Mar 11, 2022 at 7:26 AM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > But this does not address tablesync.c :-( That still copies everything, > because it decides to sync both rels (test_pub_part_1, test_pub_part_2), > with it's row filter. On older releases this would fail, because we'd > start two workers: >
Yeah, this is because of the existing problem where we sync both rels instead of one. We have fixed some similar existing problems earlier. Hou-San has reported a similar case in another email [1]. > > But I find this really weird - I think it's reasonable to expect the > sync to produce the same result as if the data was inserted and > replicated, and this just violates that. > > Shouldn't tablesync calculate a list of relations in a way that prevents > such duplicate / overlapping syncs? > Yes, I think it is better to fix it separately than to fix it along with row filter or column filter work. > In any case, this sync issue looks > entirely unrelated to the column filtering patch. > Right. [1] - https://www.postgresql.org/message-id/OS0PR01MB5716DC2982CC735FDE388804940B9%40OS0PR01MB5716.jpnprd01.prod.outlook.com -- With Regards, Amit Kapila.