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

From Tom Lane
Subject Re: -d option for pg_isready is broken
Date
Msg-id 3058.1386790193@sss.pgh.pa.us
Whole thread Raw
In response to Re: -d option for pg_isready is broken  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: -d option for pg_isready is broken
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> 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.

I guess as long as the pgunixsocket thing is in there, it makes sense
to substitute DefaultHost for it on Windows, but are we sure that's
something to back-patch?

Right now, as I was saying, PQhost is in some gray area where it's not too
clear what its charter is.  It's not "what was the host parameter", for
sure, but we haven't tried to make it an accurate description of the
connection either.  It's a bit less accurate on Windows than elsewhere,
but do we want to risk breaking anything to only partially resolve that?

More generally, if we do go over in 9.4 to the position that PQhost
reports the host parameter and nothing but, I'm not sure that introducing
a third behavior into the back branches is something that anybody will
thank us for.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: preserving forensic information when we freeze
Next
From: Kevin Grittner
Date:
Subject: Re: ANALYZE sampling is too good