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

From Dilip Kumar
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAFiTN-vLKRRSDMwPGMvcBM1CRntXbsHARU-0e76PDk=-k5RO6A@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Proposal: Conflict log history table for Logical Replication
List pgsql-hackers
On Mon, Jul 6, 2026 at 11:42 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Jul 3, 2026 at 12:51 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Thu, Jul 2, 2026 at 3:33 PM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > On Thu, Jul 2, 2026 at 1:39 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > >
> > > >
> > > > I rebased the remaining patches on top of HEAD. So far, I have run
> > > > pgindent and completed the doc merge for 0001.  The 0002 and 0003 are
> > > > just rebased.
> > > >
> > >
> >
> > I am focusing on 001 alone.
> > I was verifying conflict insertion for all conflict_types in regular
> > worker flow (not parallel), I have just one comment there:
> >
> > For insert_exists conflict, both replica_identity (JSON) and
> > replica_identity_full (bool) are NULL. Is it conscious decision to
> > keep 'replica_identity_full' as NULL or shall we make this field as
> > 'bool NOT NULL DEFAULT false'. As per doc at [1], NULL value for
> > boolean represents 'unknown'
> >
>
> Displaying 'replica_identity_full' as false means replica_identity
> index is used and same is expected to be displayed as well.
>
> > If it is intentionaly kept NULL, do you think we should update below
> > doc to explain that it can be NULL for the cases where
> > replica_identity is not applicable.
> >
> > replica_identity_full boolean I
> > indicates whether replica_identity represents a full tuple (true) or
> > key values of a replica identity index (false).
> >
>
> I agree with the doc update for this case.
>
> I have one comment on 63-0001.
> *
> In 63-0001, it seems only a minor title change in docs:
> +  <sect2 id="logical-replication-conflict-logging">
> +   <title>Conflict logging</title>
> leads to the patch showing such a big change in
> logical-replication.sgml. Is that correct? If so, I suggest moving the
> logical-replication.sgml to a later doc-only patch as that will help
> in focusing the core code change. I understand that we need to update
> docs with the new section for logging conflict information in tables
> and that is important but we can handle it separately as it would
> require more thoughts on how to rearrange the current docs.

Attached patch fixes comments raised by Nisha, Shaveta and separates
out the logical-replication.sgml changes to a new patch.

--
Regards,
Dilip Kumar
Google

Attachment

pgsql-hackers by date:

Previous
From: Ilmar Yunusov
Date:
Subject: Re: [RFC PATCH v0 0/7] Add EXPLAIN ANALYZE wait event reporting
Next
From: Ilmar Yunusov
Date:
Subject: Re: File locks for data directory lockfile in the context of Linux namespaces