RE: Conflict detection and logging in logical replication
От | Zhijie Hou (Fujitsu) |
---|---|
Тема | RE: Conflict detection and logging in logical replication |
Дата | |
Msg-id | OS0PR01MB57166ACCCCD8C4D9FC3FE56294852@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Conflict detection and logging in logical replication (Michail Nikolaev <michail.nikolaev@gmail.com>) |
Ответы |
Re: Conflict detection and logging in logical replication
|
Список | 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 по дате отправления: