*** doc/src/sgml/backup.sgml.orig	2009-12-27 15:50:26.000000000 +0100
--- doc/src/sgml/backup.sgml	2009-12-27 16:48:11.000000000 +0100
***************
*** 2128,2134 ****
  
     <para>
      In general queries will not experience lock conflicts with the database
!     changes made by recovery. This is becase recovery follows normal
      concurrency control mechanisms, known as <acronym>MVCC</>. There are
      some types of change that will cause conflicts, covered in the following
      section.
--- 2128,2134 ----
  
     <para>
      In general queries will not experience lock conflicts with the database
!     changes made by recovery. This is because recovery follows normal
      concurrency control mechanisms, known as <acronym>MVCC</>. There are
      some types of change that will cause conflicts, covered in the following
      section.
***************
*** 2373,2379 ****
      if they have been changed on the primary. The value on the standby must
      be equal to or greater than the value on the primary. If these parameters
      are not set high enough then the standby will not be able to track work
!     correctly from recovering transactions. If these values are set too low the
      the server will halt. Higher values can then be supplied and the server
      restarted to begin recovery again.
  
--- 2373,2379 ----
      if they have been changed on the primary. The value on the standby must
      be equal to or greater than the value on the primary. If these parameters
      are not set high enough then the standby will not be able to track work
!     correctly from recovering transactions. If these values are set too low
      the server will halt. Higher values can then be supplied and the server
      restarted to begin recovery again.
  
***************
*** 2399,2405 ****
     <para>
      It is important that the administrator consider the appropriate setting
      of <varname>max_standby_delay</>, set in <filename>postgresql.conf</>.
!     There is no optimal setting and should be set according to business
      priorities. For example if the server is primarily tasked as a High
      Availability server, then you may wish to lower
      <varname>max_standby_delay</> or even set it to zero, though that is a
--- 2399,2405 ----
     <para>
      It is important that the administrator consider the appropriate setting
      of <varname>max_standby_delay</>, set in <filename>postgresql.conf</>.
!     There is no optimal setting and it should be set according to business
      priorities. For example if the server is primarily tasked as a High
      Availability server, then you may wish to lower
      <varname>max_standby_delay</> or even set it to zero, though that is a
***************
*** 2454,2460 ****
  
     <para>
      As a result, you cannot create additional indexes that exist solely
!     on the standby, nor can statistics that exist solely on the standby.
      If these administrator commands are needed they should be executed
      on the primary so that the changes will propagate through to the
      standby.
--- 2454,2460 ----
  
     <para>
      As a result, you cannot create additional indexes that exist solely
!     on the standby, nor can statistics exist solely on the standby.
      If these administrator commands are needed they should be executed
      on the primary so that the changes will propagate through to the
      standby.
***************
*** 2484,2497 ****
      <productname>check_pgsql</> will work, but it is very simple.
      <productname>check_postgres</> will also work, though many some actions
      could give different or confusing results.
!     e.g. last vacuum time will not be maintained for example, since no
      vacuum occurs on the standby (though vacuums running on the primary do
      send their changes to the standby).
     </para>
  
     <para>
      WAL file control commands will not work during recovery
!     e.g. <function>pg_start_backup</>, <function>pg_switch_xlog</> etc..
     </para>
  
     <para>
--- 2484,2497 ----
      <productname>check_pgsql</> will work, but it is very simple.
      <productname>check_postgres</> will also work, though many some actions
      could give different or confusing results.
!     For example, last vacuum time will not be maintained, since no
      vacuum occurs on the standby (though vacuums running on the primary do
      send their changes to the standby).
     </para>
  
     <para>
      WAL file control commands will not work during recovery
!     e.g. <function>pg_start_backup</>, <function>pg_switch_xlog</> etc.
     </para>
  
     <para>
***************
*** 2504,2510 ****
      an advisory lock on either the primary or the standby to conflict with WAL
      replay. Nor is it possible to acquire an advisory lock on the primary
      and have it initiate a similar advisory lock on the standby. Advisory
!     locks relate only to a single server on which they are acquired.
     </para>
  
     <para>
--- 2504,2510 ----
      an advisory lock on either the primary or the standby to conflict with WAL
      replay. Nor is it possible to acquire an advisory lock on the primary
      and have it initiate a similar advisory lock on the standby. Advisory
!     locks relate only to the server on which they are acquired.
     </para>
  
     <para>
***************
*** 2555,2561 ****
  
     <para>
      Stats collector is active during recovery. All scans, reads, blocks,
!     index usage etc will all be recorded normally on the standby. Replayed
      actions will not duplicate their effects on primary, so replaying an
      insert will not increment the Inserts column of pg_stat_user_tables.
      The stats file is deleted at start of recovery, so stats from primary
--- 2555,2561 ----
  
     <para>
      Stats collector is active during recovery. All scans, reads, blocks,
!     index usage etc will be recorded normally on the standby. Replayed
      actions will not duplicate their effects on primary, so replaying an
      insert will not increment the Inserts column of pg_stat_user_tables.
      The stats file is deleted at start of recovery, so stats from primary
***************
*** 2616,2622 ****
     <listitem>
      <para>
       Full knowledge of running transactions is required before snapshots
!      may be taken. Transactions that take use large numbers of subtransactions
       (currently greater than 64) will delay the start of read only
       connections until the completion of the longest running write transaction.
       If this situation occurs explanatory messages will be sent to server log.
--- 2616,2622 ----
     <listitem>
      <para>
       Full knowledge of running transactions is required before snapshots
!      may be taken. Transactions that use large numbers of subtransactions
       (currently greater than 64) will delay the start of read only
       connections until the completion of the longest running write transaction.
       If this situation occurs explanatory messages will be sent to server log.