On Wed, May 6, 2026 at 11:13 AM Ajin Cherian <[email protected]> wrote: > > On Thu, Apr 30, 2026 at 7:37 PM shveta malik <[email protected]> wrote: > > > > > > I’m not sure how preserving the subscription OID would ensure that the > > origin ID is also preserved for sub-associated origins. Could you > > please elaborate? > > > > As I understand it, roident values are assigned independently during > > origin creation. Even if subscription OIDs are preserved, the origin > > IDs could still be reassigned differently on the new cluster. For > > example, suppose we have two subscriptions, sub1 and sub2, with > > roident values 2 and 3, assuming 1 was previously used and dropped. > > After upgrade, origin creation may start allocating from 1 again, > > resulting in roident values 1 and 2 instead. Since pg_commit_ts stores > > the numeric roident, not the origin name, this mismatch could still > > lead to incorrect conflict detection. Wouldn’t that result in the same > > wrong conflict detection issue we are trying to avoid? > > Please let me know if my understanding is wrong. > > In the first patch, the replication origins were duplicated from the > old cluster to the new with matching roidents and ronames. This > couldn't be done for subscription replication origins as subscriptions > weren't preserving OIDs on the new cluster and therefore the > corresponding roname which is derived from the subscription OIDs also > differed.
Okay. I think you did not post the first patch you are referring to here. V2 was posted directly. But I see your point. > Now with matching roname and roident, all the replication > origins from the old cluster can be copied over to the new cluster in > one shot. Okay. Will review the patch. thanks Shveta
