Add missing upgrade paths: 0.5.1→0.6.0 and 0.6.1→1.0.0-dev#282
Add missing upgrade paths: 0.5.1→0.6.0 and 0.6.1→1.0.0-dev#282
Conversation
- 0.5.1→0.6.0: adds bm25_force_merge function (same as 0.5.0→1.0.0-dev) - 0.6.1→1.0.0-dev: no schema changes, version check only
Add the upcoming 0.6.1 release to the old_version matrix so upgrade paths from 0.6.1 are tested once the release is published.
There was a problem hiding this comment.
LGTM — the new upgrade scripts follow the established patterns exactly, and the Makefile additions are straightforward.
Extended reasoning...
Overview
This PR adds two missing PostgreSQL extension upgrade path SQL scripts (0.5.1→0.6.0 and 0.6.1→1.0.0-dev), registers them in the Makefile DATA list, and adds 0.6.1 to the CI upgrade test matrix.
Security risks
None. The SQL scripts contain only version-check DO blocks and a single CREATE FUNCTION ... AS 'MODULE_PATHNAME' call that references an existing C function (tp_force_merge). No user input handling, no dynamic SQL, no permission changes.
Level of scrutiny
Low scrutiny is appropriate. These are mechanical, pattern-following changes. I verified the new scripts against their closest existing equivalents (0.5.0--1.0.0-dev.sql and 0.6.0--1.0.0-dev.sql) and confirmed they match exactly in structure and content — the only differences are the version strings and the presence/absence of bm25_force_merge (correctly included in 0.5.1→0.6.0 and correctly omitted in 0.6.1→1.0.0-dev).
Other factors
The one nit found by the bug hunter (CI will fail for the unreleased v0.6.1 download) is accurate but low-impact: fail-fast: false ensures all other matrix entries still pass, and the failing jobs will auto-resolve once v0.6.1 is released. This is a reasonable sequencing choice if the release is imminent, and does not block approval.
| matrix: | ||
| pg_version: [17, 18] | ||
| old_version: ['0.2.0', '0.3.0', '0.4.0', '0.4.1', '0.4.2', '0.5.0', '0.5.1', '0.6.0'] | ||
| old_version: ['0.2.0', '0.3.0', '0.4.0', '0.4.1', '0.4.2', '0.5.0', '0.5.1', '0.6.0', '0.6.1'] |
There was a problem hiding this comment.
🟡 Adding 0.6.1 to the old_version matrix will cause 2 CI jobs (PG 17 + PG 18) to fail because v0.6.1 has not been released yet and the "Download old release" step exits with code 1 when the GitHub release artifact doesn't exist. Consider adding 0.6.1 to the matrix only after the release is published, or adding continue-on-error: true / a conditional skip for versions whose release tarball is not yet available.
Extended reasoning...
What the bug is
The PR adds 0.6.1 to the old_version list in the upgrade test matrix at line 26 of .github/workflows/upgrade-tests.yml. However, v0.6.1 has not been released yet — the PR description itself says "upcoming 0.6.1 bugfix release" and instructs to "Cherry-pick to the release-0.6.1 branch after merge."
How it manifests
The "Download old release" step (lines 42–53) constructs a download URL of the form https://github.com/timescale/pg_textsearch/releases/download/v0.6.1/pg_textsearch-0.6.1.tar.gz. Since this release does not exist, the curl -fsSL call will fail (the -f flag causes curl to return a non-zero exit code on HTTP errors). The workflow then hits the else branch which prints an error and runs exit 1, failing the job.
Step-by-step proof
- CI triggers on this PR because
upgrade-tests.ymlis in the changed paths. - The matrix expands to include
old_version: 0.6.1for bothpg_version: 17andpg_version: 18. - For these two matrix entries, the "Download old release" step runs
curl -fsSL -o pg_textsearch-old.tar.gz "https://github.com/timescale/pg_textsearch/releases/download/v0.6.1/pg_textsearch-0.6.1.tar.gz". - The release URL returns 404 because v0.6.1 has not been published.
curl -fsSLreturns a non-zero exit code, so theifcondition fails and theelsebranch executesexit 1.- Both matrix jobs fail with red status.
Impact
Because fail-fast: false is set, the other matrix entries (0.2.0 through 0.6.0) still run normally. The impact is limited to 2 red CI jobs in the matrix, which is a cosmetic/noise issue rather than a code correctness problem. The actual upgrade SQL scripts added by this PR are correct.
How to fix
Either (a) remove 0.6.1 from the matrix now and add it back after the v0.6.1 release is published, or (b) add a graceful skip mechanism to the download step, such as continue-on-error: true on the download step with a subsequent if: steps.download.outcome == 'success' condition on later steps.
Summary
0.5.1→0.6.0upgrade script (addsbm25_force_mergefunction)0.6.1→1.0.0-devupgrade script (version check only, no schema changes)The 0.5.1→0.6.0 path was missing — users on 0.5.1 had no way to upgrade to 0.6.0. The 0.6.1→1.0.0-dev path is needed so users on the upcoming 0.6.1 bugfix release can upgrade to the next dev version.
Testing
release-0.6.1branch after merge