I assume we didn't feel any action was necessary on this issue. ---------------------------------------------------------------------------
On Thu, Aug 11, 2011 at 01:50:02PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Aug 9, 2011 at 2:16 PM, Peter Eisentraut <pete...@gmx.net> wrote: > >> But I'm a little confused by what this code is really trying > >> to accomplish: ... > > > I think the intended behavior of NI_NUMERICHOST is to suppress the > > name lookup, and return the text format *even if* the name lookup > > would have worked. So the intention of this code may be to ensure > > that we convert the the sockaddr to some sort of string even if we > > can't resolve the hostname - i.e. if the first call fails, try again > > with NI_NUMERICHOST added to make sure that we didn't fail solely due > > to some kind of DNS hiccup. I suspect that at some time this was > > defending against an actual hazard but I don't know whether it's still > > a problem on modern operating systems. > > POSIX v7 says > > If the node's name cannot be located, the numeric form of the > address contained in the socket address structure pointed to by > the sa argument is returned instead of its name. > > If you read a bit further, apparently this is just supposed to be the > default behavior if neither NI_NUMERICHOST nor NI_NAMEREQD is set (in > the first case, it doesn't try to locate a node name, and in the second, > it fails if it can't locate a node name). But certainly the dance in > postmaster.c is not necessary if you believe the spec. > > I believe that the existing coding is meant to cope with the behavior of > our stub version of getnameinfo(), which simply fails outright if > NI_NUMERICHOST isn't set. However, if we just removed that test and > behaved as per spec (return a numeric address anyway), then we could > eliminate the second call in postmaster.c. > > >> The fix would appear to be using the NI_NAMEREQD flag to getnameinfo. > > > If you want to do that, you're going to have to fix the version of > > getnameinfo() in src/port/getaddrinfo.c, which apparently doesn't > > support that flag. > > Well, it's not just that it "doesn't support that flag". It's > fundamentally incapable of returning anything but a numeric address, > and therefore the only "support" it could offer would be to fail. So > that approach seems like a dead end. > > I don't really think that there's anything to fix here with respect to > Peter's original concern, but it might be worth getting rid of the > double call in postmaster.c. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
