Re: Proposal: Conflict log history table for Logical Replication

Dilip Kumar <dilipbalaut@gmail.com>

From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>, Peter Smith <smithpb2250@gmail.com>, vignesh C <vignesh21@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-06T07:21:47Z
Lists: pgsql-hackers

Attachments

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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Allow logical replication conflicts to be logged to a table.

  2. Avoid orphaned objects dependencies