Real pg_upgrade support via a reduced bin/test_existing - #31
Draft
jnasbyupgrade wants to merge 2 commits into
Draft
Real pg_upgrade support via a reduced bin/test_existing#31jnasbyupgrade wants to merge 2 commits into
jnasbyupgrade wants to merge 2 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
jnasbyupgrade
changed the title
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
from
August 4, 2026 18:44
8a6a467 to
d05ccf0
Compare
jnasbyupgrade
marked this pull request as draft
August 4, 2026 21:11
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
2 times, most recently
from
August 5, 2026 18:14
6c1d36f to
e64f80f
Compare
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
from
August 5, 2026 19:40
e64f80f to
fb1431a
Compare
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
2 times, most recently
from
August 5, 2026 22:49
a9c46c2 to
a791789
Compare
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
from
August 5, 2026 23:00
a791789 to
03c7af9
Compare
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
from
August 5, 2026 23:11
03c7af9 to
acba0ca
Compare
Adds the pg-upgrade-test CI job: install 0.9.6 on an old PostgreSQL major, plant + prove a dependency guard, binary pg_upgrade to a newer major, ALTER EXTENSION UPDATE the migrated objects, then run the suite against the real upgraded database in existing mode. bin/test_existing is much smaller than the equivalent script would have been pre-test/install: only prepare-old and run-suite are genuinely external-to-pg_regress concerns (a real pg_upgrade binary run isn't something pg_regress can invoke itself), plus a small `update` subcommand for the post-upgrade ALTER EXTENSION UPDATE step. There's no update-scenario subcommand at all - that entire scenario is just `make test-update` now (test/install/load.sql's own 'update' mode, added in phase 3), since an in-place update has no external step to drive. run_suite() gates on plain `make test`, not the old belt-and-suspenders `make test && make verify-results` - pgxntool 2.3.0 (this repo's phase 0) already made `make test` itself exit non-zero on regression failures. Not yet crossed with TEST_SCHEMA - that's the next phase, once both this job and extension-update-test can cross it together. Verified locally against PG17 (prepare-old -> update -> run-suite, without a real pg_upgrade - this container's clusters are persistent shared infra, so the actual binary pg_upgrade leg is left for CI's ephemeral containers, same reasoning as the pg-tle-test work). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… 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.
jnasbyupgrade
force-pushed
the
phase4-pg-upgrade
branch
from
August 5, 2026 23:16
acba0ca to
bc3c24e
Compare
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.
Stacked on #30 (phase 3.5: CI hygiene). Adds binary `pg_upgrade` coverage - the one U&U scenario that genuinely can't live inside a single `pg_regress` invocation, since `pg_upgrade` is an external binary process.
What changed
Not yet crossed with `TEST_SCHEMA` - that's the next phase, once both this job and `extension-update-test` can cross it together.
Verification
Locally against PG17: `prepare-old` → `update` → `run-suite` all pass end to end, without a real `pg_upgrade` (this container's PG12/PG17 clusters are persistent shared dev infra, not disposable, so - same reasoning as the earlier pg-tle-test work - the actual binary `pg_upgrade` leg is left for CI's ephemeral containers to exercise).