Re: Conflict detection and logging in logical replication

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
report about the conflict in a more consistent way?

Best regards,
Mikhail.

[1]: https://commitfest.postgresql.org/49/5021/