From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | connection timeout hint |
Date: | 2023-12-04 02:46:48 |
Message-ID: | CAMkU=1zGu1AurGadiD78nK8JOJS=NVwQ4LBn=_Y-qUE6DUVfgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. If the
port is blocked by a firewall, it doesn't imply the database server is
not listening (if one could just get to it), and it doesn't matter if the
database server is listening. If for some reason it weren't listening as
well as being blocked, making it listen wouldn't help as long it remains
blocked at the firewall.
Is there some portable way to detect this cause of the connection problem
(connection timeout) and issue a more suitable hint
explicitly mentioning firewalls and routers, or perhaps just no hint at all?
As far as I know, only a firewall causes this problem, at least on a
persistent basis. Maybe you could see it sporadically on a vastly
overloaded server or a server caught in the process of rebooting. It would
be better to give a hint that is correct the vast majority of the time than
one that is wrong the vast majority of the time.
There are a lot of questions about this on, for example, stackoverflow. I
think people might be better able to figure it out for themselves if the
hint were not actively leading them astray.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-12-04 03:02:55 | Re: [RFC] Clang plugin for catching suspicious typedef casting |
Previous Message | jian he | 2023-12-04 02:23:30 | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |