On 24 January 2016 at 20:11, Thom Brown <t...@linux.com> wrote: > On 24 January 2016 at 19:53, Victor Wagner <vi...@wagner.pp.ru> wrote: >> On Sun, 24 Jan 2016 15:58:10 +0000 >> Thom Brown <t...@linux.com> wrote: >> >> >>> >>> Output of \set variables without patch: >>> >>> HOST = '127.0.0.1' >>> PORT = >>> '5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533,127.0.0.1:5534,127.0.0.1:5535' >>> >>> And with patch: >>> >>> HOST = >>> '127.0.0.1:5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533,127.0.0.1:5534,127.0.0.1:5535' >>> PORT = '5488' >>> >>> They're both wrong, but I'm hoping we can just show the right >>> information here. >> >> I think we should show right information here, but it is not so simple. >> >> Problem is that I never keep symbolic representation of individual >> host/port pair. And when we connect successfully, we have only struct >> sockaddr representation of the it, which contain right IP >> address, but doesn't contain symbolic host name. >> >> Moreover, one hostname from connect string can produce more than one >> addrinfo structures. For example, on the machines with IPv6 support, >> 'localhost' hostname is resolved into both 127.0.0.1 IPv4 address and >> [::1] IPv6, and produces two records. >> >> So would do any name, which have both A and AAAA records in DNS. And >> nothing prevent domain administrator to put more than one A record for >> same hostname into DNS zone. >> >> >> So, it is just same information which can be retrieved from the backend >> via >> >> select inet_client_addr(); >> select inet_client_port(); > > I think you mean: > > select inet_server_addr(); > select inet_server_port(); > >> What is really interesting for HOST and PORT variable - it is the name >> of host and port number used to make actual connection, as they were >> specified in the connect string or service file. > > And this is probably not the correct thing for it to report. The > documentation says "The database server host you are currently > connected to." and "The database server port to which you are > currently connected.", so yeah, I'd expect to see those set to > whatever those 2 functions resolve to. That being said, if one > connects via a domain socket, those appear to come back blank with > those functions, yet HOST and PORT report the correct information in > those cases (without passing in multiple hosts). Is that a > pre-existing bug?
I've just checked, and can see that this doesn't appear to be a bug. As per network.c: /* * IP address that the server accepted the connection on (NULL if Unix socket) */ and /* * port that the server accepted the connection on (NULL if Unix socket) */ Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
