This is a bit complicated to use in Docker (because `io_uring` has a long and storied security story), but it is a new feature of 18+ that we should probably explicitly support for users who want to jump through the hoops to use it despite the security risk.
Additionally, this re-alphabetizes our `--with-xxx` flags.
This is a pretty large breaking change, which is why this only makes the change in 18+ (which is currently in pre-release stages, and not due for GA until September, and pre-release `PGDATA` directories are officially *not supported* on the GA release anyhow).
Concretely, this changes `PGDATA` to `/var/lib/postgresql/MAJOR/docker`, which matches the pre-existing convention/standard of the `pg_ctlcluster`/`postgresql-common` set of commands, and frankly is what we should've done to begin with, in a classic case of Chesterton's Fence (https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence).
This also changes the `VOLUME` to `/var/lib/postgresql`, which should be more reasonable, and make the upgrade constraints more obvious.
For any users who have been testing the pre-releases, the simplest way to keep your existing data directory is going to be to add `PGDATA=/var/lib/postgresql/data` as an environment variable on your container or adjust your bind-mount from `/var/lib/postgresql/data` to `/var/lib/postgresql/18/docker`, but the *best* way is going to be to refactor your host directory such that your data lives at `18/docker` inside and you can then mount directly to `/var/lib/postgresql` (possibly setting `PGDATA=/var/lib/postgresql/MAJOR/docker` as well, if you want to go overboard on being explicit).
When we added these lines, we needed newer files than PostgreSQL had upstream, but the situation has changed and we were pinned to a specific commit from 2017 - the _oldest_ PostgreSQL release version has a file from 2020.
* Remove inaccurate references to corruption, remove SEGTERM suggestion, update information links to current docs. Postgres is carefully designed such that data is not corrupted on crashes or unclean shutdowns - the main tradeoff is that WAL replay is needed on startup. In practice, SIGTERM can cause unexpected long delays to shutdowns - often during maintenance windows - so best not to actively suggest this. The links back to official Postgres documentation seem sufficient.
There's a major issue with `su-exec` whose fix has gone unreleased for 5 years (typos leading to running code as root, the opposite of the purpose of the program).
This also decreases our Debian vs Alpine variance.
Due to user scripts/downstream code potentially using `su-exec`, I have included a compatibility symlink to `su-exec` for all versions less than the 17 pre-release.
This mimics the behavior of `docker-entrypoint.sh` before it starts the PostgreSQL server.
It has three main goals/uses:
1. (most importantly) as an example of how to use "docker-entrypoint.sh" to extend/reuse the initialization behavior
2. ("docker-ensure-initdb.sh") as a Kubernetes "init container" to ensure the provided database directory is initialized; see also "startup probes" for an alternative solution
(no-op if database is already initialized)
3. ("docker-enforce-initdb.sh") as part of CI to ensure the database is fully initialized before use
(error if database is already initialized)
I somehow missed Debian in 25b3034e9b (only updated Alpine), so this updates Debian in the same way.
> This still supports the "arbitrary user" use case but with slightly tighter permissions on the end result.
>
> This one is a little bit more "special" other images (due to the existing runtime/entrypoint modification of the directory modes) so I've tried to pick reasonable values for both halves.
This still supports the "arbitrary user" use case but with slightly tighter permissions on the end result.
This one is a little bit more "special" other images (due to the existing runtime/entrypoint modification of the directory modes) so I've tried to pick reasonable values for both halves.
In e8ebf74e50 zstd was installed as build
dependency and thus does not end up in the final image which in turn
renders docker-entrypoint.sh broken when using *.sql.zst files.
Do not remove static postgres libraries from Alpine based images.
This add near 1.4MB to image size, but allow to complie some extentions
like repmgr without errors
Tianon Gravi