Re: Conflict detection for update_deleted in logical replication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Conflict detection for update_deleted in logical replication
Date
Msg-id CAA4eK1+B1PURD4xp=LSV2o8nR3tz8sA+0qTVfYC677os8WAAuw@mail.gmail.com
Whole thread Raw
In response to RE: Conflict detection for update_deleted in logical replication  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses RE: Conflict detection for update_deleted in logical replication
List pgsql-hackers
On Wed, Jul 23, 2025 at 12:53 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> Thanks for pushing. I have rebased the remaining patches.
>

+ * This function performs a full table scan instead of using indexes because
+ * index scans could miss deleted tuples if an index has been re-indexed or
+ * re-created during change applications.

IIUC, once the tuple is not found during update, the patch does an
additional scan with SnapshotAny to find the DEAD tuple, so that it
can report update_deleted conflict, if one is found. The reason in the
comments to do sequential scan in such cases sound reasonable but I
was thinking if we can do index scans if the pg_conflict_* slot's xmin
is ahead of the RI (or any usable index that can be used during scan)
index_tuple's xmin? Note, we use a similar check with the indcheckxmin
parameter in pg_index though the purpose of that is different. If this
can happen then still in most cases the index scan will happen.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: Andrei Lepikhov
Date:
Subject: Re: track generic and custom plans in pg_stat_statements