fix: cover the old default value 1.6 (same as 1.6.4) with empty migration#2213
Closed
samrose wants to merge 2 commits into
Closed
fix: cover the old default value 1.6 (same as 1.6.4) with empty migration#2213samrose wants to merge 2 commits into
samrose wants to merge 2 commits into
Conversation
PostgreSQL Extension Dependency Analysis: PR #2213
SummaryNo extensions had dependencies with MAJOR version updates. Full Analysis ResultsPostgreSQL 15 Extension DependenciesPostgreSQL 17 Extension DependenciesOrioleDB 17 Extension Dependencies |
PostgreSQL Package Dependency Analysis: PR #2213
SummaryNo packages had MAJOR version updates. Full Analysis ResultsPostgreSQL 15 Dependency ChangesExtracting PostgreSQL 15 dependencies...
Runtime Closure Size
Raw Dependency ClosurePostgreSQL 17 Dependency ChangesExtracting PostgreSQL 17 dependencies...
Runtime Closure Size
Raw Dependency Closure |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
previously, the build scripts from pg_cron extension had output migrations patterned like 1.5-1.6 etc
recently we rewrote the packages to support multiple versions, and in the process did not have coverage for this form of extension version.
This adds an empty migration from 1.6 - 1.6.4 to cover where people have the previous version signature.
pg_cron upgrade-alias coverage: deployed fleet vs. what the test exercises
Scope
This is strictly about the extension version-upgrade step not failing: every extversion string a live project can report must successfully run
ALTER EXTENSION pg_cron UPDATEand land on the latest version. It does not assert anything about row-level data carried through the upgrade.The deployed fleet
A query of active projects by
pg_cronextversion:1.6.41.61.4-11.41.5Four of the five are legacy short-form strings that
versions.jsonnever lists (it only knows1.3.1, 1.4.2, 1.5.2, 1.6.4). The canonicalcheck_upgrade_pathtest therefore never touched1.6,1.4-1,1.4, or1.5. These ~93k projects were untested before this PR.Why these legacy strings exist
nix/ext/pg_cron/default.nixrenames upstream's scripts to Supabase's canonical version strings, then lays down symlink aliases so a cluster reporting an old short-form extversion still has a valid upgrade path. For example:pg_cron--1.4--1.4-1.sql-> symlink topg_cron--1.4.0--1.4.1.sql(default.nix:75)pg_cron--1.4-1--1.5.sql-> symlink topg_cron--1.4.2--1.5.2.sql(default.nix:76)Postgres builds its version graph from filenames, so these aliases are real, traversable edges. They are what let a
1.4-1project move forward.How the test covers every deployed version
check_all_upgrade_edges(lib.py:193) discovers the on-disk script graph, computes which versions a real cluster can actually sit at (_reachable_versions, lib.py:175), then runs two passes:Pass 1, per-script coverage (lib.py:247-251): for every reachable edge
A--B, installAfrom scratch andUPDATE TO 'B'. This guarantees each individual alias script body executes at least once, so a broken script cannot hide behind Postgres's shortest-path routing.Pass 2, full upgrade to latest (lib.py:253-258): for every reachable version
V, installVfrom scratch and run a singleUPDATE TO '1.6.4', asserting it lands on latest. This is the direct simulation of what a deployed project atVexperiences.Mapping the fleet to the test:
1.6.41.61.6 -> 1.6.4asserted1.4-11.4-1 -> 1.5,1.4-1 -> 1.5.2) + Pass 2 (1.4-1 -> 1.6.4)1.41.4 -> 1.4-1) + Pass 2 (1.4 -> 1.6.4)1.51.5 -> 1.6,1.5 -> 1.6.4) + Pass 2 (1.5 -> 1.6.4)Every deployed version is an explicit, asserted test case.
Why
1.4-1(3,363 projects) is faithfully tested1.4-1is a reachable node (incoming edge1.4 -> 1.4-1, default.nix:75), so the test can build it withCREATE EXTENSION pg_cron VERSION '1.4-1'and then run the exactALTER EXTENSION pg_cron UPDATE TO '1.6.4'a real project would run, asserting success. The same install role is used as in production: the VM test connects assupabase_admin, which is the role the dashboard's pg-meta service uses to create and upgrade extensions.What is intentionally not tested, and why that is correct
Two edges are skipped because their source version is unreachable, meaning no cluster, fresh or upgraded, can ever sit at it:
1.0(no base script, no incoming edge) and1.4.0(likewise). Neither appears in the fleet, which is consistent with them being unreachable. Their script bodies still get coverage because each is a symlink to, or shares its body with, a reachable alias that Pass 1 runs (1.0--1.1aliases1.0.0--1.1.0;1.4.0--1.4.1shares its body with the reachable1.4--1.4-1). They exist only to keep the version graph connected, which is a packaging property, not an upgrade any real project performs.Verification
The reachable set computed from the exact
default.nixscript graph is:All 13 non-latest reachable versions, including all four deployed legacy strings, have a verified forward path to
1.6.4. None are stranded. CI confirms this:pg_cron - Postgres 15 (x86_64-linux)is green on the latest run, where the priorAssertionErrorwould have failed identically.