From 4303c0fdbf219028d66e1610aaa1a8e228255356 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 29 Jun 2007 15:46:21 +0000
Subject: [PATCH] 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.
---
doc/src/sgml/backup.sgml | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 8ef3b5b9a08..454c286715b 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.97 2007/02/01 00:28:16 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.98 2007/06/29 15:46:21 tgl Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
@@ -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.
</para>
+
+ <para>
+ <function>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
+ <xref linkend="guc-checkpoint-completion-target">). 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 <command>CHECKPOINT</> command
+ (which performs a checkpoint as quickly as possible) and then
+ immediately execute <function>pg_start_backup</>. Then there
+ will be very little for <function>pg_start_backup</>'s checkpoint
+ to do, and it won't take long.
+ </para>
</listitem>
<listitem>
<para>
--
GitLab