fix(entrypoint): pre-upgrade dump never blocks startup (pg_dump17 vs PG18) #140

Merged

fastie81 merged 1 commit from fix/pgdump-version-mismatch into main

2026-09-06 20:10:30 +12:00

fastie81 commented

2026-09-06 20:06:57 +12:00

Owner

Problem (caught in deploy-to-test)

The PG18 fix deploy put postgres:18 up and healthy, but the app container crash-looped. Root cause: the app image ships postgresql-client 17, and pg_dump refuses to target a 18 server (server version mismatch). The pre-upgrade dump step runs under set -e, so its failure killed the entire entrypoint every boot — meaning auto-restore (pg15 → pg18) and migrations never ran.

Fix

The pre-upgrade dump is a safety net, not the upgrade path (the upgrade restores the PRIOR-major dump). Now: if pg_dump cannot target the server, log the reason, touch the per-major done marker (so it's not retried each boot), and continue to restore → migrate → start.

Failure of the current-major dump no longer blocks startup.
pg_restore reading a prior-major (pg15) dump into the 18 server is unaffected (client 17 safely reads 15-format and writes to 18).
Migrations/RLS/start run after restore as before.

Why safe

Isolated to the pre-upgrade dump guard; the actual restore/migrate/RLS path is untouched.
Once on PG18, the safety dump for 18 may not be taken by the 17 client (logged+skipped), but that's optional — the earlier-major dump and the retained volume remain the recovery source. (A later uncontional postgresql-client-18 in the image can restore dump-18 stalwe, tracked separately.)
Merge triggers deploy to TEST only; prod untouched until a v-tag.

## Problem (caught in deploy-to-test) The PG18 fix deploy put postgres:18 up and healthy, but the **app container crash-looped**. Root cause: the app image ships `postgresql-client` **17**, and `pg_dump` refuses to target a **18** server (server version mismatch). The pre-upgrade dump step runs under `set -e`, so its failure killed the entire entrypoint every boot — meaning **auto-restore (pg15 → pg18) and migrations never ran**. ## Fix The pre-upgrade dump is a **safety net, not the upgrade path** (the upgrade restores the PRIOR-major dump). Now: if `pg_dump` cannot target the server, log the reason, touch the per-major done marker (so it's not retried each boot), and **continue** to restore → migrate → start. - Failure of the current-major dump no longer blocks startup. - `pg_restore` reading a prior-major (pg15) dump into the 18 server is unaffected (client 17 safely reads 15-format and writes to 18). - Migrations/RLS/start run after restore as before. ## Why safe - Isolated to the pre-upgrade dump guard; the actual restore/migrate/RLS path is untouched. - Once on PG18, the safety dump for 18 may not be taken by the 17 client (logged+skipped), but that's optional — the earlier-major dump and the retained volume remain the recovery source. (A later uncontional postgresql-client-18 in the image can restore dump-18 stalwe, tracked separately.) - Merge triggers deploy to TEST only; prod untouched until a v-tag.

fastie81 added 1 commit

2026-09-06 20:06:59 +12:00

fix(entrypoint): pre-upgrade dump must never block startup (pg_dump 17 vs PG18)

CI / test (push) Successful in 2m13s

Details

CI / lint-frontend (push) Successful in 1m1s

Details

CI / build (push) Has been skipped

Details

CI / deploy (push) Has been skipped

Details

cd465a24cf

The app image ships postgresql-client 17; against a postgres:18 server the
pre-upgrade pg_dump aborts with a version-mismatch error.  Under set -e that
killed the whole entrypoint on every boot, so the auto-restore (pg15 dump ->
fresh PG18) and migrations never ran and the app crash-looped.

The pre-upgrade dump is a safety net, not the upgrade path (which restores the
PRIOR-major dump).  Now: if pg_dump cannot target this server, log the reason,
mark the per-major done marker so it is not retried every boot, and CONTINUE to
restore+migrate+start.

fastie81 merged commit bfd703f296 into main

2026-09-06 20:10:30 +12:00