Re: Conflict detection and logging in logical replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: Conflict detection and logging in logical replication
Date
Msg-id CAJpy0uA9B7GMg1h4M_y=Ebtg29=MFWGzxoVL0KwcuHiB5LuANw@mail.gmail.com
Whole thread Raw
In response to RE: Conflict detection and logging in logical replication  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses Re: Conflict detection and logging in logical replication
Re: Conflict detection and logging in logical replication
List pgsql-hackers
On Thu, Aug 15, 2024 at 12:47 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> Thanks. I have checked and merged the changes. Here is the V15 patch
> which addressed above comments.

Thanks for the patch. Please find few comments and queries:

1)
For various conflicts , we have these in Logs:
Replica identity (val1)=(30).                (for RI on 1 column)
Replica identity (pk, val1)=(200, 20).  (for RI on  2 columns)
Replica identity (40, 40, 11).                (for RI full)

Shall we have have column list in last case as well, or can simply
have *full* keyword i.e. Replica identity full (40, 40, 11)


2)
For toast column, we dump null in remote-tuple. I know that the toast
column is not sent in  new-tuple from the publisher and thus the
behaviour, but it could be misleading for users. Perhaps document
this?

See 'null' in all these examples in  remote tuple:

update_differ With PK:
LOG:  conflict detected on relation "public.t1": conflict=update_differ
DETAIL:  Updating the row that was modified locally in transaction 831
at 2024-08-16 09:59:26.566012+05:30.
Existing local tuple (30, 30, 30,
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy...);
remote tuple (30, 30, 300, null); replica identity (pk, val1)=(30,
30).

update_missing With PK:
LOG:  conflict detected on relation "public.t1": conflict=update_missing
DETAIL:  Could not find the row to be updated.
Remote tuple (10, 10, 100, null); replica identity (pk, val1)=(10, 10).


update_missing with RI full:
LOG:  conflict detected on relation "public.t1": conflict=update_missing
DETAIL:  Could not find the row to be updated.
Remote tuple (20, 20, 2000, null); replica identity (20, 20, 10,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...).

3)
For update_exists(), we dump:
Key (a, b)=(2, 1)

For delete_missing, update_missing, update_differ, we dump:
Replica identity (a, b)=(2, 1).

For update_exists as well, shouldn't we dump 'Replica identity'? Only
for insert case, it should be referred as 'Key'.


4)
Why delete_missing is not having remote_tuple. Is it because we dump
new tuple as 'remote tuple', which is not relevant for delete_missing?
2024-08-16 09:13:33.174 IST [419839] LOG:  conflict detected on
relation "public.t1": conflict=delete_missing
2024-08-16 09:13:33.174 IST [419839] DETAIL:  Could not find the row
to be deleted.
Replica identity (val1)=(30).

thanks
Shveta



pgsql-hackers by date:

Previous
From: Steven Niu
Date:
Subject: Re: [Patch] remove duplicated smgrclose
Next
From: shveta malik
Date:
Subject: Re: Conflict detection and logging in logical replication