On Mon, Oct 26, 2026 at 5:31 PM Dilip Kumar <[email protected]> wrote: > > On Fri, Oct 23, 2026 at 12:31 PM Amit Kapila <[email protected]> wrote: > > > > On Thu, Oct 22, 2026 at 6:15 PM Dilip Kumar <[email protected]> wrote: > > > > > > On Thu, Oct 15, 2026 at 9:47 AM shveta malik <[email protected]> > > > wrote: > > > > > > > > On Wed, Oct 14, 2026 at 8:16 PM Nisha Moond <[email protected]> > > > > 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
