Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

From: Rui Zhao <zhaorui126(at)gmail(dot)com>
To: Ajin Cherian <itsajin(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
Date: 2026-07-05 16:09:55
Message-ID: CAHWVJhH4dtB-1rvoQNpjnbUZjQpEpKhhzMCK4oy0_+KDEQiwOg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-07-05 17:15:45 Re: GIN index fast list search may become un-interruptible for long time.
Previous Message Pavel Stehule 2026-07-05 15:46:10 Re: inconsistent jsonb 'null' conversions