Re: Proposal: Conflict log history table for Logical Replication

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?

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?

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.