Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.115
diff -c -r2.115 backup.sgml
*** doc/src/sgml/backup.sgml	7 Mar 2008 01:46:41 -0000	2.115
--- doc/src/sgml/backup.sgml	28 Mar 2008 13:08:38 -0000
***************
*** 577,587 ****
     <para>
      It is important that the archive command return zero exit status if and
      only if it succeeded.  Upon getting a zero result,
!     <productname>PostgreSQL</> will assume that the WAL segment file has been
!     successfully archived, and will remove or recycle it.
!     However, a nonzero status tells
!     <productname>PostgreSQL</> that the file was not archived; it will try
!     again periodically until it succeeds.
     </para>
  
     <para>
--- 577,586 ----
     <para>
      It is important that the archive command return zero exit status if and
      only if it succeeded.  Upon getting a zero result,
!     <productname>PostgreSQL</> will assume that the file has been
!     successfully archived, and will remove or recycle it.  However, a nonzero 
!     status tells <productname>PostgreSQL</> that the file was not archived; 
!     it will try again periodically until it succeeds.
     </para>
  
     <para>
***************
*** 1001,1011 ****
  
     <para>
      It is important that the command return nonzero exit status on failure.
!     The command <emphasis>will</> be asked for log files that are not present
      in the archive; it must return nonzero when so asked.  This is not an
!     error condition.  Be aware also that the base name of the <literal>%p</>
!     path will be different from <literal>%f</>; do not expect them to be
!     interchangeable.
     </para>
  
     <para>
--- 1000,1012 ----
  
     <para>
      It is important that the command return nonzero exit status on failure.
!     The command <emphasis>will</> be asked for files that are not present
      in the archive; it must return nonzero when so asked.  This is not an
!     error condition.  Not all of the requested files will be WAL segment
!     files. You should also expect requests for files with a suffix of 
!     <literal>.backup</> or <literal>.history</>. Also be aware also that
!     the base name of the <literal>%p</> path will be different from 
!     <literal>%f</>; do not expect them to be interchangeable.
     </para>
  
     <para>
***************
*** 1576,1594 ****
  
     <para>
      The magic that makes the two loosely coupled servers work together is
!     simply a <varname>restore_command</> used on the standby that waits
!     for the next WAL file to become available from the primary. The
!     <varname>restore_command</> is specified in the
      <filename>recovery.conf</> file on the standby server. Normal recovery
      processing would request a file from the WAL archive, reporting failure
      if the file was unavailable.  For standby processing it is normal for
!     the next file to be unavailable, so we must be patient and wait for
!     it to appear. A waiting <varname>restore_command</> can be written as
!     a custom script that loops after polling for the existence of the next
!     WAL file. There must also be some way to trigger failover, which should
!     interrupt the <varname>restore_command</>, break the loop and return
!     a file-not-found error to the standby server. This ends recovery and
!     the standby will then come up as a normal server.
     </para>
  
     <para>
--- 1577,1598 ----
  
     <para>
      The magic that makes the two loosely coupled servers work together is
!     simply a <varname>restore_command</> used on the standby that,
!     when asked for the next WAL file, waits for it to become available from
!     the primary. The <varname>restore_command</> is specified in the
      <filename>recovery.conf</> file on the standby server. Normal recovery
      processing would request a file from the WAL archive, reporting failure
      if the file was unavailable.  For standby processing it is normal for
!     the next WAL file to be unavailable, so we must be patient and wait for
!     it to appear. For files ending in <literal>.backup</> or 
!     <literal>.history</> there is no need to wait, though a non-zero return
!     code should also be returned in this case. A waiting 
!     <varname>restore_command</> can be written as a custom script that loops
!     after polling for the existence of the next WAL file. There must also be
!     some way to trigger failover, which should interrupt the 
!     <varname>restore_command</>, break the loop and return a file-not-found
!     error to the standby server. This ends recovery and the standby will then
!     come up as a normal server.
     </para>
  
     <para>
***************
*** 1608,1616 ****
  
     <para>
      A working example of a waiting <varname>restore_command</> is provided
!     as a <filename>contrib</> module named <application>pg_standby</>. This
!     example can be extended as needed to support specific configurations or
!     environments.
     </para>
  
     <para>
--- 1612,1621 ----
  
     <para>
      A working example of a waiting <varname>restore_command</> is provided
!     as a <filename>contrib</> module named <application>pg_standby</>. It 
!     should be used as a reference on how to correctly implement the logic
!     described above. It can also be extended as needed to support specific
!     configurations or environments.
     </para>
  
     <para>