Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
Rui Zhao <zhaorui126@gmail.com>
From: Rui Zhao <zhaorui126@gmail.com>
To: Ajin Cherian <itsajin@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Zsolt Parragi <zsolt.parragi@percona.com>
Date: 2026-07-05T16:09:55Z
Lists: pgsql-hackers
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.
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.
Minor, in that same hunk: the dumpReplicationOrigins(conn) call isn't indented
under its if.
Otherwise v10 reads well; the other reviewers' comments all look addressed.
Zsolt, a small request -- could you use reply-all on the thread? A couple of
times the CC list got narrowed, and when the reply chain continued from there
I dropped off it and missed the update. Keeping everyone CC'd helps the rest
of us stay in the loop.
Thanks,
Rui
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Introduce replication progress tracking infrastructure.
- 5aa2350426c4 9.5.0 cited