On Wednesday, August 14, 2024 10:15 PM Michail Nikolaev <michail.nikol...@gmail.com> wrote: > > 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. > > That seems a little bit strange to me. > > From the perspective of a user, I expect that if a change from publisher is > not > applied - I need to know about it from the logs.
I think this is exactly the current behavior in the patch. In the race condition we discussed, the insert will be applied if the conflicting tuple is removed concurrently before CheckAndReportConflict(). > But in that case, I will not see any information about conflict in the logs > in SOME cases. But in OTHER cases I will see it. However, in both cases the > change from publisher was not applied. And these cases are just random and > depend on the timing of race conditions. It is not something I am expecting > from the database. 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. Best Regards, Hou zj
