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

From Fujii Masao
Subject Re: -d option for pg_isready is broken
Date
Msg-id CAHGQGwE77AKyabYwde5+8BjLdOpThp7cnswaO_syEdJOGYvnNw@mail.gmail.com
Whole thread Raw
In response to Re: -d option for pg_isready is broken  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: -d option for pg_isready is broken
List pgsql-hackers
On Thu, Nov 21, 2013 at 9:58 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Nov 21, 2013 at 6:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Nov 20, 2013 at 4:55 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> Not that I can see, but it's not very future-proof.  If libpq changes
>>>> its idea of what will provoke database-name expansion, this will again
>>>> be broken.
>>>
>>> Yeah, I agree that we should make the logic of pg_isready more future-proof
>>> in 9.4dev. One idea is to expose internal_ping() as a libpq function. Then,
>>> instead of just calling PQpingParams(), we can do PQconnectStartParams(),
>>> libpq-function-version-of-internal_ping(), PQhost(), PQport(), and PQfinish().
>>> That is, we get to know the host and port information by calling
>>> PQhost() and PQport(),
>>> after trying to connect to the server.

While I was investigaing PQhost() for that approach, I found several
problems of PQhost().

(1) PQhost() can return Unix-domain socket directory path even in the
platform that
    doesn't support Unix-domain socket.

(2) In the platform that doesn't support Unix-domain socket, when
neither host nor hostaddr
    are specified, the default host 'localhost' is used to connect to
the server and
    PQhost() must return that, but it doesn't.

(3) PQhost() cannot return the hostaddr.

As the result of these problems, you can see the incorrect result of
\conninfo, for example.

$ psql -d "hostaddr=127.0.0.1"
=# \conninfo
You are connected to database "postgres" as user "postgres" via socket
in "/tmp" at port "5432".

Obviously "/tmp" should be "127.0.0.1".

The attached patch fixes these problems of PQhost(). But I'm concerned
about that
this change may break the existing application using PQhost(). That is, some
existing application might not assume that PQhost() returns hostaddr.
If my concern
is true, maybe we need to implement something like PQhostaddr(). It's too late
to add such new libpq function into the current stable release,
though... Thought?

If it's okay to change the behavior of PQhost() as I explained, I will commit
the patch in all supported versions.

Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: plpgsql_check_function - rebase for 9.3
Next
From: Tom Lane
Date:
Subject: Re: plpgsql_check_function - rebase for 9.3