Thread

Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

shveta malik <shveta.malik@gmail.com> — 2026-05-06T10:43:41Z

On Wed, May 6, 2026 at 11:13 AM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Thu, Apr 30, 2026 at 7:37 PM shveta malik <shveta.malik@gmail.com> 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