Add a note that pg_start_backup will take awhile because of new

distributed checkpoint behavior.  Explain how to work around this
by issuing a manual CHECKPOINT command.  Per discussion with Heikki.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 8ef3b5b9a0873e291cbd288b93bee7ce01bb5e2a..454c286715bbb37c4230b978c7f095451b748b69 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Backup and Restore
@@ -674,6 +674,22 @@ SELECT pg_start_backup('label');
      issue this command.  You can ignore the result returned by the function;
      but if it reports an error, deal with that before proceeding.
     
+
+    
+     pg_start_backup can take a long time to finish.
+     This is because it performs a checkpoint, and the I/O
+     required for a checkpoint will be spread out over a significant
+     period of time, by default half your inter-checkpoint interval
+     (see the configuration parameter
+     ).  Usually
+     this is what you want because it minimizes the impact on query
+     processing.  If you just want to start the backup as soon as
+     possible, execute a CHECKPOINT command
+     (which performs a checkpoint as quickly as possible) and then
+     immediately execute pg_start_backup.  Then there
+     will be very little for pg_start_backup's checkpoint
+     to do, and it won't take long.
+