Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAJpy0uDcoQCmdrXqEank8FcWTzmrch7_WB_ZagcwR66yHzsdzw@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (Nisha Moond <nisha.moond412@gmail.com>)
List pgsql-hackers
On Wed, Sep 30, 2026 at 6:53 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> >> I think there may be some misunderstanding about what the
> >> replica_identity_full column actually stores. This question was also
> >> raised earlier; please see [1] and the discussion that followed. This
> >> field indicates the subscriber’s actual search method.
> >
> >
> > Thank you for clarifying the intended design and also the pointer to the old thread.
> >
> > I understand now that the intention for `replica_identity_full` is to indicate whether the conflicting row was
locatedvia a specific replica key index (`false`) versus a full-tuple search (`true`), rather than reflecting the DDL
catalogproperty (pg_class.relreplident). 
> >
>
> I think the docs can be improved to avoid this confusion, as Vignesh
> also suggested earlier in [1]. How about updating it to:
> "Indicates whether the conflicting local row was located using the
> full tuple (true) or the replica identity key of the local table
> (false)."
>
> Let me know if this works for you.

+1

thanks
Shveta



pgsql-hackers by date:

Previous
From: shihao zhong
Date:
Subject: Re: Correct documentation for protocol version
Next
From: vignesh C
Date:
Subject: Re: Fix apply worker crash when subscriber table has only a deferrable primary key