Re: Proposal: Conflict log history table for Logical Replication

On Wed, Aug 26, 2026 at 8:02 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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?

I have the exact same understanding and feels that the reported
scenario behaves in expected way.

> [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