Re: Proposal: Conflict log history table for Logical Replication

On Fri, Sep 18, 2026 at 1:58 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Fri, Sep 18, 2026 at 1:35 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> >
> > On Thu, Sep 17, 2026 at 8:06 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > 2) Now that remote_tuple has been removed, there is some information
> > loss when the replica identity key itself is updated.
> > For example:
> > -- pub
> > INSERT INTO t1 VALUES (3,'three');
> > -- sub
> > DELETE FROM t1 WHERE a = 3;
> > -- pub
> > UPDATE t1 SET a = 30 WHERE a = 3;
> >
> > Server log:
> > conflict detected on relation "public.t1": conflict=update_missing
> > DETAIL: Could not find the row to be updated: remote row (30,
> > three), replica identity (a)=(3).
> >
> > Conflict log table: replica_identity = {"a":3}, and there is no
> > mention of the new key 30 anywhere.
> >
> > For update_missing the remote change is skipped, but for
> > update_origin_differs the change is applied, so the local row now has
> > a=30 while the CLT row names a=3, and nothing connects the two. The
> > log will show the remote tuple, though.
>
> I agree. I too noticed this. Need to think more here.
>
> Another point of concern: we don't know from the CLT which column
> conflicted, out of the potentially large number of columns in a user
> tab. Consider an update_origin_differs case:
>
> Table t(id PK, val), with id=10, val=20 on both nodes.
>
> On the subscriber, the row is changed to val=200.
> At the same time, on the publisher, it is changed to val=300.
>
> The publisher's change comes in as an update_origin_differs conflict
> and overwrites 200 with 300. But the CLT only records something like:
>
> SELECT conflict_type, replica_identity, local_conflicts FROM
> pg_conflict.pg_conflict_log_16390;
> update_origin_differs | {"id":10} | [{"xid":"...", "commit_ts":"...",
> "origin":null}]
>
> So we know row id=10 had a conflict, but not which column conflicted,
> or what the old and new values were. Is there a concrete way for a
> user to find that information given only the CLT? Is changed col info
> worth adding to CLT?
>

I see that both what you and Nisha reported have value in terms of
giving more information to users. But OTOH we can add this additional
information as a separate enhancement as well, as this information
will also have all kinds of complications w.r.t size of data shouldn't
be more than 1GB.

--
With Regards,
Amit Kapila.