On Mon, Aug 26, 2024 at 9:05 AM shveta malik <shveta.ma...@gmail.com> wrote: > > On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond <nisha.moond...@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
