Re: Conflict Detection and Resolution

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Conflict Detection and Resolution
Date: 2024-08-26 03:35:05
Message-ID: CAJpy0uCtYweJHwuYdgGWR7iSDUKjqDtA7yoLe+XMWqWnmQhj8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2024-08-26 04:00:00 Re: configure failures on chipmunk
Previous Message jian he 2024-08-26 03:26:00 Re: Set query_id for query contained in utility statement