Re: -d option for pg_isready is broken

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: -d option for pg_isready is broken
Дата
Msg-id CA+Tgmobt5iCL=Ar8sjY=iwtZF4FwvbPe4w6ZH20Qwgf8J5Wc3A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: -d option for pg_isready is broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: -d option for pg_isready is broken
Список pgsql-hackers
On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> In general, I think the definition of these query functions ought to
>>> be "what was the value of this parameter when the connection was made".
>>> As such, I'm not even sure that the pgunixsocket behavior that's in
>>> PQhost now is a good idea, much less that we should extend that hack
>>> to cover DefaultHost.
>
>> Well, returning /tmp on Windows is just stupid.  I don't see why we
>> should feel bad about changing that.  A bug is a bug.
>
> What I was suggesting was we should take out the pgunixsocket fallback,
> not make it even more complicated.  That probably implies that we need
> still another accessor function to get the socket path.

Well, I guess.  I have a hard time seeing whatever rejiggering we want
to do in master as a reason not to back-patch that fix, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gavin Flower
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: preserving forensic information when we freeze