On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) <houzj.f...@fujitsu.com> wrote: > Here is the V6 patch set which addressed Shveta and Nisha's comments > in [1][2][3][4].
Thanks for the patch. I tested the v6-0001 patch with partition table scenarios. Please review the following scenario where Pub updates a tuple, causing it to move from one partition to another on Sub. Setup: Pub: create table tab (a int not null, b int not null); alter table tab add constraint tab_pk primary key (a,b); Sub: create table tab (a int not null, b int not null) partition by range (b); alter table tab add constraint tab_pk primary key (a,b); create table tab_1 partition of tab FOR values from (MINVALUE) TO (100); create table tab_2 partition of tab FOR values from (101) TO (MAXVALUE); Test: Pub: insert into tab values (1,1); Sub: update tab set a=1 where a=1; > just to make it Sub's origin Sub: insert into tab values (1,101); Pub: update b=101 where b=1; --> Both 'update_differ' and 'insert_exists' are detected. For non-partitioned tables, a similar update results in 'update_differ' and 'update_exists' conflicts. After detecting 'update_differ', the apply worker proceeds to apply the remote update and if a tuple with the updated key already exists, it raises 'update_exists'. This same behavior is expected for partitioned tables too. Thanks, Nisha
