[travismolick]

Summary

The Postgres 18 upgrade (140132d) updated the dev Compose file and the wiki example to mount the data volume at /var/lib/postgresql, but docker-compose.prod.yml still mounted it at /var/lib/postgresql/data. Postgres 18 images keep their data in a versioned subdirectory (/var/lib/postgresql/18/docker) and exit at startup when anything is mounted at the old path, even an empty volume:

data in /var/lib/postgresql/data (unused mount/volume)

So the production stack can't start Postgres at all on main right now.

Changes

• docker-compose.prod.yml: mount the postgres volume at /var/lib/postgresql.
• wiki/Setup-(Docker).md, Postgres upgrades section:
  • Note the new mount path and the startup error, and say to change the image tag and the mount path together.
  • Remove the container with docker compose rm --stop --force postgres instead of just stopping it. Docker won't delete a volume that a stopped container still references.
  • Recreate the container with docker compose up -d postgres instead of docker compose start postgres. start would restart the old container, whose volume was deleted.

Upgrade notes

• New installs: no action needed.
• Existing stacks with pre-18 data in the old volume: dump the database, change the mount path and image together, recreate the volume and restore, following the updated wiki steps.

Testing

• Started a throwaway postgres:18 container with a volume at /var/lib/postgresql/data: it exits with the error above, even with an empty volume.
• Started the same container with the volume at /var/lib/postgresql: it initializes and starts normally, with PGDATA at /var/lib/postgresql/18/docker.

[Earthmark]

Makes sense and I ran into the same issue in another repo. As long as the migration has allready happened this seems fine (and the version is already 18 in the compose file, looks like it has).

Seems the migration procedure was already listed, I'm worried about data loss because it says delete the volume, but it's true and correct.