Re: -d option for pg_isready is broken - Mailing list pgsql-hackers

From Robert Haas
Subject Re: -d option for pg_isready is broken
Date
Msg-id CA+TgmoYRzBp5bPOmny6_ePFpTp0JGVbeTF0S5ZJN3tg0sF1fUg@mail.gmail.com
Whole thread Raw
In response to Re: -d option for pg_isready is broken  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: -d option for pg_isready is broken
List pgsql-hackers
On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: autovacuum_work_mem
Next
From: Kevin Grittner
Date:
Subject: Re: Why the buildfarm is all pink