Re: Conflict detection and logging in logical replication
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
Nisha Moond <nisha.moond412@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>,
Dilip Kumar <dilipbalaut@gmail.com>, Jan Wieck <jan@wi3ck.info>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, shveta malik <shveta.malik@gmail.com>
Date: 2024-08-16T05:16:43Z
Lists: pgsql-hackers
On Thu, Aug 15, 2024 at 12:47 PM Zhijie Hou (Fujitsu) <houzj.fnst@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) 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
Commits
-
Rename the conflict types for the origin differ cases.
- 640178c92e3f 18.0 landed
-
Doc: explain the log format of logical replication conflicts.
- edcb71258504 18.0 landed
-
Log the conflicts while applying changes in logical replication.
- 9758174e2e5c 18.0 landed
-
Avoid duplicate table scans for cross-partition updates during logical replication.
- a67da49e1d98 18.0 cited