Re: -d option for pg_isready is broken

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: -d option for pg_isready is broken
Дата
Msg-id CA+TgmoYRzBp5bPOmny6_ePFpTp0JGVbeTF0S5ZJN3tg0sF1fUg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: -d option for pg_isready is broken  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: -d option for pg_isready is broken
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: autovacuum_work_mem
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Why the buildfarm is all pink