Re: Proposal: Conflict log history table for Logical Replication

On Wed, 26 Aug 2026 at 20:02, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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 agree, and the behavior seems correct.

There are actually three different things involved here, which can be
a bit confusing because similar terminology is used for all of them:
Replica identity of the table on the publisher — determines the
identity information included in the logical change sent to the
subscriber.
Replica identity configured for the corresponding table on the
subscriber — this is the local table's replica identity and can be
different from the publisher's replica identity.
replica_identity / replica_identity_full columns in the conflict table
— these describe the search value and method used by the apply worker
to locate the local row. They do not directly represent either the
publisher or subscriber's replica identity setting.

Would it make sense to clarify this distinction in the documentation
to avoid confusion? For example something like:
replica_identity - The search value used to locate the local row: the
JSON representation of the replica identity key values or full tuple.

This would make it clearer that these conflict-table columns describe
how the apply worker searched for the local row, rather than the
replica identity configured on either the publisher or subscriber.
I'm fine if you don't want to change and feel the existing documented
contents are ok.

Regards,
Vignesh