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>, Amit Kapila <amit.kapila16@gmail.com>
Cc: "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-19T03:38:47Z
Lists: pgsql-hackers 
On Friday, August 16, 2024 7:47 PM Michail Nikolaev <michail.nikolaev@gmail.com>  wrote:
> > I think you might misunderstand the behavior of CheckAndReportConflict(),
> > even if it found a conflict, it still inserts the tuple into the index which
> > means the change is anyway applied.
> 
> > In the above conditions where a concurrent tuple insertion is removed or
> > rolled back before CheckAndReportConflict, the tuple inserted by apply will
> > remain. There is no need to report anything in such cases as apply was
> > successful.
> 
> Yes, thank you for explanation, I was thinking UNIQUE_CHECK_PARTIAL works
> differently.
> 
> But now I think DirtySnapshot-related bug is a blocker for this feature then,
> I'll reply into original after rechecking it.

Based on your response in the original thread[1], where you confirmed that the
dirty snapshot bug does not impact the detection of insert_exists conflicts, I
assume we are in agreement that this bug is not a blocker for the detection
feature. If you think otherwise, please feel free to let me know.

[1] https://www.postgresql.org/message-id/CANtu0oh69b%2BVCiASX86dF_eY%3D9%3DA2RmMQ_%2B0%2BuxZ_Zir%2BoNhhw%40mail.gmail.com

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.