Re: -d option for pg_isready is broken

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: -d option for pg_isready is broken
Date: 2013-11-19 21:03:40
Message-ID: CA+TgmoYcEZYgauvVPCOHFRm5SgivFz2w4tvmqY9_=butA3YEKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 19, 2013 at 1:22 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 11/19/2013 10:12 AM, Robert Haas wrote:
>> On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
>>>> http://www.postgresql.org/docs/9.3/static/app-pg-isready.html
>>>
>>> Attached is the updated version of the patch. Is there any other bug?
>>
>> 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.
>
> Why aren't we using the exact same code as psql? Why does pg_isready
> have its own code for this?

Because pg_isready wants to print the host and port we actually tried
to connect to, which no other utility does. Turns out, there's no
clean API for that. We tried to invent something, but the evidence
seems to indicate that what we invented bites.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2013-11-19 21:04:12 Re: pre-commit triggers
Previous Message Andres Freund 2013-11-19 20:54:28 Re: pre-commit triggers