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