* 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)
The use of manually calling localdef caused any future update to the
locales package to remove the manually installed locales, since
locale-gen takes precendence. This would usually be encountered when
a downstream Dockerfile added additional packages, and as a side effect
caused an upgrade to the locales package.
Fix by relying on the /etc/locale.gen file, which is the official place
to specify which locales should be installed.
Fixes#1112
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 is pulled in automatically via `gnupg`, and moved from `Recommends` to `Depends` in 99474ad900, which has been part of `src:gnupg2` since 2.1.21-4 (and every supported version of both Debian _and_ Ubuntu have 2.2.x 😇).
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.
https://github.com/docker-library/postgres/issues/1024 converted all
`echo` calls to `printf`, but this change causes the password file
used by `initdb` to be blank rather than contain a single newline.
As a result, `initdb` will fail to start with an empty value with
the error:
```
initdb: error: password file "/dev/fd/63" is empty
```
`POSTGRES_PASSWORD` can be blank if `POSTGRES_HOST_AUTH_METHOD=trust`
is used. This change adds a newline to restore the original behavior.
Closes#1025
The use of the `echo` shell built-in has been actively discouraged for a long time, but it's really convenient so we keep doing it. This converts them all to use `printf` appropriately such that we avoid issues like `echo "$someVar"` from doing the wrong thing if `$someVar` is `-n` or similar.
Jeremy Schneider