* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Feb 4, 2015 at 8:08 AM, Stephen Frost <sfr...@snowman.net> wrote: > > Apologies for the confusion- the client isn't using it to determine if > > there's activity. They're using it exactly as it's intended, as I > > understand it- to check and see if the number of rollbacks is > > signifigant compared to the number of commits. The issue is that, with > > databases that have little activity, you can end up with a commit ratio > > of 50% or less. Perhaps check_postgres could have an option to only > > complain when some minimum number of transactions has been reached.. > > That sounds like a much better idea. pg_dump isn't really doing > anything wrong here, so "fixing" it feels like the wrong solution.
It occurs to me that 'commit ratio' might not be the check that check_postgres users really want but is, instead, a proxy as we don't actually provide a way to get at what they really want. Perhaps we should consider adding a new stat- *errored* transactions. This would be a count of transactions which rolled back due to an error (and not an explicit "rollback;" or abort), or even have counts of both errored and aborted transactions. At least in my experience, rolled back transactions aren't all bad, but transactions which were terminated due to an error case are things you care about and want to look into. I've used tail-n-mail with PG logs to check for such errors, but it'd certainly be nice to have a Nagios check which could report on them. Thanks, Stephen
signature.asc
Description: Digital signature