Document WAL recovery now uses checkpoints.

Simon Riggs

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index b732b2ae7dd6f87f937690158f19d09baf025c1f..01c8ed7d6e61d2f7798695192b5183892709e762 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Backup and Restore
@@ -855,7 +855,9 @@ SELECT pg_stop_backup();
    
     
      Start the server.  The server will go into recovery mode and
-     proceed to read through the archived WAL files it needs.  Upon completion
+     proceed to read through the archived WAL files it needs.  Should the
+     recovery be terminated because of an external error, the server can
+     simply be restarted and it will continue recovery.  Upon completion
      of the recovery process, the server will rename
      recovery.conf to recovery.done (to prevent
      accidentally re-entering recovery mode in case of a crash later) and then
@@ -935,7 +937,21 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
       recover to such a time, you must go back to your previous base backup
       and roll forward from there.)
      
-    
+   
+
+   
+    If recovery finds a corruption in the WAL data then recovery will
+    complete at that point and the server will not start. The recovery 
+    process could be re-run from the beginning, specifying a 
+    recovery target so that recovery can complete normally.
+    If recovery fails for an external reason, such as a system crash or
+    the WAL archive has become inaccessible, then the recovery can be
+    simply restarted and it will restart almost from where it failed.
+    Restartable recovery works by writing a restartpoint record to the control
+    file at the first safely usable checkpoint record found after 
+    checkpoint_timeout seconds. 
+   
+
 
     
      Recovery Settings