Adjust paragraph about monitoring streaming replication, now that we have

standby_keep_segments.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index cff0339b523562ab7ca0aa8ca55d8672bd24e3c1..c27c1903058281d8053611dfd983c952abd47eba 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability, Load Balancing, and Replication
@@ -827,13 +827,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
    
     Monitoring
     
-     The WAL files required for the standby's recovery are not deleted from
-     the 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
      pg_current_xlog_location on the primary and the