PR #801 to postgres image breaks docker-entrypoint initialization logic in CI environments in k8s

[kruftik]

Pull request #801 breaks the initialization logic of docker-entrypoint script if the postgres runs as a sidecar container to the main one in a CI environment and has PGHOST variable defined.

psql command tries to connect to postgres daemon and respects the well-known PGxxx variables during the try.

if PGHOST equals to 127.0.0.1 (or localhost), the client fails with connection refused error breaking the entrypoint script:

2021-01-18 16:44:23.932 UTC [489] LOG:  database system was shut down at 2021-01-18 16:44:21 UTC
2021-01-18 16:44:23.936 UTC [488] LOG:  database system is ready to accept connections
 done
server started

psql: could not connect to server: Connection refused
	Is the server running on host "127.0.0.1" and accepting
	TCP/IP connections on port 5432?```

[tianon]

I'm kind of confused here -- why are you setting the client parameter PGHOST on your server container?

[kruftik]

what about our specific case - we're using gitlab for our CI and it provides 'service' entity which is a kind of abstraction for some auxiliary services for the main build container. good examples of service are different DBs, caches and similar stuff which are needed for run the integration tests or so (instead of, e.g., using test-containers library). the implementation details of the service abstraction depends on the platform gitlab-runner (jenkins-slave or bamboo-agent equivalent in gitlab) deployed to. in k8s they are implemented as sidecar containers (2...N containers in k8s next to the main one sharing the same linux network namespace) in the same build Pod. by default, service containers see the same set of environment variables as the main build container exposed to. that is we provide the build containers with the PGHOST and sibling environment variables and the services see them too.

[tianon]

Doh, that's unfortunate, and also kind of a miracle it ever worked honestly (because any of our more advanced initialization behavior would've caused the exact same failure).

I guess we need to start filtering/overriding more known-bad client variables in our psql invocation. 😕

[tianon]

It would be helpful to get some testing/validation on #808 👍