jj9987

The error message says quite clearly, that Counter to that, there appears to be PostgreSQL data in: /var/lib/postgresql/data (unused mount/volume) This is usually the result of upgrading the Docker image without upgrading the underlying database using "pg_upgrade" (which requires both versions).PostgreSQL updates can not be done in-place. If you had existing PostgreSQL database in the directory, then you can't simply use a newer image, you need to actually upgrade the database with pg_upgrade. EDIT: Apparently there is a breaking change with official PostgreSQL 18 Docker image as well. I've updated the PostgreSQL 18 template to use the correct volume.

Took me awhile, but I've updated the templates to make the port not mandatory. Been awhile since I've actively worked with those, never spotted it. Thanks for reporting! I've also added newer PostgreSQL versions' templates.

If you are using the official PostgreSQL image, then you can configure the initial superuser using POSTGRES_USER and POSTGRES_PASSWORD environment variables for username/password and POSTGRES_DB for database name. For simplicity purposes, you can use these. But it is recommended to connect with the superuser to the database and create a custom user and database for the application. You can follow PostgreSQL documentation for that, but the basics should be: CREATE USER 'user' WITH ENCRYPTED PASSWORD 'password'; CREATE DATABASE 'database' WITH OWNER 'user';

If both containers (the application and postgresql) are in the same custom network, you can connect using postgresql container's (host)name. If you are using host networking, you will need to use the host IP.

How did you create/configure the user and the password? Using environment variables or did you manually create it? If you manually created the user, then wiping the appdata will remove all non-system/non-root users as well.

User `postgres` is configured with ID 999 in the container. The docker entrypoint script configures the postgres data directories to be owned by that user, if container is started as root (but postgres is run as postgres user). https://github.com/docker-library/postgres/blob/master/15/bookworm/docker-entrypoint.sh#L59

That's normal PostgreSQL log at default level (LOG: indicates informative message). What's the exact error you are seeing?

What update did you do? What tag are you using?

PostgreSQL has a process, that you must follow for major version upgrades.

Seems like the user, that is connecting to the database, does not have the correct permissions. What have you done so far? How did you configure the database and the users?

Postgres doesn't change the permissions, unless it is run the first time (when it needs to initialize the data directory) even then it sets them to 775. 600 might not be enough for PostgreSQL data directory anyway. https://github.com/docker-library/postgres/blob/master/14/bullseye/docker-entrypoint.sh The owner can be unknown, because it is configured for the user ID that Postgres image runs as within the container. Just because host doesn't know the UID, doesn't mean it's broken. But it needs to match the userID, that the postgres process in Docker runs as. PUID and PGID don't do anything, they are specific to Linuxserver images, not Docker in general. It feels like something else is changing the permissions.

PostgreSQL upgrades aren't as easy as increasing the version. To do it properly, you have three options: 1) Dump all data from the old version, import it into the new version. 2) Go through the pg_upgrade process, which requires you to have binaries for both versions, but can be done in-place. 3) Using replication. Follow the official documentation on how to do each one of them, whichever suits you best: https://www.postgresql.org/docs/current/upgrading.html In case of containerized PostgreSQL, dump/import is probably the easiest to do, but will cause downtime.

Added the template for postgres 15. Postgres CLI tools default to the same database name as the user you are trying to connect with. Maybe your database has a different name?

pg_dumpall tries to dump the whole database instance (all databases) and needs root/superuser permissions. If you want to dump a single database, use pg_dump.

It's a password failure error. Have you tried resetting the password?

What are the errors you are seeing?

These logs are normal, nothing alarming. It says it is ready to accept connections, so could it be something else? Wrong IP perhaps?

Howdy Docker works by mounting host paths to container paths. These are called volumes. Check where /var/lib/postgresql/data is mounted to. Latest version of the template defaults to /mnt/cache/appdata/postgresql<version>, e.g. /mnt/cache/appdata/postgresql14. That directory either should not exist, be empty or only contain PostgreSQL own files.

Port 5432 is not WebUI, it is PostgreSQL TCP port. This container only runs the database engine itself. If you want a webUI, you need to find and deploy some other tool.

What version of psql are you using to connect to it? What error is psql giving? Server logs do not give very much information what the error is.

Howdy. Just deleting the Docker won't wipe your data, unless you specifically also delete the appdata folder (whether it is on the array or cache drive). So if the appdata is still there and you recreate the container (has to be the same major version of PostgreSQL), all the databases and the data should still be there. As for recovery, standard data recovery applies, but it is much harder to do with databases, since it is not just one file. And if part of it is missing, basically all is gone. You can add additional databases when you log in as superuser `postgres` and run `CREATE DATABASE <name>;`. Security-wise I'd also recommend to have different users with the necessary permissions (e.g. one user can only access one database etc). For auto-backups, you can run a cron job, that runs `pg_dump` or `pg_dumpall`. Alternatively you could use pgBackRest, but there is no template for it at this moment, it needs additional configuration and is more complicated. --- Made some changes to the templates: - BREAKING CHANGE: Database volume paths now include version tag, e.g. `/mnt/cache/appdata/postgresql10` so you can run multiple instances with different versions at the same time. - BREAKING CHANGE: PostgreSQL 10 template got changed, this could have broken stuff on old users. I am not familiar with the template changes on older versions. - Added PostgreSQL 12, 13 and 14 templates. - Container names changed to lowercase and includes version, e.g. `postgresql14`. This should make it easier for using in custom networks. - Brought the templates up to date with current schema version. Hopefully it is more user-friendly now. Feedback welcome. Sorry, it's been too long since I updated them.

The upgrade is sorta complicated, you need both old and new binaries available, which the official docker images do not provide. Backup and restore might be more convenient and easier.

It's absolutely okay to use one database instance with multiple databases for multiple apps. You will just have to create the new databases (and preferably also new roles) through the psql shell. Postgres upgrades can't be done by simply changing the version tags, they often have changes that require additional steps (e.g. pg_upgrade). So definitely don't use the latest tag. I changed the templates long time ago, haven't added newer templates to the repo though. Here's the information on how to do it: https://www.postgresql.org/docs/14/upgrading.html

Happy birthday! Unraid has really improved over the years and awesome features just keep coming and coming. Keep up the good work!

Postgres 11 has some breaking changes apparently. Made a not-so-smart move to configure this to latest tag. I'll fix this to PostgreSQL 10 and create another template for Postgres 10.