Re: -d option for pg_isready is broken

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, 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 19:19:40
Message-ID: CA+Tgmobt5iCL=Ar8sjY=iwtZF4FwvbPe4w6ZH20Qwgf8J5Wc3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-12-11 19:25:30 Re: preserving forensic information when we freeze
Previous Message Robert Haas 2013-12-11 19:17:27 Re: preserving forensic information when we freeze