| 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: | Whole Thread | Raw Message | 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
| 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 |