From e76b4e0ddbdb1d1214bfa2b3d212b6d62671729d Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Mon, 12 Apr 2010 10:01:04 +0000
Subject: [PATCH] Adjust paragraph about monitoring streaming replication, now
 that we have standby_keep_segments.

---
 doc/src/sgml/high-availability.sgml | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index cff0339b52..c27c190305 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.59 2010/04/12 09:52:29 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.60 2010/04/12 10:01:04 heikki Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability, Load Balancing, and Replication</title>
@@ -827,13 +827,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
    <sect3 id="streaming-replication-monitoring">
     <title>Monitoring</title>
     <para>
-     The WAL files required for the standby's recovery are not deleted from
-     the <filename>pg_xlog</> directory on the primary while the standby is
-     connected. If the standby lags far behind the primary, many WAL files
-     will accumulate in there, and can fill up the disk. It is therefore
-     important to monitor the lag to ensure the health of the standby and
-     to avoid disk full situations in the primary.
-     You can calculate the lag by comparing the current WAL write
+     An important health indicator of streaming replication is the amount
+     of WAL records generated in the primary, but not yet applied in the
+     standby. You can calculate this lag by comparing the current WAL write
      location on the primary with the last WAL location received by the
      standby. They can be retrieved using
      <function>pg_current_xlog_location</> on the primary and the