Re: Conflict detection and logging in logical replication

On Thu, Aug 15, 2024 at 12:47 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)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)

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?

See 'null' in all these examples in remote tuple:

update_differ With PK:
LOG: conflict detected on relation "public.t1": conflict=update_differ
DETAIL: Updating the row that was modified locally in transaction 831
at 2024-08-16 09:59:26.566012+05:30.
Existing local tuple (30, 30, 30,
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy...);
remote tuple (30, 30, 300, null); replica identity (pk, val1)=(30,
30).

update_missing With PK:
LOG: conflict detected on relation "public.t1": conflict=update_missing
DETAIL: Could not find the row to be updated.
Remote tuple (10, 10, 100, null); replica identity (pk, val1)=(10, 10).

update_missing with RI full:
LOG: conflict detected on relation "public.t1": conflict=update_missing
DETAIL: Could not find the row to be updated.
Remote tuple (20, 20, 2000, null); replica identity (20, 20, 10,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...).

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'.

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?
2024-08-16 09:13:33.174 IST [419839] LOG: conflict detected on
relation "public.t1": conflict=delete_missing
2024-08-16 09:13:33.174 IST [419839] DETAIL: Could not find the row
to be deleted.
Replica identity (val1)=(30).

thanks
Shveta