Hello, Hou!
> 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.
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.
Maybe it is better to report about the fact that event from publisher was not applied because of conflict and then try to
provide additional information about the conflict itself?
Or possibly in case we were unable to apply the event and not able to find the conflict, we should retry the event processing?
Especially, this seems to be a good idea with future [1] in mind.
Or we may add ExecInsertIndexTuples ability to return information about conflicts (or ItemPointer of conflicting tuple) and then
