pg-upgrade-test: run ALTER EXTENSION UPDATE before binary pg_upgrade, not after

Reorders prepare-old -> update -> pg_upgrade -> run-suite (was prepare-old
-> pg_upgrade -> update -> run-suite). The old order proved pg_upgrade
could migrate 0.9.6's frozen objects, then updated afterward - not
actionable, since that version already shipped. This job's whole point is
proving pg_upgrade correctly migrates the objects count_nulls' CURRENT code
creates, which requires updating BEFORE the binary upgrade runs. make
install (into the old cluster) already happens earlier in the job, so the
current version's update scripts are on disk in time for the moved step.

Updates the job's step names/comments and bin/test_existing's own
file-header sequence description to match the new order.

Author: jnasbyupgrade

.github/workflows/ci.yml

@@ -17,15 +17,18 @@
 #                              per-PG-version container/checkout setup for
 #                              no added confidence.
 #   pg-upgrade-test         -- BINARY pg_upgrade: install 0.9.6 on an OLD
-#                              PostgreSQL major, binary-upgrade the cluster
-#                              to a NEWER major, then update the extension
-#                              to current - proves objects created on an
-#                              old server still work when read on a new
-#                              one. A smaller old_pg/new_pg matrix (not the
-#                              full PG matrix - by far the most expensive
-#                              job here, installing two full PostgreSQL
-#                              majors and running the real pg_upgrade
-#                              binary per leg).
+#                              PostgreSQL major, update the extension to
+#                              current (still on the old major), THEN
+#                              binary-upgrade the cluster to a NEWER major -
+#                              proves pg_upgrade correctly migrates the
+#                              objects the extension actually creates
+#                              TODAY, not objects frozen at some past
+#                              version (which would be untestable anyway -
+#                              that old version already shipped). A smaller
+#                              old_pg/new_pg matrix (not the full PG matrix
+#                              - by far the most expensive job here,
+#                              installing two full PostgreSQL majors and
+#                              running the real pg_upgrade binary per leg).
 #   pg-tle-test             -- pg_tle DEPLOYMENT: fresh install registered
 #                              through AWS pg_tle's database-backed catalog
 #                              instead of a filesystem .control file.
@@ -213,13 +216,19 @@ jobs:
         run: make verify-results TEST_LOAD_SOURCE=update
 
   # Proves count_nulls survives a BINARY pg_upgrade (in-place catalog
-  # migration to a newer PostgreSQL major), not just an in-place extension
-  # update. Installs 0.9.6 on an old cluster, plants a dependency guard,
-  # binary-pg_upgrades to a newer cluster, updates the extension to current,
+  # migration to a newer PostgreSQL major). Installs 0.9.6 on an old
+  # cluster, plants a dependency guard, updates the extension to CURRENT
+  # (still on the old major), THEN binary-pg_upgrades to a newer cluster,
   # then runs the suite against the REAL migrated objects in existing mode.
-  # No bridge-update step first: count_nulls has always been pure SQL
-  # functions with no SELECT-*-over-catalog views, so it has no known
-  # pg_upgrade-unsafe old version to bridge past.
+  # Updating before the binary upgrade (not after) is deliberate: the whole
+  # point of this job is proving pg_upgrade correctly migrates the objects
+  # count_nulls' CURRENT code actually creates - migrating 0.9.6's objects
+  # and updating afterward would instead test whether pg_upgrade can
+  # migrate a legacy structure frozen in the past, which isn't actionable
+  # (that version already shipped; nothing to fix if it turned out
+  # fragile). No bridge-update step first: count_nulls has always been
+  # pure SQL functions with no SELECT-*-over-catalog views, so it has no
+  # known pg_upgrade-unsafe old version to bridge past.
   #
   # Deliberately not doing a stepwise every-major-in-sequence climb (one
   # cluster walking 10->11->12->...->newest, vs. the single big jumps here):
