Re: pg_dump's aborted transactions

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Feb 4, 2015 at 8:08 AM, Stephen Frost <sfrost(at)snowman(dot)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