From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: -d option for pg_isready is broken |
Date: | 2013-12-11 14:52:49 |
Message-ID: | CA+TgmoYRzBp5bPOmny6_ePFpTp0JGVbeTF0S5ZJN3tg0sF1fUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-12-11 08:56:43 -0500, Robert Haas wrote:
>> > $ psql -d "hostaddr=127.0.0.1"
>> > =# \conninfo
>> > You are connected to database "postgres" as user "postgres" via socket
>> > in "/tmp" at port "5432".
>>
>> Yeah, that's true. But the whole point of having both host and
>> hostaddr seems to be that you can lie about where you're connecting.
>> If you set host=some.pretty.domain.name hostaddr=1.2.3.4, the point is
>> to say that you're connecting to the first while, under the covers,
>> actually connecting to the second. Now, I am unclear what value this
>> has, but someone at some point evidently thought it was a good idea,
>> so we need to be careful about changing it.
>
> One use case is accessing a particular host when using DNS round robin
> to standbys in combination with SSL.
Ah, interesting point. And it's not inconceivable that some
application out there could be using PQhost() to retrieve the host
from an existing connection object and reusing that value for a new
connection, in which case redefining it to sometimes return hostaddr
would break things. So I think we shouldn't do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-12-11 14:59:45 | Re: Why the buildfarm is all pink |
Previous Message | Robert Haas | 2013-12-11 14:50:38 | Re: autovacuum_work_mem |