psql -h localhost fails in init script

[simonseyock]

psql -h localhost fails in init scripts. I encountered this problem while running a third party script I can not change.

Simple Dockerfile to reproduce:

FROM postgres:9.4
COPY ./init.sh /docker-entrypoint-initdb.d/
RUN chmod a+x /docker-entrypoint-initdb.d/init.sh

init.sh:

#!/bin/bash
psql -h localhost -p 5432 -U postgres -d postgres -c 'select 1;'

Output:

psql: could not connect to server: Connection refused
        Is the server running on host "localhost" (127.0.0.1) and accepting
        TCP/IP connections on port 5432?
could not connect to server: Cannot assign requested address
        Is the server running on host "localhost" (::1) and accepting
        TCP/IP connections on port 5432?

I tried this on windows and linux and with and without the chmod line. The crucial part in the psql command is the -h localhost option. All other options can be removed and the error still occurs, but if the -h is removed everything works fine.

Does a workaround exist for this?

[ionicom]

A recent change to the docker_entrypoint.sh script restricts postgres to only accept connections over a unix domain socket during internal initialization: #440

I too ran into this limitation when trying to run db migrations (via flyway) during this init context: https://stackoverflow.com/questions/51699847/flyway-unable-to-connect-to-postgres-container-within-docker-entrypoint-initdb-d

I would also appreciate a suggested workaround and would suggest the documentation be updated to clearly state the limitations of /docker-entrypoint-initdb.d/ scripts executing during internal init.

[tianon]

This was also discussed a little over in #441.

I think the best workaround (short of using the unix socket instead) is suggested in #440 (comment):

pg_ctl -o "-c listen_addresses='localhost'" -w restart

[simonseyock]

Thanks for mentioning that. If desired I can create a PR to add this workaround to the documentation.

[tianon]

I'm a bit wary of actively documenting the workaround since I think that would provide users with a false sense of the level to which it's supported.

For example, if we could find a way to appropriately provide the arguments to the image (https://github.com/docker-library/docs/tree/57a71eed9a741dd9a64b9a439d2664b896bff87d/postgres#database-configuration) on to pg_ctl when we start this temporary daemon, that would make the workaround have a subtle bug (removing those arguments during restart, essentially).

[AlanFoster]

Edit: I see that the crucial problem here is that you can't modify this third party script. Perhaps you could send a PR to have it fixed? 🤔

For what it's worth, I ran into a similar problem where I wasn't able to connect to the postgres instance whilst using a connection string that set the host part to localhost.

Based on the docs I dropped the explicit host part:

a Unix-domain socket connection is chosen if the host part is either empty or starts with a slash

Therefore:

- postgresql://postgres@localhost:5432/postgres
+ postgresql://postgres@:5432/postgres

The psql CLI supports this format, so this should work for you:

#!/bin/bash

psql postgresql://postgres@:5432/postgres -c 'select 1;'

Or using your existing format, just don't specify the host part and it should work:

#!/bin/bash

psql -p 5432 -U postgres -d postgres -c 'select 1;'

[tianon]

Thanks for the detailed examples, @AlanFoster 👍

I've opened docker-library/docs#1298 to add a blurb to the documentation about this.

[afarber]

I think the best workaround (short of using the unix socket instead) is suggested in #440 (comment):

pg_ctl -o "-c listen_addresses='localhost'" -w restart

The following workaround without restarting postgres also works for me in a postgres:17-alpine3.20 based Dockerfile:

RUN sed -i "s/listen_addresses=''/listen_addresses='localhost'/" /usr/local/bin/docker-entrypoint.sh