Re: Conflict detection and logging in logical replication
| От | Michail Nikolaev |
|---|---|
| Тема | Re: Conflict detection and logging in logical replication |
| Дата | |
| Msg-id | CANtu0oiFPkHe0HrbnKKCTXdFKVRfhUF8bwKzR9Y7y3Q7bdQKWQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | RE: Conflict detection and logging in logical replication ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
| Ответы |
RE: Conflict detection and logging in logical replication
|
| Список | pgsql-hackers |
Hello, everyone.
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 ExecCheckIndexConstraints uses 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?
[0]: https://commitfest.postgresql.org/49/5151/
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 ExecCheckIndexConstraints uses 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?
[0]: https://commitfest.postgresql.org/49/5151/
В списке pgsql-hackers по дате отправления: