Re: Conflict detection and logging in logical replication

shveta malik <shveta.malik@gmail.com>

From: shveta malik <shveta.malik@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Peter Smith <smithpb2250@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Nisha Moond <nisha.moond412@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Dilip Kumar <dilipbalaut@gmail.com>, Jan Wieck <jan@wi3ck.info>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, shveta malik <shveta.malik@gmail.com>
Date: 2024-08-22T03:25:24Z
Lists: pgsql-hackers
On Wed, Aug 21, 2024 at 3:04 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
>
> Attach the V20 patch set which addressed above, Shveta[1][2] and Kuroda-san's[3]
> comments.
>

Thank You for the patch. Few comments:

1)
+ The key section includes the key values of the local tuple that
violated a unique constraint insert_exists or update_exists conflicts.

 --I think something  is missing in this line. Maybe add a 'for' or
*in case of*:
 The key section includes the key values of the local tuple that
violated a unique constraint *in case of*/*for* insert_exists or
update_exists conflicts.

2)
+ The replica identity section includes the replica identity key
values that used to search for the existing local tuple to be updated
or deleted.

--that *were* used to

thanks
Shveta



Commits

  1. Rename the conflict types for the origin differ cases.

  2. Doc: explain the log format of logical replication conflicts.

  3. Log the conflicts while applying changes in logical replication.

  4. Avoid duplicate table scans for cross-partition updates during logical replication.