summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane2005-10-22 22:09:49 +0000
committerTom Lane2005-10-22 22:09:49 +0000
commitc3a7b0577b6eb9586076d0cf91503ee30b3824fb (patch)
tree4716c4d764f1f9dfd47fcaa1e591c9ed132ed309
parentf72a342fb7c714cf40491b5d2b5e34d835178744 (diff)
Add a note about GNU tar's propensity to complain if a file changes
while tar is copying it. This behavior is unhelpful when taking a base backup. Per gripe from Pallav Kalva back in April.
-rw-r--r--doc/src/sgml/backup.sgml11
1 files changed, 10 insertions, 1 deletions
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index e8f8b8a5813..74f3add15c3 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,5 +1,5 @@
<!--
-$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.72 2005/10/22 21:56:07 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.73 2005/10/22 22:09:49 tgl Exp $
-->
<chapter id="backup">
<title>Backup and Restore</title>
@@ -677,6 +677,15 @@ SELECT pg_stop_backup();
</para>
<para>
+ Some versions of GNU <application>tar</> consider it an error if a file
+ is changed while <application>tar</> is copying it. This case is normal,
+ and not an error, when taking a base backup of an active database.
+ Since ignoring all errors from <application>tar</> would be unwise,
+ you should either manually inspect <application>tar</>'s messages or
+ else use a different backup tool that does not complain about this case.
+ </para>
+
+ <para>
It is not necessary to be very concerned about the amount of time elapsed
between <function>pg_start_backup</> and the start of the actual backup,
nor between the end of the backup and <function>pg_stop_backup</>; a