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