RE: Conflict detection and logging in logical replication
Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
From: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Nisha Moond <nisha.moond412@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, shveta malik <shveta.malik@gmail.com>, Jan Wieck <jan@wi3ck.info>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: 2024-06-24T02:09:27Z
Lists: pgsql-hackers
Attachments
- v2-0002-Collect-statistics-about-conflicts-in-logical-rep.patch (application/octet-stream) patch v2-0002
- v2-0001-Detect-and-log-conflicts-in-logical-replication.patch (application/octet-stream) patch v2-0001
On Friday, June 21, 2024 3:47 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > - The detail of the conflict detection > > We add a new parameter detect_conflict for CREATE and ALTER subscription > commands. This new parameter will decide if subscription will go for > confict detection. By default, conflict detection will be off for a > subscription. > > When conflict detection is enabled, additional logging is triggered in the > following conflict scenarios: > insert_exists: Inserting a row that violates a NOT DEFERRABLE unique > constraint. > update_differ: updating a row that was previously modified by another origin. > update_missing: The tuple to be updated is missing. > delete_missing: The tuple to be deleted is missing. > > For insert_exists conflict, the log can include origin and commit > timestamp details of the conflicting key with track_commit_timestamp > enabled. And update_differ conflict can only be detected when > track_commit_timestamp is enabled. > > Regarding insert_exists conflicts, the current design is to pass > noDupErr=true in ExecInsertIndexTuples() to prevent immediate error > handling on duplicate key violation. After calling > ExecInsertIndexTuples(), if there was any potential conflict in the > unique indexes, we report an ERROR for the insert_exists conflict along > with additional information (origin, committs, key value) for the > conflicting row. Another way for this is to conduct a pre-check for > duplicate key violation before applying the INSERT operation, but this > could introduce overhead for each INSERT even in the absence of conflicts. > We welcome any alternative viewpoints on this matter. When testing the patch, I noticed a bug that when reporting the conflict after calling ExecInsertIndexTuples(), we might find the tuple that we just inserted and report it.(we should only report conflict if there are other conflict tuples which are not inserted by us) Here is a new patch which fixed this and fixed a compile warning reported by CFbot. Best Regards, Hou zj
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