Re: -d option for pg_isready is broken

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: -d option for pg_isready is broken
Дата
Msg-id CAHGQGwE77AKyabYwde5+8BjLdOpThp7cnswaO_syEdJOGYvnNw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: -d option for pg_isready is broken  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: -d option for pg_isready is broken
Список 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

Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: plpgsql_check_function - rebase for 9.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: plpgsql_check_function - rebase for 9.3