When testing locally with the here-configured postgres database, it was
not convenient to change settings. While we want the pdc application to
use an unprivileged (from both a system and postgres perspective) login,
there may be (emergency) circumstances where we want to log in as the
postgres user. Furthermore, the bitnami image provides good defaults, so
we want to keep those, but at the same time allow overrides of the .conf
on a case-by-case or setting-by-setting basis. The docs for the bitnami
postgresql image show how to enable the postgres user on first startup
by setting POSTGRESQL_POSTGRES_PASSWORD[1] and mounting a volume for the
extended configuration files[2].
It is helpful to remember that the password will take hold only on the
starting of the container when the postgres data directory does not yet
exist and will be initialized, and not thereafter. In other words, you
might have to move/delete the existing data directory in order for this
to "take" on the next start of the database container. Also, the .conf
extended settings in the conf.d files are higher precedence than the
generated/main/root postgresql.conf but lower precedence than, say, an
'alter database set ...=...' command run by the postgres user[3][4].
When testing locally with the here-configured postgres database, it was not convenient to change settings. While we want the pdc application to use an unprivileged (from both a system and postgres perspective) login, there may be (emergency) circumstances where we want to log in as the postgres user. Furthermore, the bitnami image provides good defaults, so we want to keep those, but at the same time allow overrides of the .conf on a case-by-case or setting-by-setting basis. The docs for the bitnami postgresql image show how to enable the postgres user on first startup by setting POSTGRESQL_POSTGRES_PASSWORD[1] and mounting a volume for the extended configuration files[2].
It is helpful to remember that the password will take hold only on the starting of the container when the postgres data directory does not yet exist and will be initialized, and not thereafter. In other words, you might have to move/delete the existing data directory in order for this to "take" on the next start of the database container. Also, the .conf extended settings in the conf.d files are higher precedence than the generated/main/root postgresql.conf but lower precedence than, say, an 'alter database set ...=...' command run by the postgres user[3][4].
[1] https://github.com/bitnami/bitnami-docker-postgresql#creating-a-database-user-on-first-run [2] https://github.com/bitnami/bitnami-docker-postgresql#allow-settings-to-be-loaded-from-files-other-than-the-default-postgresqlconf [3] https://www.starkandwayne.com/blog/where-is-postgresql-getting-that-ing-configuration-parameter-from/ [4] https://www.postgresql.org/docs/14/view-pg-settings.html
Issue #39 Allow settings overrides by either .conf or postgres user