On Mon, Oct 12, 2026 at 10:26 AM Amit Kapila <[email protected]> wrote: > > 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. >
Okay. Works for me. We can explore these as further enhancements. Basically these: 1) When the replica identity (RI) itself changes, we can explore logging both the new and old RI values. 2) We can look into logging the 'conflicted column': name and value. thanks Shveta
