On Fri, Sep 18, 2026 at 1:58 PM shveta malik <[email protected]> wrote: > > On Fri, Sep 18, 2026 at 1:35 PM Nisha Moond <[email protected]> wrote: > > > > On Thu, Sep 17, 2026 at 8:06 PM Dilip Kumar <[email protected]> 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.
