Re: PQping command line tool

From: Phil Sorber <phil(at)omniti(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PQping command line tool
Date: 2012-10-03 22:09:00
Message-ID: CADAkt-jkHYQA5Je=Rs6D5MJb1zuHt_HEOTpnU9wAj4SpWaDcVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 3, 2012 at 11:42 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2012/10/3 Phil Sorber <phil(at)omniti(dot)com>:
>> On Wed, Oct 3, 2012 at 11:35 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> On Tue, Oct 2, 2012 at 11:01:36PM -0400, Phil Sorber wrote:
>>>> I was wondering recently if there was any command line tool that
>>>> utilized PQping() or PQpingParams(). I searched the code and couldn't
>>>> find anything and was wondering if there was any interest to have
>>>> something like this included? I wrote something for my purposes of
>>>> performing a health check that also supports nagios style status
>>>> output. It's probably convenient for scripting purposes as well. It's
>>>> not currently ready for submission to a commitfest, but if there was
>>>> an interest I would clean it up so that it would be.
>>>
>>> I don't see any tool using PQping except pg_ctl. Perhaps we should
>>> modify "pg_ctl status" to use PQping. Right now is only checks the
>>> postmaster.pid file, and checks to see that the pid is a running
>>> postmaster. What it currently doesn't do is to check if the server is
>>> accepting connections with PQping(), like we do for "pg_ctl -w start".
>>>
>>> Comments?
>>
>> I was thinking that maybe this should be a new feature in an existing
>> tool, however I don't think pg_ctl would satisfy my use case as it's
>> normally bundled with the server. This would need to be something that
>> I could install just a client package. It's not a deal breaker, but it
>> makes things more complex.
>>
>> How about adding it as an option to psql? That's not to say that I
>> think we shouldn't also add it to 'pg_ctl status'.

I was looking at the code and originally I was using return code to
signify what the status was and some text output when quiet wasn't
set, but psql has it's own set of established return codes. How does
everyone feel about using different return codes when psql is in the
PQping mode?

Also was just printing out terse text forms of the enums. OK,
NO_RESPONSE, etc. I was thinking they could be used in shell scripts
that way, but we could do that with return codes as well. Would people
like to see something more human friendly and descriptive?

Also -C, --check was available and I went with that. Most of the other
stuff I could think of already had the short option taken.

>
> +1
>
> Pavel
>>
>>>
>>> --
>>> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
>>> EnterpriseDB http://enterprisedb.com
>>>
>>> + It's impossible for everything to be true. +
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-10-03 22:14:02 Re: Detecting libpq connections improperly shared via fork()
Previous Message Daniel Farina 2012-10-03 22:08:18 Detecting libpq connections improperly shared via fork()