Jeff Janes <jeff.ja...@gmail.com> writes:
> When one tries to connect to a server and port which is protected by a
> firewall, ones get messages like this:
> Unix:
> psql: error: connection to server at "192.168.0.26", port 5432 failed:
> Connection timed out
> Is the server running on that host and accepting TCP/IP connections?
> Windows:
> psql: error: connection to server at "192.168.0.26", port 5432 failed:
> Connection timed out (0x0000274C/10060)
> Is the server running on that host and accepting TCP/IP connections?
> But the hint given is unhelpful, and even positively misleading.
Well, maybe. I think you're right that it would be useful to give
different hints for ETIMEDOUT and ECONNREFUSED, but sadly it seems
not uncommon for systems to just drop connection requests that
there's no listening process for.
Can we break down the possible cases any further?
* Target host doesn't exist or is down: could give ETIMEDOUT,
EHOSTDOWN, or EHOSTUNREACH.
* Host is up, but PG server is not running or not listening on that
socket: ideally ECONNREFUSED, but could be ETIMEDOUT if the local
firewall blocks it.
* Server is running, but firewall blocks reaching it: almost
certainly ETIMEDOUT.
Are there more cases?
The current hint is already reasonably on-point for EHOSTDOWN,
EHOSTUNREACH, ECONNREFUSED. I agree it's too specific for
ETIMEDOUT, but what exactly would be a better message in view
of the multitude of possible causes?
> Is there some portable way to detect this cause of the connection problem
> (connection timeout)
No, I don't think so. We have the kernel errno to work with
and little more.
regards, tom lane
