*** 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 **** 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 MVCC. There are some types of change that will cause conflicts, covered in the following section. --- 2128,2134 ---- 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 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 **** It is important that the administrator consider the appropriate setting of max_standby_delay, set in 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 max_standby_delay or even set it to zero, though that is a --- 2399,2405 ---- It is important that the administrator consider the appropriate setting of max_standby_delay, set in 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 max_standby_delay or even set it to zero, though that is a *************** *** 2454,2460 **** 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 ---- 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 **** check_pgsql will work, but it is very simple. 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). WAL file control commands will not work during recovery ! e.g. pg_start_backup, pg_switch_xlog etc.. --- 2484,2497 ---- check_pgsql will work, but it is very simple. 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). WAL file control commands will not work during recovery ! e.g. pg_start_backup, pg_switch_xlog etc. *************** *** 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. --- 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. *************** *** 2555,2561 **** 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 ---- 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 **** 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 ---- 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.