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 = ''
>>> PORT =
>>> '5530,,,,,'
>>> And with patch:
>>> HOST =
>>> ',,,,,'
>>> 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 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)


 * port that the server accepted the connection on (NULL if Unix socket)


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to