Re: Proposal: Conflict log history table for Logical Replication

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:
> >
> > >
> > > Overall, I prefer option 2 and deal with the very rare cases in a
> > > separate patch if necessary.
> >
> > Yes, that makes sense. I have prepared a top-up patch using approach
> > 2, IMHO the edge case should realistically only trigger when a
> > user-defined type’s output function produces an unusually massive
> > value. I'll see if I can construct a test for this. While we could
> > theoretically simulate it with a minimal on-disk type whose output
> > function generates a 1GB string, that feels more like an
> > artificial/pathological case than a realistic workload.
> >
>
> Thanks for the patch. Please find a few initial comments; I’m still reviewing.
>
> 1) Issue #2 from [1] is not fixed yet.
> replica_identity is currently built from the index's full descriptor,
> so INCLUDE columns are included. This is incorrect because:
> a) INCLUDE columns are not part of the lookup key, so this does not
> match the log, which reports only key columns.
> b) On UPDATE, an INCLUDE column can contain arbitrarily large
> text/json values and unnecessarily contribute to the tuple size.
>
> The attached diff copies only the index key attributes. Please
> consider it if the approach looks reasonable.
> ~~~
>
> 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?

thanks
Shveta