Minor additions and typo fixes for the backup documentation. Patch from

Simon Riggs, minor editorialization by Neil Conway.

doc/src/sgml/backup.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.86 2006/09/16 00:30:11 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.87 2006/09/19 15:18:41 neilc Exp $ -->
 
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -614,10 +614,10 @@ archive_command = 'test ! -f .../%f &amp;&amp; cp %p .../%f'
 
    <para>
     Also, you can force a segment switch manually with
-    <function>pg_switch_xlog()</>,
+    <function>pg_switch_xlog</>, if you want to ensure that a
-    if you want to ensure that a just-finished transaction is archived
+    just-finished transaction is archived immediately.  Other utility
-    immediately.  Other utility functions related to WAL management are
+    functions related to WAL management are listed in <xref
-    listed in <xref linkend="functions-admin-backup-table">.
+    linkend="functions-admin-backup-table">.
    </para>
   </sect2>
 
@@ -666,15 +666,22 @@ SELECT pg_start_backup('label');
 <programlisting>
 SELECT pg_stop_backup();
 </programlisting>
-     This should return successfully.
+     This should return successfully; however, the backup is not yet fully
+     valid.  An automatic switch to the next WAL segment occurs, so all
+     WAL segment files that relate to the backup will now be marked ready for
+     archiving.
     </para>
    </listitem>
    <listitem>
     <para>
-     Once the WAL segment files used during the backup are archived as part
+     Once the WAL segment files used during the backup are archived, you are
-     of normal database activity, you are done.  The file identified by
+     done.  The file identified by <function>pg_stop_backup</>'s result is
-     <function>pg_stop_backup</>'s result is the last segment that needs
+     the last segment that needs to be archived to complete the backup.  
-     to be archived to complete the backup.
+     Archival of these files will happen automatically, since you have
+     already configured <varname>archive_command</>. In many cases, this
+     happens fairly quickly, but you are advised to monitor your archival
+     system to ensure this has taken place so that you can be certain you
+     have a valid backup.  
     </para>
    </listitem>
   </orderedlist>
@@ -701,9 +708,15 @@ SELECT pg_stop_backup();
     It is not necessary to be very concerned about the amount of time elapsed
     between <function>pg_start_backup</> and the start of the actual backup,
     nor between the end of the backup and <function>pg_stop_backup</>; a
-    few minutes' delay won't hurt anything.  You
+    few minutes' delay won't hurt anything.  However, if you normally run the
-    must however be quite sure that these operations are carried out in
+    server with <varname>full_page_writes</> disabled, you may notice a drop
-    sequence and do not overlap.
+    in performance between <function>pg_start_backup</> and 
+    <function>pg_stop_backup</>.  You must ensure that these backup operations
+    are carried out in sequence without any possible overlap, or you will
+    invalidate the backup.
+   </para>
+
+   <para>
    </para>
 
    <para>
@@ -1437,20 +1450,22 @@ if (!triggered)
    <title>Failover</title>
 
    <para>
-    If the Primary Server fails then the Standby Server should take begin
+    If the Primary Server fails then the Standby Server should begin
     failover procedures.
    </para>
 
    <para>
     If the Standby Server fails then no failover need take place. If the
-    Standby Server can be restarted, then the recovery process can also be
+    Standby Server can be restarted, even some time later, then the recovery
-    immediately restarted, taking advantage of Restartable Recovery.
+    process can also be immediately restarted, taking advantage of 
+    Restartable Recovery. If the Standby Server cannot be restarted, then a
+    full new Standby Server should be created.
    </para>
 
    <para>
     If the Primary Server fails and then immediately restarts, you must have
     a mechanism for informing it that it is no longer the Primary. This is
-    sometimes known as STONITH (Should the Other Node In The Head), which is
+    sometimes known as STONITH (Shoot the Other Node In The Head), which is
     necessary to avoid situations where both systems think they are the
     Primary, which can lead to confusion and ultimately data loss.
    </para>
@@ -1479,12 +1494,12 @@ if (!triggered)
    </para>
 
    <para>
-    So, switching from Primary to Standby Server can be fast, but requires
+    So, switching from Primary to Standby Server can be fast but requires
     some time to re-prepare the failover cluster. Regular switching from
     Primary to Standby is encouraged, since it allows the regular downtime
-    one each system required to maintain HA. This also acts as a test of the
+    that each system requires to maintain HA. This also acts as a test of the
-    failover so that it definitely works when you really need it. Written
+    failover mechanism so that it definitely works when you really need it. 
-    administration procedures are advised.
+    Written administration procedures are advised.
    </para>
   </sect2>
 
@@ -1492,10 +1507,12 @@ if (!triggered)
    <title>Implementing Record-based Log Shipping</title>
 
    <para>
-    The main features for Log Shipping in this release are based around the
+    The main features for Log Shipping in this release are based
-    file-based Log Shipping described above. It is also possible to
+    around the file-based Log Shipping described above. It is also
-    implement record-based Log Shipping using the pg_xlogfile_name_offset()
+    possible to implement record-based Log Shipping using the
-    function, though this requires custom development.
+    <function>pg_xlogfile_name_offset</function> function (see <xref
+    linkend="functions-admin">), though this requires custom
+    development.
    </para>
 
    <para>