@@ -268,6 +277,17 @@ jobs:
         # in this job cannot silently make the eventual existing-mode run
         # test a fresh install instead.
         run: bin/test_existing prepare-old count_nulls_upgrade "" 0.9.6
+      - name: Update the extension to the current version (still on the old cluster)
+        # Exercises ALTER EXTENSION UPDATE on the OLD cluster, BEFORE the
+        # binary pg_upgrade below, running the 0.9.6->stable update script -
+        # deliberately in this order (not update-after-upgrade): this job
+        # exists to prove pg_upgrade correctly migrates the objects
+        # count_nulls' CURRENT code creates, so pg_upgrade must run against
+        # already-current objects, not 0.9.6 ones. `make install` above
+        # already installed the current version's update scripts/control
+        # file into this (old) cluster's sharedir, so they're in place for
+        # this ALTER EXTENSION UPDATE to use.
+        run: bin/test_existing update count_nulls_upgrade
       - name: Install PostgreSQL ${{ matrix.new_pg }}
         run: apt-get install -y postgresql-${{ matrix.new_pg }} postgresql-server-dev-${{ matrix.new_pg }}
       - name: Install count_nulls into new cluster
@@ -294,18 +314,13 @@ jobs:
                       /var/lib/postgresql/${{ matrix.new_pg }}/test/pg_upgrade_output.d \
                       -name '*.log' 2>/dev/null | sort | xargs -r tail -n +1; exit 1; }
           pg_ctlcluster ${{ matrix.new_pg }} test start
-      - name: Update the pg_upgraded extension to the current version
-        # Exercises ALTER EXTENSION UPDATE on genuinely pg_upgraded objects
-        # (the extension binary pg_upgrade just migrated), running the
-        # 0.9.6->stable update script.
-        run: bin/test_existing update count_nulls_upgrade
       - name: Run the suite against the pg_upgraded database (existing mode)
         # run-suite asserts the version, re-proves the dependency guard
-        # still blocks a non-CASCADE drop (i.e. it survived pg_upgrade),
-        # drops the guard, then runs the suite against the REAL pg_upgraded
-        # + updated database via --use-existing (so pg_regress does not
-        # drop/recreate it) - a plain fresh `make test` would silently test
-        # a fresh install instead of the migrated objects.
+        # still blocks a non-CASCADE drop (i.e. it survived both the update
+        # and pg_upgrade), drops the guard, then runs the suite against the
+        # REAL pg_upgraded database via --use-existing (so pg_regress does
+        # not drop/recreate it) - a plain fresh `make test` would silently
+        # test a fresh install instead of the migrated objects.
         run: bin/test_existing run-suite count_nulls_upgrade ""
 
   pg-tle-test:

bin/test_existing

@@ -12,11 +12,17 @@
 #
 # The pg-upgrade-test CI job repeats the same sequence:
 #
-#   prepare-old (install + plant guard) -> [real pg_upgrade binary, in CI] ->
-#   update (ALTER EXTENSION UPDATE) -> run-suite (assert + run existing-mode)
+#   prepare-old (install + plant guard) -> update (ALTER EXTENSION UPDATE,
+#   on the OLD cluster, before pg_upgrade) -> [real pg_upgrade binary, in
+#   CI] -> run-suite (assert + run existing-mode)
 #
-# so it lives here once instead of being duplicated as inline YAML. Not
-# CI-only: a developer can run any subcommand locally against a scratch
+# so it lives here once instead of being duplicated as inline YAML. update
+# runs BEFORE the binary pg_upgrade, not after: the point of this job is
+# proving pg_upgrade correctly migrates the objects count_nulls' CURRENT
+# code creates, so pg_upgrade needs to run against already-current objects,
+# not ones still frozen at the old INSTALL_VERSION.
+#
+# Not CI-only: a developer can run any subcommand locally against a scratch
 # database. Modeled on Postgres-Extensions/cat_tools's bin/test_existing.
 # Two differences from that script: count_nulls ships no
 # SELECT-*-over-catalog views, so it has no known pg_upgrade-unsafe old