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 по дате отправления: