On Tue, Mar 11, 2025 at 2:28 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> On Tue, Mar 11, 2025 at 11:10 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> The goal of introducing a new conflict type is to handle multiple-key
> conflicts separately. It will not only allow users to apply different
> resolution methods for single-key vs multi-key conflicts but will also
> help them identify such cases directly from stats instead of filtering
> through the LOG file.
Thanks for the explanation, that makes sense.
> For example, with future resolution options, 'last_update_wins' will
> work well for single-key conflicts (insert_exists/update_exists) since
> only one local tuple will be replaced if the remote wins. However, for
> multi-key conflicts, this resolution may not be feasible. Even if
> supported, resolving the conflict could result in deleting multiple
> tuples, which users may want to control separately, like opting to
> skip or error out in case of multi-key conflicts.
> For reference, databases like EDB-PGD(BDR)[1] support a separate
> conflict type for multi-key cases. OTOH, Oracle[2] and DB2[3] do not
> have a separate conflict_type and always ERROR out during conflict
> resolution if multiple unique constraint violations happen. However,
> none of these databases use the single-key conflict_type and
> resolution for the multi-key conflict cases.
>
> We’d like to know your preference—should we always ERROR out like
> Oracle/DB2, or keep it as a separate conflict_type for better control
> during resolution?
I agree that supporting this new conflict type will provide users with
better control, particularly when doing automatic conflict resolution.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
