On Wed, Aug 26, 2026 at 7:04 PM vignesh C <[email protected]> wrote:
>
> On Wed, 26 Aug 2026 at 18:26, Dilip Kumar <[email protected]> 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
