On Mon, Aug 26, 2024 at 9:05 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> 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).
>
Fixed.
Thanks,
Nisha
