Re: Proposal: Conflict log history table for Logical Replication

On Mon, Aug 10, 2026 at 10:32 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, Aug 8, 2026 at 2:23 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > There are two possible definitions we could give to CLT:
> >
> > 1. it stores how replication conflicts were resolved.
> > 2. it stores which replication conflicts caused data divergences (and
> > how they were resolved).
> >
> > My interpretation had been (1). The option is named
> > conflict_log_destination, which reads as choosing where the same
> > information goes, and the server log carries every conflict including
> > the conflicts resolved by the ERROR resolver. So I expected the table
> > to have the same coverage.
> >
> > That said, I can accept (2), and I agree it is what other replication
> > solutions do. If we go that way, though, I would like the CLT to have
> > a 'resolution' column, showing which resolution method was applied,
> > even though the resolvers are hard-wired per conflict type today. With
> > that column, a user can see both what conflict happened and how it was
> > handled by looking at the CLT alone.

Here is an updated patch as we discussed, and below is the list of changes:

1. Insert only resolved (LOG-level) conflicts in the conflict log
table: Conflicts that raise an ERROR halt replication and roll back
the transaction, so they are logged exclusively to the server log for
monitoring and alerting. The table is preserved purely as an audit log
for resolved conflicts where data is updated or skipped, I updated the
documentation accordingly.

2. Removed the key column from LocalConflictSchema: Since unique index
violations are ERROR-level and no longer stored in the table, the key
attribute is unnecessary and has been removed.

3. Preserved local_conflicts as json[]: Although currently recorded
conflicts involve a single local tuple, we decided to keep
local_conflicts as a JSON array for future-proofing. This ensures that
any future enhancements (such as multi-row conflict resolvers) will
not require backward-incompatible table schema changes.

I will work on other follow-up patches soon.

--
Regards,
Dilip Kumar
Google