[bitnami/postgresql] Updated libpostgresql.sh to specify a host to Postgres Commands #68236
+2
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the change
Updates the
postgresql_start_bg
andpostgresql_execute_print_output
functions in libpostgresql.sh to specify the loopback address as the host forpsql
andpg_isready
commands.Benefits
If a custom unix socket directory is specified in the Primary configuration, startup will fail as the
psql
andpg_isready
commands do not look at the correct location for the Unix socket directory. This updates them to use the loopback host which should work regardless of where the unix socket file is stored, and it is also consistent with the behavior of the probes used by the Helm chart.Being able to specify a custom Unix socket directory is useful, as the Bitnami Postgresql image provided by Iron Bank is built on top of the RHEL Universal Base Image and uses the RHEL Postgresql port. The RHEL Postgresql port defaults to storing Postgresql's unix socket under /run, which poses an issue as it is a common security measure to deploy containers with read-only root filesystems.
Possible drawbacks
None that I'm aware of. I've tested this in standalone and replication mode, and both appeared to work as expected.
Applicable issues
Additional information
There appears to be a separate bug here mentioned in #68027 where if the startup setup fails the first time, it will never be completed. When this happens, the Postgresql container will act as if it is healthy even though the authentication and databases have not been properly setup. This PR does not fix that issue.