Re: [WIP] pg_ping utility

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Monday, October 15, 2012 7:13 PM
> To: Andres Freund
> Cc: pgsql-hackers@postgresql.org; Thom Brown; Phil Sorber
> Subject: Re: [HACKERS] [WIP] pg_ping utility
> 
> Andres Freund <andres@2ndquadrant.com> writes:
> > Why not add a pg_ctl subcommand for that? For me that sounds like a
> > good place for it...
> 
> I think that's a bad fit, because every other pg_ctl subcommand requires
> access to the data directory.  It would be very confusing if this one
> subcommand worked remotely when the others didn't.
> 
> There was also some discussion of wedging it into psql, which would at
least
> have the advantage that it'd typically be installed on the right side of
the
> client/server divide.  But I still think "wedging into" is the appropriate
verb
> there: psql is a tool for making a connection and executing some SQL
> commands, and "ping" is not that.
> 
> Yeah, I know a whole new executable is kind of a pain, and the amount of
> infrastructure and added maintenance seems a bit high compared to what
> this does.  But a lot of the programs in src/bin/scripts are not much
bigger.
> (In fact that might be the best place for this.)
> 
>             regards, tom lane
> 

This seems to be begging for a canonical "pg_monitor" command where
"pg_ping" would be one sub-command.  A bit much for a single command but it
would provide a frame onto which additional user interfaces could be hung -
though I am lacking for concrete examples at the moment.  pg_monitor would
be focused on "database" monitoring and not "cluster" monitoring generally
but pg_ping would be a necessary pre-requisite since if the cluster is not
available database monitoring doesn't make any sense.

With the recent focus on pg_stat_statements and the current WIP on
"pg_lwlocks" having an official UI for accessing much of this kind data has
merit.  Encapsulating the queries into commands makes actually using them
easier and there can be associated documentation discussing how to interpret
those specific "commands" and some level of consistency when asking for data
for bug and performance reports.  It may be that psql already does much of
this as I am just not that familiar with the program but if that is the case
then classifying it as "making a connection and executing some SQL commands"
is a limited description.  pg_ping is arguably doing at least the first part
of that.

David J.