Horton

RE: Conflict detection and logging in logical replication

Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>

View thread View on postgr.es
From: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
To: Michail Nikolaev <michail.nikolaev@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, shveta malik <shveta.malik@gmail.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>
Date: 2024-08-14T02:31:10Z
Lists: pgsql-hackers 
On Tuesday, August 13, 2024 7:33 PM Michail Nikolaev <michail.nikolaev@gmail.com>  wrote:

> I think this is an independent issue which can be discussed separately in the
> original thread[1], and I have replied to that thread.

>Thanks! But it seems like this part is still relevant to the current thread:

> > It also seems possible that a conflict could be resolved by a concurrent update
> > before the call to CheckAndReportConflict, which means there's no guarantee
> > that the conflict will be reported correctly. Should we be concerned about
> > this?

This is as expected, and we have documented this in the code comments. We don't
need to report a conflict if the conflicting tuple has been removed or updated
due to concurrent transaction. The same is true if the transaction that
inserted the conflicting tuple is rolled back before CheckAndReportConflict().
We don't consider such cases as a conflict.

Best Regards,
Hou zj

Commits

  1. Rename the conflict types for the origin differ cases.

  2. Doc: explain the log format of logical replication conflicts.

  3. Log the conflicts while applying changes in logical replication.

  4. Avoid duplicate table scans for cross-partition updates during logical replication.