Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

From: vignesh C <vignesh21(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
Date: 2026-04-30 06:51:54
Message-ID: CALDaNm2-uwpbJ8fnrssp+hORvOutsqRoZAsa05xVVzXe5Bt3bw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 29 Apr 2026 at 14:11, Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Ajin,
>
> > Sequence of Events During Upgrade
> >
> > 1. pg_dumpall dumps all non-subscription replication origins from the
> > old cluster with their roidents and LSN positions.
> > 2. pg_dump dumps each subscription, but now records the old roident
> > alongside the subscription info.
> > 3. During restore, pg_dumpall's output recreates non-subscription
> > origins on the new cluster with their original roidents via
> > binary_upgrade_create_replication_origin().
>
> To confirm, why do we have to handle separately for subscription-associated
> origins? I'm thinking it's not needed if the subscription's OID is preserved
> during the upgrade.

+1 to preserve the subscription OID. This should make preserving
replication origin easier.

> I checked the old thread to preserve it [1], but it could not be accepted because
> there are no strong motivations. But I feel this is the good reason to do so now.

Here is a rebased version of the patch.

Regards,
Vignesh

Attachment Content-Type Size
v1-0001-Preserve-subscription-OIDs-during-pg_upgrade.patch application/octet-stream 9.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2026-04-30 07:08:58 Re: First draft of PG 19 release notes
Previous Message Ayush Tiwari 2026-04-30 06:46:35 Re: [PATCH] Fix stale relation close in sequence synchronization