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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books