RE: Conflict detection and logging in logical replication - Mailing list pgsql-hackers

From Zhijie Hou (Fujitsu)
Subject RE: Conflict detection and logging in logical replication
Date
Msg-id OS0PR01MB5716294CD70727681B24663694872@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Conflict detection and logging in logical replication  (Michail Nikolaev <michail.nikolaev@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: collect_corrupt_items_vacuum.patch
Next
From: Thomas Munro
Date:
Subject: Re: Remaining dependency on setlocale()