Re: Proposal: Conflict log history table for Logical Replication

On Wed, Aug 26, 2026 at 7:04 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Wed, 26 Aug 2026 at 18:26, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > I didn’t check the script but if publisher has set the RI full then isn’t we should say RI is full, publisher is the one defining what should be RI am I missing something?
>
> I don't think this is necessarily true. The publisher's replica
> identity determines the identity information sent in the logical
> change, whereas the conflict log records the local relation's replica
> identity on the subscriber.
> For example, both publisher tables can have RI full:
> CREATE TABLE tab1 (a int, b text);
> ALTER TABLE tab1 REPLICA IDENTITY FULL;
> CREATE TABLE tab2 (a int, b text);
> ALTER TABLE tab2 REPLICA IDENTITY FULL;
>
> But on the subscriber, one table has primary key and another table has RI full:
> CREATE TABLE tab1 (a int PRIMARY KEY, b text);
> CREATE TABLE tab2 (a int, b text);
> ALTER TABLE tab2 REPLICA IDENTITY FULL;
>
> Generate update_origin_differs conflict for both the tables.
>
> The conflict log then shows:
> relname | replica_identity_full
> ---------+-----------------------
> tab1 | f
> tab2 | t
>
> If replica_identity_full represented the publisher's RI, both would be
> true. The different values show that it represents the subscriber's
> local RI.

Please consider how the subscriber locates tuples in
FindLogicalRepLocalIndex() [1]:

Case #1 Index Scan (Key-based search): If a valid Primary Key or
Replica Identity index exists on the subscriber
(GetRelationIdentityOrPK(localrel)), the apply worker uses that local
index to find the tuple, regardless of whether the publisher
configured a Replica Identity index or REPLICA IDENTITY FULL.
Case #2 Sequential Scan (Full tuple search): If no usable local
index/PK is present, the subscriber falls back to a sequential scan
only if the remote publisher has set REPLICA IDENTITY FULL
(remoterel->replident == REPLICA_IDENTITY_FULL). Without remote RI
FULL, the operation errors out.

How Conflict Detection Should Report This:
Case #1 (Index Found): Report that the search was not RI FULL (i.e.
key-based). The log should record the specific key values used to
locate the tuple, regardless of the publisher's remote RI setting.
Case #2 (Sequential Scan): Report that the search was RI FULL, because
the tuple was located via a full-tuple sequential scan (which is only
possible when the publisher sends the full old tuple).

In short, this field indicates the subscriber's actual search method:
by key index or by full-tuple sequential scan. This applies to both
the log and the conflict log table, and I think that makes complete
sense to me.

Let me know your thoughts?

[1]
FindLogicalRepLocalIndex()
{
idxoid = GetRelationIdentityOrPK(localrel);
if (OidIsValid(idxoid))
return idxoid;

if (remoterel->replident == REPLICA_IDENTITY_FULL) -- **this is RI
full of remote**
}

--
Regards,
Dilip Kumar
Google