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 OS0PR01MB57166ACCCCD8C4D9FC3FE56294852@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>)
Responses Re: Conflict detection and logging in logical replication
List pgsql-hackers
On Friday, August 9, 2024 7:45 PM Michail Nikolaev <michail.nikolaev@gmail.com>  wrote:
> There are some comments on this patch related to issue [0]. In short: any
> DirtySnapshot index scan may fail to find an existing tuple in the case of a
> concurrent update.
> 
> - FindConflictTuple may return false negative result in the case of concurrent update because >
ExecCheckIndexConstraintsuses SnapshotDirty.
 
> - As a result, CheckAndReportConflict may fail to report the conflict.
> - In apply_handle_update_internal we may get an CT_UPDATE_MISSING instead of CT_UPDATE_DIFFER
> - In apply_handle_update_internal we may get an CT_DELETE_MISSING instead of CT_DELETE_DIFFER
> - In apply_handle_tuple_routing we may get an CT_UPDATE_MISSING instead of CT_UPDATE_DIFFER
> 
> If you're interested, I could create a test to reproduce the issue within the
> context of logical replication. Issue [0] itself includes a test case to
> replicate the problem.
> 
> 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?

Thanks for reporting.

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

Best Regards,
Hou zj

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: [BUG?] check_exclusion_or_unique_constraint false negative
Next
From: David Rowley
Date:
Subject: Re: Do we still need parent column in pg_backend_memory_context?