Re: Proposal: Conflict log history table for Logical Replication

From: vignesh C <vignesh21(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Narayanan Venkateswaran <narayananvpostgres(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, saurabh singh <saurabh(dot)singh214(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-10-01 05:24:58
Message-ID: CALDaNm3zZSovnjHiK6D+MetjRPyOAOnPt=O7nVgb3mNgCWb=iA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 1 Oct 2026 at 10:26, shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Thu, Oct 1, 2026 at 10:17 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > On Wed, 30 Sept 2026 at 18:53, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Sep 30, 2026 at 12:28 PM Narayanan Venkateswaran
> > > <narayananvpostgres(at)gmail(dot)com> wrote:
> > > >
> > > > Hi Nisha,
> > > >
> > > > Thank you very much for the guidance and the pointers to the older thread,
> > > >
> > > > Please find some replies inline,
> > > >
> > > > On Wed, Sep 30, 2026 at 11:05 AM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> > > >>
> > > >> On Tue, Sep 29, 2026 at 5:56 PM Narayanan Venkateswaran
> > > >> <narayananvpostgres(at)gmail(dot)com> wrote:
> > > >> >
> > > >> > Thank you very much for the excellent work. I looked at the patch v77,
> > > >> >
> > > >>
> > > >> Hi Narayanan, thanks for reviewing it.
> > > >>
> > > >> > The code decides replica_identity_full using the following logic (in conflict.c),
> > > >> >
> > > >> > if (!TupIsNull(searchslot))
> > > >> > {
> > > >> > Oid replica_index = GetRelationIdentityOrPK(rel);
> > > >> >
> > > >> > /*
> > > >> > * If the table has a valid replica identity index, build the index
> > > >> > * JSON datum from key value. Otherwise, in REPLICA IDENTITY FULL
> > > >> > * cases, set replica_identity_full to true and leave replica_identity
> > > >> > * NULL to avoid serializing full tuples that could exceed memory
> > > >> > * allocation limits.
> > > >> > */
> > > >> > if (OidIsValid(replica_index))
> > > >> > {
> > > >> > values[attno++] = BoolGetDatum(false);
> > > >> > values[attno++] = build_index_key_json(rel,
> > > >> > replica_index,
> > > >> > searchslot,
> > > >> > &omitted);
> > > >> > }
> > > >> > else
> > > >> > {
> > > >> > values[attno++] = BoolGetDatum(true);
> > > >> > nulls[attno++] = true;
> > > >> > }
> > > >> > }
> > > >> > else
> > > >> > {
> > > >> > nulls[attno++] = true;
> > > >> > nulls[attno++] = true;
> > > >> > }
> > > >> >
> > > >> > In PostgreSQL catalogs (pg_class.relreplident), a table's replica can be one of four values:
> > > >> >
> > > >> > 'd' = REPLICA_IDENTITY_DEFAULT: Use PK index if one exists. If the table has no PK, it has no index and is NOT FULL.
> > > >> > 'n' = REPLICA_IDENTITY_NOTHING: No replica identity.
> > > >> > 'i' = REPLICA_IDENTITY_INDEX: Explicit unique index.
> > > >> > 'f' = REPLICA_IDENTITY_FULL: The entire tuple is the identity.
> > > >> >
> > > >> > If a subscriber relation has REPLICA IDENTITY DEFAULT without a primary key (or REPLICA IDENTITY NOTHING) GetRelationIdentityOrPK() returns InvalidOid. In this case, the code sets replica_identity_full = true.
> > > >> >
> > > >>
> > > >> 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 located via a specific replica key index (`false`) versus a full-tuple search (`true`), rather than reflecting the DDL catalog property (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.
> >
> > The (true) and (false) in this wording are a little unclear, as it is
> > not obvious what they refer to. I'm not sure they are necessary here.
> > If we do want to mention the Boolean values, it may be clearer to
> > explicitly refer to the field, for example, replica_identity_full
> > (true/false).
>
> Shall it be:
>
> "True if the conflicting local row was located using the full tuple,
> rather than the replica identity key of the local table."

Thanks, this looks good to me.

Regards,
Vignesh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-10-01 05:26:20 Re: Server crash when describing a FETCH statement after its cursor is closed
Previous Message Ayush Tiwari 2026-10-01 05:24:55 Re: [PATCH] Clear FatalError earlier during crash restart