[Unknown] Unable to start PostgreSQL containers after trixie

[OdinVex]

Seems something has changed with PGDATA and everything's broken about it with the latest docker image. I can't start the containers to even maintain them/fix them, any suggestions besides doing this version migration mounting stuff (PG_MAJOR weird idea that won't be used)?

[OdinVex]

This is related to #1259.

[OdinVex]

Actual error:

Failed to deploy a stack: compose up operation failed: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "<POSTGRESQL_PATH>" to rootfs at "/var/lib/postgresql/data": change mount propagation through procfd: open o_path procfd: open /<DOCKER ROOT>/overlay2/17561d31d0730b3fd3071752d82cf8fe60b2ea0ed84521c6ee8b06427ca8f064/merged/var/lib/postgresql/data: no such file or directory: unknown

[OdinVex]

Turns it out's the way the data folder is linked, breaks mounting over it. I simply overwrote PGDATA and chose a different folder for now.

    environment:
        - PGDATA=/VERSION_FOLDERS_SUCK/data
...
    volumes:
        - <POSTGRESQL_PATH>:/VERSION_FOLDERS_SUCK/data:rw

I then hijacked the entrypoint (entrypoint: /bin/sh, set stdin_open and tty to true) to run a shell so I could upgrade the database, since there's no way to fix this issue otherwise. Edit: At the moment I can't pg_upgrade, but I'm tinkering to figure it out.

[OdinVex]

Screw it, sticking to docker.io/postgres:17 permanently.

[notarobot63]

Same error here, going from latest to 17 did the trick

[beanbeanjuice]

Getting the exact same error.

[dumiensky]

Same issue on postgres:latest

[maxidorius]

+1 same error

[AdamLBS]

Same error here

[hexxone]

Big oof. Thats the stupidist change I have seen postgres make in a while.

There should NEVER be a "latest" docker tag if you decide that breaking changes on this tag will STOP THE CONTAINER from even starting.

Postgres should have chosen a way where backward compatibilty doesnt suddenly break with a random update and cost me 2 hours of troubleshooting for a problem which looks like my fileystem is broken. I almost had a heart attack there. Thanks.

[iz0eyj]

+1

Please check the containers before releasing them; I don’t understand how a problem like this could have gone unnoticed.
Apparently, the only solution is to roll back to version 17.

[ImreSamu]

There has been a change with PG18 + PGDATA,
described in the documentation under PGDATA + “Important Change”:

• https://github.com/docker-library/docs/tree/master/postgres#pgdata
  • Change PGDATA in 18+ to /var/lib/postgresql/MAJOR/docker #1259

The key point:
* For version 18 the path is : /var/lib/postgresql/18/docker

[OdinVex]

Yes, but upgrading in this Docker isn't possible out-of-box, breaking installations, even if PGDATA is specified. The container is almost pointless because of it. A compromise would be to provide two containers per version, one including just the latest, the other including the latest and previous with automatic backing up of databases and upgrades. PostgreSQL updating is...just whack. Requiring old version server binaries just to upgrade a DB...needs a redesign and commitment to forward-compatibility. Perfect otherwise..

[yosifkit]

Requiring old version server binaries just to upgrade a DB...needs a redesign and commitment to forward-compatibility.

I agree that it is a design that isn't suited for containers. You'll have to take that up on the PostgreSQL mailing lists, they don't really visit our repo for containerizing it.

The recent change of PGDATA and the related VOLUME is to better align the image with how upstream PostgreSQL expects users to run PostgreSQL server and to make future major upgrades easier (#1259 (comment)).