Re: Proposal: Conflict log history table for Logical Replication

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 am not sure a separate column something like "remote_new_key" is
worth it just for this case as it would be NULL for the two delete
conflicts, and identical to replica_identity for every update that
does not change the key. I think we can document that replica_identity
contains the old key when the key is updated. Thoughts?
~~~

[1] https://www.postgresql.org/message-id/CABdArM5HbgRhPttsnZ2SFmxCMgqcanbyT4ZCo%3DfJBV0V65Hp_w%40mail.gmail.com

--
Thanks,
Nisha