Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Ajin Cherian <itsajin(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shvetamalik(at)gmail(dot)com>
Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
Date: 2026-05-06 10:43:41
Message-ID: CAJpy0uCok7LCLUYXX1B5hSW2Gy1ow+jB5vPLzpHgXMkzWf5dAw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amul Sul 2026-05-06 10:52:20 Question: Should we release the FK fast-path pk_slot's buffer pin promptly?
Previous Message Amit Kapila 2026-05-06 10:31:41 Re: Proposal: Conflict log history table for Logical Replication