| 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
| 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 |