Обсуждение: localhost redux
I've been having a problem with the pgstat.c localhost change since 7.4, in that statistics gathering stopped working on my gentoo boxes. I've not traced it back beyond getaddrinfo called in getaddrinfo_all, and decided the quick fix was to go back and change pgstat to use 127.0.0.1 instead of localhost. I don't know if the problem is isolated to just me, but I wanted to suggest that we use a parameter for that, which can be configured in the postgresql.conf, with a default value if it's not set, set to localhost. I'd be happy to write a patch that follows this behavior but wanted to see if everyone agrees with that line of thinking before doing so. Gavin
"Gavin M. Roy" <gmr@ehpg.net> writes:
> I've been having a problem with the pgstat.c localhost change since 7.4,
> in that statistics gathering stopped working on my gentoo boxes. I've
> not traced it back beyond getaddrinfo called in getaddrinfo_all, and
> decided the quick fix was to go back and change pgstat to use 127.0.0.1
> instead of localhost.
> I don't know if the problem is isolated to just me, but I wanted to
> suggest that we use a parameter for that, which can be configured in the
> postgresql.conf, with a default value if it's not set, set to
> localhost.
I think you should first trace down what the problem really is --- is
your system just misconfigured or is there some fundamental issue that
we really ought to answer to?
regards, tom lane
I have no problem resolving localhost anywhere else on the box, do you have any suggestions on finding out if it's a misconfiguration? Gavin Tom Lane wrote: >"Gavin M. Roy" <gmr@ehpg.net> writes: > > >>I've been having a problem with the pgstat.c localhost change since 7.4, >>in that statistics gathering stopped working on my gentoo boxes. I've >>not traced it back beyond getaddrinfo called in getaddrinfo_all, and >>decided the quick fix was to go back and change pgstat to use 127.0.0.1 >>instead of localhost. >> >> > > > >>I don't know if the problem is isolated to just me, but I wanted to >>suggest that we use a parameter for that, which can be configured in the >>postgresql.conf, with a default value if it's not set, set to >>localhost. >> >> > >I think you should first trace down what the problem really is --- is >your system just misconfigured or is there some fundamental issue that >we really ought to answer to? > > regards, tom lane > >
"Gavin M. Roy" <gmr@ehpg.net> writes:
> I have no problem resolving localhost anywhere else on the box, do you
> have any suggestions on finding out if it's a misconfiguration?
In that case maybe we have a bug to fix; but that makes me even less
eager to "solve" it by substituting 127.0.0.1 ...
regards, tom lane
> > I don't know if the problem is isolated to just me, but I wanted to > > suggest that we use a parameter for that, which can be configured in the > > postgresql.conf, with a default value if it's not set, set to > > localhost. > > I think you should first trace down what the problem really is --- is > your system just misconfigured or is there some fundamental issue that > we really ought to answer to? The trouble on AIX is, that getaddrinfo only does a nameservice lookup, no /etc/hosts. So if your nameservice does not have localhost ... Same for `hostname`, if nameservice does not resolve `hostname` ... Andreas
Gavin M. Roy wrote: > I have no problem resolving localhost anywhere else on the box, do you > have any suggestions on finding out if it's a misconfiguration? > Gavin Are you the users on IRC yesterday night ? He had the same problem, however he/she had the GUC variable stats_start_collector equal to "on" in the configuration file but was shown as "off" with a SHOW stats_start_collector inside a psql section. That GUC variable is resetted to off is the collector doesn't start ? Regards Gaetano Mendola
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: >> I think you should first trace down what the problem really is --- is >> your system just misconfigured or is there some fundamental issue that >> we really ought to answer to? > The trouble on AIX is, that getaddrinfo only does a nameservice lookup, > no /etc/hosts. Wouldn't that break many other programs besides Postgres? But in any case if your nameserver doesn't resolve localhost, I'd say you'd better fix your nameserver. See eg, http://www.faqs.org/rfcs/rfc2606.html The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A recordpointing to the loop back IP address and is reserved for such use. Any other use would conflict with widelydeployed code which assumes this use. regards, tom lane
Tom Lane wrote: >"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: > > >>>I think you should first trace down what the problem really is --- is >>>your system just misconfigured or is there some fundamental issue that >>>we really ought to answer to? >>> >>> > > > >>The trouble on AIX is, that getaddrinfo only does a nameservice lookup, >>no /etc/hosts. >> >> > >Wouldn't that break many other programs besides Postgres? > Maybe not many use getaddrinfo() >But in any >case if your nameserver doesn't resolve localhost, I'd say you'd better >fix your nameserver. See eg, http://www.faqs.org/rfcs/rfc2606.html > > The ".localhost" TLD has traditionally been statically defined in > host DNS implementations as having an A record pointing to the > loop back IP address and is reserved for such use. Any other use > would conflict with widely deployed code which assumes this use. > > If localhost isn't being resolved correctly are you seeing error messages like this on the server log (from pqcomm.c)? "could not translate host name \"%s\", service \"%s\" to address: %s" Of course, using -i or -h "*" on the postmaster would inhibit that, but you would expect it in the default setup if localhost resolution fails. cheers andrew
> If localhost isn't being resolved correctly are you seeing error > messages like this on the server log (from pqcomm.c)? > > "could not translate host name \"%s\", service \"%s\" to > address: %s" After poking around, I found the following: The Windows pdc (==name server :-( ) does really not resolve localhost (this might be common for Windows nameservers). I do not have a services entry for 5432, and don't have a dns record for this RS6000. LOG: could not translate service "5432" to address: Host not found WARNING: could not create listen socket for "*" LOG: could not bind socket for statistics collector: Can't assign requested address Setting to a port, that is listed in /etc/services does not change anything (except the port of course). I do not have those problems on a machine where dns lists the machine and localhost. This machine has a long obsolete oslevel 4.3.2, so am not sure it is worth pursuing the issue. I only wanted to state, that it does not work here under certain cirumstances eighter. Andreas
Yeah, I was talking about it on freenode yesterday. If the stats collector doesn't start, the internal variable is set to off. Gavin Gaetano Mendola wrote: > Gavin M. Roy wrote: > >> I have no problem resolving localhost anywhere else on the box, do >> you have any suggestions on finding out if it's a misconfiguration? >> Gavin > > > Are you the users on IRC yesterday night ? He had the same problem, > however > he/she had the GUC variable stats_start_collector equal to "on" in the > configuration file but was shown as "off" with a SHOW > stats_start_collector > inside a psql section. > > That GUC variable is resetted to off is the collector doesn't start ? > > > Regards > Gaetano Mendola > > > > >
On Tue, Jul 20, 2004 at 08:32:00AM -0400, Tom Lane wrote: > "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: > >> I think you should first trace down what the problem really is --- is > >> your system just misconfigured or is there some fundamental issue that > >> we really ought to answer to? > > > The trouble on AIX is, that getaddrinfo only does a nameservice lookup, > > no /etc/hosts. > > Wouldn't that break many other programs besides Postgres? But in any > case if your nameserver doesn't resolve localhost, I'd say you'd better > fix your nameserver. See eg, http://www.faqs.org/rfcs/rfc2606.html > > The ".localhost" TLD has traditionally been statically defined in > host DNS implementations as having an A record pointing to the > loop back IP address and is reserved for such use. Any other use > would conflict with widely deployed code which assumes this use. There is no requirement for a recursive resolver (local nameserver) to have localhost hardwired to return 127.0.0.1. It's not even clearly a good idea in all cases. If, though, the resolver returns anything for localhost it must be 127.0.0.1 (or, presumably, ::127.0.0.1). While many recursive resolvers do have localhost hardwired (to avoid this sort of issue) relying on it may be overly brave. It would be nice if the OP could check their recursive resolver to see what it is returning for a query for localhost ('dig @<nameserver> localhost', where <nameserver> is the nameserver listed in /etc/resolv.conf), just to check whether the DNS vs non-DNS localhost thing is an issue at all. Also whether they have /etc/netsvc.conf (IIRC) configured to use /etc/hosts or not. getaddrinfo() has had strange and unusual bugs on some older versions of AIX, anyway, so it may not be a DNS issue at all. Cheers, Steve