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.
> >
>
> The new resolution column is worth considering, we could name it as
> resolution_type or resolution_method as follows:
>
> ┌───────────────────────┬─────────────────────────────┐
> │ Conflict type │ resolution method │
> ├───────────────────────┼─────────────────────────────┤
> │ update_origin_differs │ apply_remote (or overwrite) │
> ├───────────────────────┼─────────────────────────────┤
> │ delete_origin_differs │ apply_remote │
> ├───────────────────────┼─────────────────────────────┤
> │ update_missing │ skip │
> ├───────────────────────┼─────────────────────────────┤
> │ delete_missing │ skip │
> ├───────────────────────┼─────────────────────────────┤
> │ update_deleted │ skip │
> └───────────────────────┴─────────────────────────────┘
>
> Today we will have just two distinct outcomes: apply_remote and skip.
> insert_exists, update_exists, and multiple_unique_conflicts are
> ERROR-only today, so under the "exclude ERROR" design they wouldn't
> produce CLT rows at all. BTW, looking at future possibilities, we will
> have values like:
> - keep_local — reject remote change, keep local row (mirror image of
> apply_remote)
> - keep_remote — same as apply_remote, likely the eventual canonical
> name once the strategy is user-selectable rather than hard-wired
> - last_write_wins — timestamp-based pick
>
> So, for update_origin_differs/delete_origin_differs, we can use either
> apply_remote, keep_remote, or overwrite. Do you have any preference?

My prefernce is 'apply_remote' here.
'keep_local - apply_remote' forms a natural, symmetric pair.
overwrite is somewhat ambiguous - it doesn't immediately say what is
being overwritten or which side wins.

>
> Today this column doesn't add much value as each conflict type maps
> 1:1 to a fixed resolution (keep_remote or skip) but it will be really
> valuable when we have configurable resolution methods, so I am okay
> with this low cost addition of an additional column. OTOH, there is an
> argument that as this new column doesn't add much value we can add it
> later as well with configurable resolution methods. I am fine either
> way. Does anyone else have an opinion on this matter?

+1 on adding the resolution column. While this information on
default-resolutions is already documented, having it shown directly in
the column gives users immediate clarity about which resolution is
being used, without requiring them to look it up in the docs or know
the history of the defaults. I understand that this behavior is not
new and that we aren’t introducing it, but I think exposing it here
makes the behavior much clearer to users.

> I feel even if we decide to have this column today, we can do it as a
> top-up patch on the next inserts-into-clt patch.
>
> > Users would still have to read the server log for conflicts handled by
> > the ERROR resolver, and I think it would be good to somehow make that
> > information queryable some day.
> >
>
> Yes, we can do it as a separate patch later.
>
> --
> With Regards,
> Amit Kapila.