[check_postgres] pgbouncer pooler/backend

[Greg Sabino Mullane]

> The idea is to keep the existent plugins and make them workable with pgbouncer
> (if it is relevant).
> 
> Many plugins are irrelevant for pgbouncer (last_analyze for example), and some
> plugin lacks if we want to check_pgbouncer.
> 
> 
> So I wonder if it is better to do a check_pgbouncer.pl or make check_postgres.pl
> understood it can use a normal postgresql server or a modified one (then issue
> relevant query for this kind of modified server) ?

I think pgbouncer is a fairly unique case: it should be 100% transparent to all
current queries, right? We should make separate actions for pgbouncer
information (or Slony/Bucardo/etc.) This should be a very small number of things
to check for, right? Perhaps something like this

./check_postgres_bouncer_clients --warning=20

We'd know to use the default pgbouncer port for these checks, of course. If I
get time, I'll whip up a proof of concept, but anyone feel free to take a swipe
at it, it's unlikely to happen before PostgreSQL Conference East, at any rate.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 226 bytes
Desc: OpenPGP digital signature
Url : https://mail.endcrypt.com/pipermail/check_postgres/attachments/20090327/04166290/attachment.bin