Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Date: 2013-01-28 16:20:05
Message-ID: CAHGQGwGuBEQ9FGu_U3cv1FJHyykkVLakb+8Bgiz+RxWaVX44BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 28, 2013 at 4:47 AM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> On Sun, Jan 27, 2013 at 2:38 PM, Phil Sorber <phil(at)omniti(dot)com> wrote:
>> On Fri, Jan 25, 2013 at 11:20 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber <phil(at)omniti(dot)com> wrote:
>>>> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>>> set_pglocale_pgservice() should be called?
>>>>>
>>>>> I think that the command name (i.e., pg_isready) should be given to
>>>>> PQpingParams() as fallback_application_name. Otherwise, the server
>>>>> by default uses "unknown" as the application name of pg_isready.
>>>>> It's undesirable.
>>>>>
>>>>> Why isn't the following message output only when invalid option is
>>>>> specified?
>>>>>
>>>>> Try \"%s --help\" for more information.
>>>>
>>>> I've updated the patch to address these three issues. Attached.
>>>>
>>>>>
>>>>> When the conninfo string including the hostname or port number is
>>>>> specified in -d option, pg_isready displays the wrong information
>>>>> as follows.
>>>>>
>>>>> $ pg_isready -d "port=9999"
>>>>> /tmp:5432 - no response
>>>>>
>>>>
>>>> This is what i asked about in my previous email about precedence of
>>>> the parameters. I can parse that with PQconninfoParse, but what are
>>>> the rules for merging both individual and conninfo params together?
>>>
>>> If I read conninfo_array_parse() correctly, PQpingParams() prefer the
>>> option which is set to its keyword array later.
>>
>> It would be really nice to expose conninfo_array_parse() or some
>> wrapped version directly to a libpq consumer. Otherwise, I need to
>> recreate this behavior in pg_isready.c.
>>
>> Thoughts on adding:
>> PQconninfoOption *PQparamsParse(const char **keywords, const char
>> **values, char **errmsg, bool use_defaults, int expand_dbname)
>> or similar?

Maybe. But I'm not inclined to add new libpq interface at this stage.
Because we are in the last CommitFest and I'm not sure whether
we have enough time to implement that. Instead, how about using
both PQconninfoParse() and PQconndefaults() like uri-regress.c does?
Or just remove that output message? At least I don't think that the
information about host and port needs to be output. Which would make
the code very simpler.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-28 16:21:09 Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Previous Message Kevin Grittner 2013-01-28 16:15:29 Re: autovacuum not prioritising for-wraparound tables