Re: Proposal: Conflict log history table for Logical Replication

On Fri, Oct 23, 2026 at 12:31 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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.

Fair enough

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.

I am wondering is it right to call it remote_origin? As this is
locally generated origin right?

--
Regards,
Dilip Kumar
Google