Re: Recovery conflict monitoring

Couple of doc suggestions:

--- doc/src/sgml/high-availability.sgml
+ The number of query cancels and the reason for them can be viewed
using
+ the <structname>pg_stat_database_conflicts</> system view on the slave
+ server.

For compleness sake, this should also mention the per-database summary,
even though I'm not sure how valuable that view is. Also, "on a standby
server" instead of "on the slave server" here. "slave" is mentioned
once as a synonym in high-availability.sgml once, but that's it, and
there can be more than one standby you want to pull these stats from.

*** doc/src/sgml/monitoring.sgml
! number of rows returned, fetched, inserted, updated and deleted, and
! total number of queries cancelled due to conflict with recovery.

This would be clearer if it said you're talking about standby recovery
here, and possibly that this info is only available on the standby. I
could see someone reading this and thinking it's possible for general
database crash recovery to produce cancelled queries, instead of the way
connections are actually blocked until that's done.

! <entry><structname>pg_stat_database_conflicts</>
! <entry>One row per database, showing database OID, database name and
! the number of queries that have been cancelled in this database
due to
! dropped tablespaces, lock timeouts, old snapshots, pinned
buffers and
! deadlocks.

A clarification that you're talking about standby query cancellation
here might be helpful too. I don't think that's necessary for all of
the detailed pg_stat_get_* functions that regular users are less likely
to care about, just these higher level ones.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books