Re: Proposal: Conflict log history table for Logical Replication

On Mon, Oct 26, 2026 at 5:31 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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

Okay, we can keep the column.

>
> 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?
>

You’re right, the name isn’t apt.

I tried to look into remote-origin capturing: we don’t capture that
today. apply_handle_origin() is essentially a no-op; it only checks
msg ordering and doesn’t even call logicalrep_read_origin(), so the
incoming origin name is discarded. And the publisher sends the ORIGIN
message only when the change has a non-local (non-null) origin (i.e.
it was itself replicated into the publisher from another source), so
it wouldn’t be set for the common case anyway. So I’m not sure we
should store it. I’d lean toward renaming the current column to
something more apt. How about it as apply_origin:"the origin the
change was applied under" or subscription_origin?

thanks
Shveta