Re: [WIP] pg_ping utility
| От | Tom Lane |
|---|---|
| Тема | Re: [WIP] pg_ping utility |
| Дата | |
| Msg-id | 11215.1350349732@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [WIP] pg_ping utility ("David Johnston" <polobo@yahoo.com>) |
| Список | pgsql-hackers |
"David Johnston" <polobo@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
В списке pgsql-hackers по дате отправления: