Re: Proposal: Conflict log history table for Logical Replication

On Thu, Oct 15, 2026 at 9:47 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Wed, Oct 14, 2026 at 8:16 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> >
> >
> > 1) Does the remote_origin column in CLT add any value?
> > + if (replorigin_xact_state.origin != InvalidReplOriginId)
> > + replorigin_by_oid(replorigin_xact_state.origin, true, &remote_origin);
> >
> > IIUC, replorigin_xact_state.origin is the subscription's own origin,
> > set at worker start, so every row has pg_<subid>.
>
> It could also be pg_<subid>_<relid>, for a tablesync worker. But
> again, it is not very useful as both subid and relid can be figured
> out from CLT table itself. So I too currently do not see any use of
> this column, unless I am missing some case?

While testing further on origin, I noticed that we do not distinguish
between origin-not -set and origin-dropped case in CLT while LOG does
distinguish between the two cases

For a simple test like this:

Sub:
SELECT pg_replication_origin_create('nd');
SELECT pg_replication_origin_session_setup('nd');
UPDATE tab2 set j=10 where i=1;
SELECT pg_replication_origin_session_reset();
SELECT pg_replication_origin_drop('nd'); -- 'nd' gone; row still
carries its id

Pub:
UPDATE tab2 set j=100 where i=1;

logfile dumps 'non-existent origin' for the dropped origin:

LOG: conflict detected on relation "public.tab2":
conflict=update_origin_differs
DETAIL: Updating the row that was modified by a non-existent origin
in transaction ....

For the case when the origin was not set, the log shows 'modified locally':

LOG: conflict detected on relation "public.tab2":
conflict=update_origin_differs
DETAIL: Updating the row that was modified locally in transaction ....

while CLT's local_conflicts column dumps origin:null for both cases:

{"{\"xid\":\"688\",\"commit_ts\":\"2026-10-15T10:50:10.159126+05:30\",\"origin\":null}"}
{"{\"xid\":\"691\",\"commit_ts\":\"2026-10-15T10:59:50.929314+05:30\",\"origin\":null}"}

I think, it is not worth the code-fix for the reason that as we can
not dump origin as 'non-existent' to CLT as it could be confused with
an actual origin name. So, fixing this would require marking the
origin with 'dropped:true', which is not worth the effort. But I feel
we can modify the doc at-least to
explain what 'origin:null' means.

Suggestion:
local_conflicts: An array of JSON objects representing the state of
existing local row(s) that caused the conflict. Each object includes
the local transaction ID (xid), commit timestamp (commit_ts), and the
name of the replication origin that last modified the row (origin).
The origin field is NULL if the transaction had no replication origin
set or if that origin has since been dropped. The column itself is
NULL if there are no local conflicting rows (e.g., in update_missing
and delete_missing conflicts).

Earlier it was:
local_conflicts: An array of JSON objects representing the state of
existing local row(s) that caused the conflict. Each object includes
the local transaction ID (xid), commit timestamp (commit_ts), and
origin (origin). This is NULL if there are no local conflicting rows
(e.g., in update_missing and delete_missing conflicts).

Attached the doc patch atop v81, consider it if you agree with the suggestion.

thanks
Shveta