Follow-up to #256, which added a solid test/pg_upgrade.sh (proven on 17->18 copy+link and 15->16) but leaves it un-wired: it is in not_a_suite and nothing runs it, so like native_scale before it, the coverage exists only when someone remembers.
Constraint: opt-in, not every run
It should not run on every PR or in the default matrix. It needs two majors built with the extension preloaded, runs pg_upgrade twice (per mode), and is expensive — the same reason it correctly can't be a one-config-per-suite matrix entry (run_san is the precedent). The goal is a home that is runnable and documented, not one that fires per-commit.
Options (any one closes this)
- Opt-in CI job: a
workflow_dispatch (manual) and/or scheduled (nightly) job — not on pull_request/push — that runs at least one pair (17->18) in both copy and link mode. Free arm/x86 runners make a nightly cheap.
- Opt-in local invocation, documented: record
test/pg_upgrade.sh OLD_PG_CONFIG NEW_PG_CONFIG [copy|link] in the release-gate checklist next to run_san, so a release run exercises it deliberately. A PGC_RUN_UPGRADE=1-style flag on the matrix that, when set, runs one pair after the majors are built would also work — off by default.
- Either way, write it into the gate documentation so it isn't forgotten (this is the failure mode that made
native_scale dark).
Acceptance
pg_upgrade.sh is invoked by some automated-or-checklisted gate that is opt-in (not per-PR), covering >= 1 major pair in both copy and link mode.- The invocation is recorded in the release procedure / gate docs so it cannot silently rot.
Part of the CI-extension theme in #243. Non-blocking for #256 itself, which is correct as a standalone suite.
Follow-up to #256, which added a solid
test/pg_upgrade.sh(proven on 17->18 copy+link and 15->16) but leaves it un-wired: it is innot_a_suiteand nothing runs it, so likenative_scalebefore it, the coverage exists only when someone remembers.Constraint: opt-in, not every run
It should not run on every PR or in the default matrix. It needs two majors built with the extension preloaded, runs
pg_upgradetwice (per mode), and is expensive — the same reason it correctly can't be a one-config-per-suite matrix entry (run_sanis the precedent). The goal is a home that is runnable and documented, not one that fires per-commit.Options (any one closes this)
workflow_dispatch(manual) and/or scheduled (nightly) job — not onpull_request/push— that runs at least one pair (17->18) in both copy and link mode. Free arm/x86 runners make a nightly cheap.test/pg_upgrade.sh OLD_PG_CONFIG NEW_PG_CONFIG [copy|link]in the release-gate checklist next torun_san, so a release run exercises it deliberately. APGC_RUN_UPGRADE=1-style flag on the matrix that, when set, runs one pair after the majors are built would also work — off by default.native_scaledark).Acceptance
pg_upgrade.shis invoked by some automated-or-checklisted gate that is opt-in (not per-PR), covering >= 1 major pair in both copy and link mode.Part of the CI-extension theme in #243. Non-blocking for #256 itself, which is correct as a standalone suite.