postgres home directory, /var/lib/postgresql, owned by root again

In 18+, /var/lib/postgresql is the mount target and still the postgres user's home directory. This brings back #274 (fixed by #277) when doing a bind mount on a new directory.

I have this issue again with v18. I started over with a fresh container and newly created volumes. This is my compose file:

services:

  db:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=redacted
      - TZ=Europe/Berlin
      - PGTZ=Europe/Berlin
    volumes:
      - /mnt/storage/postgres-data:/var/lib/postgresql
    ports:
      - "5432:5432"

Originally posted by @dkadioglu in #274

If the local directory for the bind mount (like /mnt/storage/postgres-data) doesn't exist before doing a docker compose up, then it will be automatically created by docker as root owned. If users need the .psql_history file, then they'll need to pre-create the directory locally (or chown/chmod after) with permissions such that the postgres user of the image can use it (uid/gid 70 in Alpine; uid/gid 999 in Debian); alternatively, they can run the image as a different user (e.g. user: 1000:1000) that already has permissions to access that directory on the host.

Now that 18 has moved the volume to /var/lib/postgresql/ instead of PGDATA, then it might make sense for us to chown or chmod it in the entypoint script so that the postgres user correctly owns or can at least use their home directory. 🤔 It could be a breaking change though, so we'll have to give it some thought.

Start with the entrypoint script and reproduce the bind-mount behavior using the compose file shown, including a newly created host directory. Determine how ownership and permissions differ for Alpine and Debian images; done means the postgres user can use its home directory without breaking existing volume behavior or introducing an unintended breaking change.