Re: Conflict Detection and Resolution - Mailing list pgsql-hackers

On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> The patches have been rebased on the latest pgHead following the merge
> of the conflict detection patch [1]. The detect_conflict option has
> been removed, and conflict detection is now enabled by default. This
> change required the following updates in resolver patches:
> patch-0001:
>  - Removed dependency on the detect_conflict option. Now, default
> conflict resolvers are set on CREATE SUBSCRIPTION if no values are
> provided.
>  - To keep the behavior unchanged, the default resolvers are now set as -
>   insert_exists  = error
>   update_exists  = error
>   update_differ  = apply_remote
>   update_missing = skip
>   delete_missing = skip
>   delete_differ  = apply_remote
>  - Added documentation for conflict resolvers.
>
> patch-0002:
> - Removed dependency on the detect_conflict option.
> - Updated test cases in 034_conflict_resolver.pl to reflect new
> default resolvers and the removal of the detect_conflict option.
>
> patch-0003:
> - Implemented resolver for the update_exists conflict type. Supported
> resolvers are: apply_remote, keep_local, error.
>

Thanks Nisha for the patches, I was running some tests on
update_exists and found this case wherein it misses to LOG one
conflict out of 3.

create table tab (a int primary key, b int unique, c int unique);
Pub: insert into tab  values (1,1,1);

Sub:
insert into tab  values (2,20,30);
insert into tab values (3,40,50);
insert into tab values (4,60,70);

Pub: update tab set a=2,b=40,c=70 where a=1;

Here it logs update_exists conflict and the resolution for  Key
(b)=(40) and Key (c)=(70) but misses to LOG first one which is with
Key (a)=(2).

thanks
Shveta