*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 1905,1910 **** SET ENABLE_SEQSCAN TO OFF;
--- 1905,1911 ----
          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 archiving.
+         This parameter has no effect on a restartpoint.
          This parameter can only be set in the <filename>postgresql.conf</>
          file or on the server command line.
         </para>
*** a/doc/src/sgml/wal.sgml
--- b/doc/src/sgml/wal.sgml
***************
*** 424,429 ****
--- 424,430 ----
    <para>
     There will always be at least one WAL segment file, and will normally
     not be more than (2 + <varname>checkpoint_completion_target</varname>) * <varname>checkpoint_segments</varname> + 1
+    or <varname>checkpoint_segments</> + <xref linkend="guc-wal-keep-segments"> + 1
     files.  Each segment file is normally 16 MB (though this size can be
     altered when building the server).  You can use this to estimate space
     requirements for <acronym>WAL</acronym>.
***************
*** 436,441 ****
--- 437,461 ----
    </para>
  
    <para>
+    In archive recovery or standby mode, the server periodically performs
+    <firstterm>restartpoints</><indexterm><primary>restartpoint</></>
+    which are similar to checkpoints in normal operation: the server forces
+    all its state to disk, updates the <filename>pg_control</> file to
+    indicate that the already-processed WAL data need not be scanned again,
+    and then recycles old log segment files if they are in the
+    <filename>pg_xlog</> directory. Note that this recycling is not affected
+    by <varname>wal_keep_segments</> at all. A restartpoint is triggered
+    if at least one checkpoint record has been replayed and
+    <varname>checkpoint_timeout</> seconds have passed since last restartpoint.
+    In standby mode, a restartpoint is also triggered if
+    <varname>checkoint_segments</> log segments have been replayed since
+    last restartpoint and at least one checkpoint record has been replayed
+    since. In log shipping case, restartpoints can't be performed more
+    frequently than checkpoints in the master because restartpoints can only
+    be performed at checkpoint records.
+   </para>
+ 
+   <para>
     There are two commonly used internal <acronym>WAL</acronym> functions:
     <function>LogInsert</function> and <function>LogFlush</function>.
     <function>LogInsert</function> is used to place a new record into