Rename standby_keep_segments to wal_keep_segments.

Also, make the name of the GUC and the name of the backing variable match.
Alnong the way, clean up a couple of slight typographical errors in the
related docs.

2 files changed, 10 insertions, 10 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index eb3e8edd436..e1372bf4a89 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.268 2010/04/19 00:55:25 rhaas Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.269 2010/04/20 11:15:06 rhaas Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -1842,10 +1842,10 @@ SET ENABLE_SEQSCAN TO OFF;
        </listitem>
       </varlistentry>
 
-      <varlistentry id="guc-standby-keep-segments" xreflabel="standby_keep_segments">
-       <term><varname>standby_keep_segments</varname> (<type>integer</type>)</term>
+      <varlistentry id="guc-wal-keep-segments" xreflabel="wal_keep_segments">
+       <term><varname>wal_keep_segments</varname> (<type>integer</type>)</term>
        <indexterm>
-        <primary><varname>standby_keep_segments</> configuration parameter</primary>
+        <primary><varname>wal_keep_segments</> configuration parameter</primary>
        </indexterm>
        <listitem>
        <para>
@@ -1853,17 +1853,17 @@ SET ENABLE_SEQSCAN TO OFF;
         directory, in case a standby server needs to fetch them via streaming
         replication. Each segment is normally 16 megabytes. If a standby
         server connected to the primary falls behind more than
-        <varname>standby_keep_segments</> segments, the primary might remove
+        <varname>wal_keep_segments</> segments, the primary might remove
         a WAL segment still needed by the standby and the replication
         connection will be terminated.
 
         This sets only the minimum number of segments retained for standby
-        purposes, the system might need to retain more segments for WAL
-        archival or to recover from a checkpoint. If <varname>standby_keep_segments</>
+        purposes; the system might need to retain more segments for WAL
+        archival or to recover from a checkpoint. If <varname>wal_keep_segments</>
         is zero (the default), the system doesn't keep any extra segments
         for standby purposes, and the number of old WAL segments available
         for standbys is determined based only on the location of the previous
-        checkpoint and status of WAL archival.
+        checkpoint and status of WAL archiving.
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
        </para>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c27c1903058..d2a8ea77998 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.60 2010/04/12 10:01:04 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.61 2010/04/20 11:15:06 rhaas Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability, Load Balancing, and Replication</title>
@@ -737,7 +737,7 @@ trigger_file = '/path/to/trigger_file'
     falls behind too much, the primary will delete old WAL files still
     needed by the standby, and the standby will have to be manually restored
     from a base backup. You can control how long the primary retains old WAL
-    segments using the <varname>standby_keep_segments</> setting.
+    segments using the <varname>wal_keep_segments</> setting.
    </para>
 
    <para>