On Fri, Aug 16, 2024 at 10:46 AM shveta malik <shveta.ma...@gmail.com> wrote: > > 3) > For update_exists(), we dump: > Key (a, b)=(2, 1) > > For delete_missing, update_missing, update_differ, we dump: > Replica identity (a, b)=(2, 1). > > For update_exists as well, shouldn't we dump 'Replica identity'? Only > for insert case, it should be referred as 'Key'. >
On rethinking, is it because for update_exists case 'Key' dumped is not the one used to search the row to be updated? Instead it is the one used to search the conflicting row. Unlike update_differ, the row to be updated and the row currently conflicting will be different for update_exists case. I earlier thought that 'KEY' and 'Existing local tuple' dumped always belong to the row currently being updated/deleted/inserted. But for 'update_eixsts', that is not the case. We are dumping 'Existing local tuple' and 'Key' for the row which is conflicting and not the one being updated. Example: ERROR: conflict detected on relation "public.tab_1": conflict=update_exists Key (a, b)=(2, 1); existing local tuple (2, 1); remote tuple (2, 1). Operations performed were: Pub: insert into tab values (1,1); Sub: insert into tab values (2,1); Pub: update tab set a=2 where a=1; Here Key and local tuple are both 2,1 instead of 1,1. While replica identity value (used to search original row) will be 1,1 only. It may be slightly confusing or say tricky to understand when compared to other conflicts' LOGs. But not sure what better we can do here. -------------------- One more comment: 5) For insert/update_exists, the sequence is: Key .. ; existing local tuple .. ; remote tuple ... For rest of the conflicts, sequence is: Existing local tuple .. ; remote tuple .. ; replica identity .. Is it intentional? Shall the 'Key' or 'Replica Identity' be the first one to come in all conflicts? thanks Shveta
