Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 9, 2015 at 10:16 PM, Noah Misch <noah@leadboat.com> wrote:
>> The listening side is in good shape today. This thread is about the address
>> that pg_ctl uses in PQping("host=..."). Listening on 0.0.0.0 is portable.
>> PQping("host='0.0.0.0'") relies on non-portable semantics in the underlying
>> connect() syscall. PQping("host='127.0.0.1'") is a portable substitute.
> Ah. So in this case 0.0.0.0 is interpreted to mean "any IP that's a
> way to reach the local host", and using 127.0.0.1 makes sense because
> we know that will always be one of them? I could buy that line of
> reasoning.
I do *not* buy that we can safely replace "localhost" by "127.0.0.1".
Consider a system that's only set up with IPv6 local addressing.
AFAICS the complaint in this bug is about a system with broken DNS (ie,
unable to resolve "localhost" properly, which is something mandated by
relevant RFCs, I believe). We should not break legally, if perhaps
strangely, configured systems in order to work around a misconfigured one.
Failure to resolve localhost to a working loopback address will break a
lot of services besides ours, so the OP is going to need to fix the
configuration problem eventually anyway.
BTW, it looks like pgstat.c will work in such a case, but it's only
accidentally so; as Noah notes, listening to 0.0.0.0 works, and then
it looks like we get the actual IP address for backends to connect to
from the listen socket itself. That wasn't a situation that the code
was meant to handle, for sure, and I wouldn't want to bet that it would
work like that on every platform.
Now, if you're proposing trying "localhost" and falling back to 127.0.0.1
if it fails to resolve, that would be OK with me --- but it would be a
significant amount of additional complexity for what remains a case I do
not think we need to support.
regards, tom lane
