Re: Conflict detection for multiple_unique_conflicts in logical replication

On Fri, Apr 4, 2025 at 10:41 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> My point is, if it is deemed useful for a user to know if a *single*
> conflict was caused by an INSERT or by an UPDATE, then why is it not
> equally useful to know if *multiple* conflicts were caused by an
> INSERT or by an UPDATE?
>

The reason is that users can resolve single insert_exists or
update_exists by using last_update_wins kind of resolution strategy
either manually or automatically (in the future, after we get that
patch committed). The same may not be true for multiple rows case or
at least it won't be as simple the case as for single row, one may
need to consider removing multiple rows which can lead to data
inconsistency, so we are planning an ERROR as the default resolution
startegy. This could be the reason that even BDR has a single
conflict_type for this case [1][2]. I don't deny the possibility that
in the future, one comes up with a case where separate conflict types
for these makes sense, and at that time, we can consider adding more
conflict types, but for now, there is no solid case for it that is why
we kept a single conflict type.

[1] - https://www.enterprisedb.com/docs/pgd/4/bdr/conflicts/#insert-operations-that-violate-multiple-unique-constraints
[2] - https://www.enterprisedb.com/docs/pgd/4/bdr/conflicts/#update-operations-that-violate-multiple-unique-constraints

--
With Regards,
Amit Kapila.