On Tue, Mar 11, 2025 at 2:28 PM Nisha Moond <nisha.moond...@gmail.com> wrote: > > On Tue, Mar 11, 2025 at 11:10 AM Dilip Kumar <dilipbal...@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
