Re: Proposal: Conflict log history table for Logical Replication

On Thu, Oct 22, 2026 at 6:15 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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?
> >
>
> Yeah, that's a valid point, we can remove this column for now.
>

Isn't the value of origin_id for each tablesync worker different? Say
there are ten tablesync workers each with different origins and some
or all of them have conflicts during their apply (catch-up) phase,
won't recording origin-id be helpful to distinguish those? I feel the
origin and origin-id are internally generated values so having them
recorded is useful rather than a user trying to find out by
conflict-table name. In future, we may also want to record
local-origin-id as well which makes this value even more helpful as
users would be able to compare conflicting origins directly from the
table instead of inferring them via table names or other means.

--
With Regards,
Amit Kapila.