Summary
test/extension_upgrade.sh landed in #389 and is a good guard: it installs a released
build, creates a columnar table with rows, installs the tree under test over it, runs
ALTER EXTENSION UPDATE, and then requires reads, writes, table creation, a
maintenance call, and that every C function's link name is namespaced.
Nothing runs it.
The gap, precisely
It is listed in harness_selftest.sh's not_a_suite:
lib|portlib|run_all_versions|...|pg_upgrade|extension_upgrade) return 0 ;;
That exemption is correct -- it needs two builds and a restart, which the ordinary
suite contract cannot express, so it must not be in SUITES.
But look at what pg_upgrade gets in exchange. It is exempt from the registration
check and explicitly invoked by the runner:
test/run_all_versions.sh:505: if bash "$SRCDIR/test/pg_upgrade.sh" "$_old" "$_new" "$_mode" ...
That invocation is what closed #257, titled "Wire test/pg_upgrade.sh into an opt-in
gate (not per-PR) so #256's coverage doesn't rot".
extension_upgrade.sh has the exemption and not the invocation. So it is in
neither the matrix, nor CI, nor the Makefile:
$ grep -rn "extension_upgrade" .github/workflows/ Makefile
(nothing)
It runs only when a human types its name. That is the same gap #257 existed to close,
one suite over, and it is worth more here than there: the guard exists precisely
because the failure it catches is invisible until a user upgrades.
Second, smaller problem: it cannot run in the documented dev loop
The container loop copies the tree without .git (documented in
docs/testing.md), and the suite needs tags to find the old build:
FAIL v1.0-alpha is not present. Fetch tags, or pass an explicit ref:
git fetch --tags && test/extension_upgrade.sh <pg_config> <ref>
Reviewing #389 I had to copy .git into the container to exercise it at all. So even
a person who remembers to run it hits a wall in the standard environment.
What would fix it
- Invoke it from
run_all_versions.sh the way pg_upgrade.sh is invoked, on the
same opt-in terms, so the matrix covers it.
- Either let it take a non-git source for the old build (a tarball or an installed
prefix), or state in its header that it needs a real checkout with tags, so the
failure reads as a precondition rather than a bug.
Neither blocked #389, which is merged and green: full matrix PG18 + PG19 ALL VERSIONS PASSED, and I verified the upgrade path by hand. This is about the guard surviving
the next six months.
Summary
test/extension_upgrade.shlanded in #389 and is a good guard: it installs a releasedbuild, creates a columnar table with rows, installs the tree under test over it, runs
ALTER EXTENSION UPDATE, and then requires reads, writes, table creation, amaintenance call, and that every C function's link name is namespaced.
Nothing runs it.
The gap, precisely
It is listed in
harness_selftest.sh'snot_a_suite:That exemption is correct -- it needs two builds and a restart, which the ordinary
suite contract cannot express, so it must not be in
SUITES.But look at what
pg_upgradegets in exchange. It is exempt from the registrationcheck and explicitly invoked by the runner:
That invocation is what closed #257, titled "Wire test/pg_upgrade.sh into an opt-in
gate (not per-PR) so #256's coverage doesn't rot".
extension_upgrade.shhas the exemption and not the invocation. So it is inneither the matrix, nor CI, nor the Makefile:
It runs only when a human types its name. That is the same gap #257 existed to close,
one suite over, and it is worth more here than there: the guard exists precisely
because the failure it catches is invisible until a user upgrades.
Second, smaller problem: it cannot run in the documented dev loop
The container loop copies the tree without
.git(documented indocs/testing.md), and the suite needs tags to find the old build:Reviewing #389 I had to copy
.gitinto the container to exercise it at all. So evena person who remembers to run it hits a wall in the standard environment.
What would fix it
run_all_versions.shthe waypg_upgrade.shis invoked, on thesame opt-in terms, so the matrix covers it.
prefix), or state in its header that it needs a real checkout with tags, so the
failure reads as a precondition rather than a bug.
Neither blocked #389, which is merged and green: full matrix PG18 + PG19
ALL VERSIONS PASSED, and I verified the upgrade path by hand. This is about the guard survivingthe next six months.