From 5658c33b32d7f63f5b6d4a7551f630cbee3ee44f Mon Sep 17 00:00:00 2001 From: Ruben Fiszel Date: Wed, 26 Aug 2026 20:15:15 +0000 Subject: [PATCH] docs: warn that pinning back to postgres 16 needs the mount reverted too Reverting only the image tag leaves 16 running against the 18-style mount, where PGDATA is a subdirectory of the volume rather than its root. 16 then initdbs a fresh cluster there and Windmill boots against an empty database while the real one sits unread at the volume root. Verified: container exits 0, runs, and the pre-existing table is gone from its view. Every other path in this change fails loudly; this was the exception. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt --- docker-compose.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docker-compose.yml b/docker-compose.yml index bd1e060f22..694cbf2afb 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -15,6 +15,10 @@ services: ## its RLS policies to cluster-level roles, and a single-database dump loses both ## silently. Full procedure, and why 16 is still a valid choice until Nov 2028: ## https://www.windmill.dev/docs/advanced/self_host#upgrade-postgresql-to-18 + ## Pinning back to postgres:16 means reverting the mount below as well. 16 against + ## the 18-style mount initdbs a fresh cluster into a subdirectory of db_data and + ## comes up blank, the one path here that fails quietly instead of loudly. The + ## original cluster is still at the volume root, unread, so it is recoverable. db: deploy: # To use an external database, set replicas to 0 and set DATABASE_URL to the external database url in the .env file