Re: -d option for pg_isready is broken

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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 04:40:00
Message-ID: CAHGQGwE77AKyabYwde5+8BjLdOpThp7cnswaO_syEdJOGYvnNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 21, 2013 at 9:58 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Nov 21, 2013 at 6:41 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Nov 20, 2013 at 4:55 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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 Content-Type Size
fix_pqhost_bugs_v1.patch text/x-patch 619 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-12-11 05:10:38 Re: plpgsql_check_function - rebase for 9.3
Previous Message Amit Kapila 2013-12-11 04:28:38 Re: plpgsql_check_function - rebase for 9.3