"David Johnston" <pol...@yahoo.com> writes:
>> 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.)
> 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.
Meh. If we had near-term plans for more such subcommands, that might
make sense. But I think all that's really wanted here is a command-line
wrapper around the libpq PQping() functionality. People who are trying
to build more complex monitoring tools are likely to be using PQping()
directly anyway, rather than invoking a command-line tool.
> 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.
None of that stuff is accessible without opening up an actual database
connection, and IMO the whole point of PQping is that it *doesn't* open
a connection and thus doesn't get into problems of user authentication.
So I really think it's a different sort of animal that needs a separate
API.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
