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

From Nisha Moond
Subject Re: Conflict detection and logging in logical replication
Date
Msg-id CABdArM6wYc6SAhxRK26f=24D170DeLxirdPk6mC8dvWbD7mkeA@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
List pgsql-hackers
On Mon, Jun 24, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> When testing the patch, I noticed a bug that when reporting the conflict
> after calling ExecInsertIndexTuples(), we might find the tuple that we
> just inserted and report it.(we should only report conflict if there are
> other conflict tuples which are not inserted by us) Here is a new patch
> which fixed this and fixed a compile warning reported by CFbot.
>
Thank you for the patch!
A review comment: The patch does not detect 'update_differ' conflicts
when the Publisher has a non-partitioned table and the Subscriber has
a partitioned version.

Here’s a simple failing test case:
Pub: create table tab (a int primary key, b int not null, c varchar(5));

Sub: create table tab (a int not null, b int not null, c varchar(5))
partition by range (b);
alter table tab add constraint tab_pk primary key (a, b);
create table tab_1 partition of tab for values from (minvalue) to (100);
create table tab_2 partition of tab for values from (100) to (maxvalue);

With the above setup, in case the Subscriber table has a tuple with
its own origin, the incoming remote update from the Publisher fails to
detect the 'update_differ' conflict.

--
Thanks,
Nisha



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: [PATCH] Add ACL (Access Control List) acronym
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Improve EXPLAIN output for multicolumn B-Tree Index