On Fri, Aug 16, 2024 at 10:46 AM shveta malik <shveta.ma...@gmail.com> wrote: > > On Thu, Aug 15, 2024 at 12:47 PM Zhijie Hou (Fujitsu) > <houzj.f...@fujitsu.com> wrote: > > > > Thanks. I have checked and merged the changes. Here is the V15 patch > > which addressed above comments. > > Thanks for the patch. Please find few comments and queries: > > 1) > For various conflicts , we have these in Logs: > Replica identity (val1)=(30). (for RI on 1 column) > Replica identity (pk, val1)=(200, 20). (for RI on 2 columns) > Replica identity (40, 40, 11). (for RI full) > > Shall we have have column list in last case as well, or can simply > have *full* keyword i.e. Replica identity full (40, 40, 11) >
I would prefer 'full' instead of the entire column list as the complete column list could be long and may not much sense. > > 2) > For toast column, we dump null in remote-tuple. I know that the toast > column is not sent in new-tuple from the publisher and thus the > behaviour, but it could be misleading for users. Perhaps document > this? > Agreed that we should document this. I suggest that we can have a doc patch that explains the conflict logging format and in that, we can mention this behavior as well. > 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'. > I think update_exists is quite similar to insert_exists and both happen due to unique key violation. So, it seems okay to display the Key for update_exists. > > 4) > Why delete_missing is not having remote_tuple. Is it because we dump > new tuple as 'remote tuple', which is not relevant for delete_missing? > Right. -- With Regards, Amit Kapila.
