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