Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

shveta malik <shveta.malik@gmail.com>

From: shveta malik <shveta.malik@gmail.com>
To: Rui Zhao <zhaorui126@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, pgsql-hackers@lists.postgresql.org, Zsolt Parragi <zsolt.parragi@percona.com>, shveta malik <shveta.malik@gmail.com>
Date: 2026-07-06T03:31:26Z
Lists: pgsql-hackers
On Sun, Jul 5, 2026 at 9:40 PM Rui Zhao <zhaorui126@gmail.com> wrote:
>
> Hi Ajin,
>
> Thanks for v10. On the version gating I asked about earlier -- I think it's
> now moot, and the gates can come back out.
>
> Since v10, 14d8418083 ("Remove pg_upgrade support for upgrading from pre-v10
> servers") raised pg_upgrade's minimum source version to v10.
> pg_replication_origin has existed since 9.5, so every cluster pg_upgrade now
> accepts already has it, and the original unconditional
> get_replication_origin_info() is safe again. Both gates that went into v10 are
> now always true:
>
>   - check.c:      if (GET_MAJOR_VERSION(old_cluster.major_version) >= 905)
>   - pg_dumpall.c: if (server_version >= 90500)   -- only reached under
>                   binary_upgrade, i.e. against the v10+ old cluster
>
> 14d8418083 was itself removing exactly this kind of pre-v10 version check
> across pg_upgrade, so dropping these fits the same cleanup.
>

Thanks for pointing to the commit.

> v10 doesn't apply on current master anyway (0002 fails on pg_proc.dat), so
> could you post a rebase? That'd let it be built and tested against HEAD, and
> it's a natural point to drop the two gates and go back to the unconditional
> calls.

I can apply v10 on the latest HEAD (9d1188f298), can you please try it again?

thanks
Shveta



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Introduce replication progress tracking infrastructure.