Re: Proposal: Conflict log history table for Logical Replication

On Thu, Jun 18, 2026 at 9:33 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Tue, Jun 16, 2026 at 6:54 PM Dilip Kumar <dilipbalaut(at)gmail(dot)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. Additionally, the nested try-catch to downgrade ERROR to
WARNING also looks ugly and a source of future bugs and maintenance
burden. The attached patch tries to fix this by ERRORing out on
insertion failure and attaching the required conflict info as a
context of ERROR. The patch also improved the ReportApplyConflict()
non-ERROR paths by displaying the conflict information in server LOGs
before inserting the same into CLT so that if insertion fails, the
complete conflict info can be present in server LOGs. See
v52-1-amit.Improve-error-handling-for-conflict-log-table-ins.

Additionally, there is another problem with 0003 where when a parallel
apply worker hits an ERROR-level conflict it logs the conflict to the
conflict log table in a new transaction in its error path, after
aborting the failed apply transaction. But the leader detects worker
failure in pa_wait_for_xact_finish() by waiting on the worker's
transaction lock, and AbortOutOfAnyTransaction() releases that lock:
the leader unblocks, sees a non-finished state, raises "lost
connection to the logical replication parallel apply worker", and
tears the worker down -- which can SIGTERM it mid-insert and lose the
conflict log row, besides being a misleading message. The attached
top-up patch v52-2-amit.fix_parallel_apply_logging fixes that by
introducing PARALLEL_TRANS_ERROR state. I think if you are okay with
this patch, you can merge it into your 0003 but
v52-1-amit.Improve-error-handling-for-conflict-log-table-ins can be
reviewed before being merged into 0003.

I have taken help from AI to work on these top-up (atop v52 0003)
bug-fix patches and done self initial review and test of these but
more review and testing is required for this work.

--
With Regards,
Amit Kapila.