Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Date
Msg-id CAHGQGwFVUUMZFkQqrZYgUmFfa0-OzmHcfh32jCYk8femHz-rPg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)  (Phil Sorber <phil@omniti.com>)
Responses Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
List pgsql-hackers
On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber <phil@omniti.com> wrote:
> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao <masao.fujii@gmail.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.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Skip checkpoint on promoting from streaming replication
Next
From: Tom Lane
Date:
Subject: Re: autovacuum not prioritising for-wraparound tables