Horton
Menu

Re: Proposal: Conflict log history table for Logical Replication

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, vignesh C <vignesh21@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2026-06-22T08:38:21Z
Lists: pgsql-hackers 
On Sun, Jun 21, 2026 at 7:19 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 9:33 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Tue, Jun 16, 2026 at 6:54 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > > IMHO we should just log WARNING and continue the apply worker on
> > > conflict insertion failure, lets see what other thinks on this.
> > >
> >
> > I have the same opinion. Allowing CLT to block the apply worker would
> > be undesirable; CLT is a history/logs collection feature and should
> > not interrupt core logical replication work.
> >
>
> I think the insert can fail in rare cases like disk getting full while
> writing WAL or some internal memory ERROR and the ERROR could be
> persistent which means the LOG will be filled with the same WARNING if
> there are many conflicts. Also, users may not like missing out on
> conflict information. So, we can ERROR out and let users fix the
> situation.

Okay, that's another way to look at it. I am okay with this approach too.

Thanks,
Shveta

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