Skip to content

Upgrade bundled PostgreSQL to 18 with a safe migration path - #34

Merged
kilo666mj merged 3 commits into
mainfrom
postgres-18
Oct 18, 2026
Merged

kilo666mj merged 3 commits into
mainfrom
postgres-18

Conversation

@kilo666mj

Copy link
Copy Markdown
Owner

Replaces #33. The plain tag bump there would stop every Compose install, fresh ones included: the postgres:18 image moved PGDATA to /var/lib/postgresql/18/docker and its volume to /var/lib/postgresql, and its entrypoint exits when anything is mounted at the old /var/lib/postgresql/data (docker-library/postgres#1259).

Changes

  • compose.yaml: postgres:18-alpine (same digest as Update postgres Docker tag to v18 #33), volume mounted at /var/lib/postgresql. The volume name stays postgres-data on purpose: an existing PostgreSQL 17 volume makes the 18 container refuse to start with a clear error, instead of silently starting empty.
  • docs/operations.md: new "Upgrade PostgreSQL to a new major version" section: dump on the old revision, keep the old data in a rollback volume, start 18 alone, restore, then start Rendercase; plus rollback steps.
  • CI tests: go test -race -count=1. In Update postgres Docker tag to v18 #33 every package reported (cached), so the PostgreSQL integration tests never ran against 18.
  • CI compose job (new, permanent): starts PostgreSQL from compose.yaml on a fresh volume and checks the server major matches the image tag. Image publishing now depends on it, so a future major bump that breaks Compose fails here.

Rehearsal

The second commit adds a temporary workflow that runs the documented steps against a real PostgreSQL 17 volume seeded with internal/store/schema.sql and a row. It checks that 18 refuses the old volume, that data survives the dump/restore, that the startup schema re-applies cleanly on 18, and that the rollback path brings 17 back. It will be removed before merge.

🤖 Generated with Claude Code

kilo666mj and others added 3 commits October 18, 2026 11:46
The postgres:18 image moved PGDATA to /var/lib/postgresql/18/docker and
its volume to /var/lib/postgresql, and its entrypoint refuses to start
when anything is mounted at the old /var/lib/postgresql/data path. The
plain tag bump in #33 would therefore stop every Compose install,
including fresh ones.

- compose.yaml: postgres 18-alpine, volume mounted at /var/lib/postgresql.
  The volume name is unchanged on purpose: an existing PostgreSQL 17
  volume makes the 18 container refuse to start instead of silently
  coming up empty.
- docs/operations.md: dump/restore procedure for 17 -> 18, keeping the
  old data in a rollback volume, plus the rollback steps.
- CI: run go test with -count=1. The setup-go cache restored every
  package as "(cached)", so the PostgreSQL integration tests did not
  run against a new server version.
- CI: new "compose postgres" job starts PostgreSQL from compose.yaml on
  a fresh volume and checks the server major matches the image tag;
  image publishing now depends on it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Runs the docs/operations.md steps on a real PostgreSQL 17 volume. To be
removed before merge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The rehearsal passed on the PR (run 39116646413): PostgreSQL 18 refused
the old volume, the dump restored on 18, the startup schema re-applied,
and the rollback volume brought 17 back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kilo666mj kilo666mj mentioned this pull request Oct 18, 2026
1 task
@kilo666mj
kilo666mj merged commit 41ce9e4 into main Oct 18, 2026
10 checks passed
@kilo666mj
kilo666mj deleted the postgres-18 branch October 18, 2026 09:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant