1- <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.99 2007/07/16 22:20:51 momjian Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.100 2007/09/14 04:15:50 momjian Exp $ -->
22
33<chapter id="backup">
44 <title>Backup and Restore</title>
@@ -729,16 +729,17 @@ SELECT pg_stop_backup();
729729 <para>
730730 Some backup tools that you might wish to use emit warnings or errors
731731 if the files they are trying to copy change while the copy proceeds.
732- This situation is normal, and not an error, when taking a base backup of
733- an active database; so you need to ensure that you can distinguish
732+ This situation is normal, and not an error, when taking a base backup
733+ of an active database; so you need to ensure that you can distinguish
734734 complaints of this sort from real errors. For example, some versions
735- of <application>rsync</> return a separate exit code for <quote>vanished
736- source files</>, and you can write a driver script to accept this exit
737- code as a non-error case. Also, some versions of GNU
738- <application>tar</> consider it an error if a file is changed while
739- <application>tar</> is copying it. Fortunately, GNU
740- <application>tar</> versions 1.16 and later exit with <literal>1</>
741- if files changed during the backup, and <literal>2</> for other errors.
735+ of <application>rsync</> return a separate exit code for
736+ <quote>vanished source files</>, and you can write a driver script to
737+ accept this exit code as a non-error case. Also, some versions of
738+ GNU <application>tar</> consider it an error if a file was truncated
739+ while <application>tar</> is copying it. Fortunately, GNU
740+ <application>tar</> versions 1.16 and later exits with <literal>1</>
741+ if a file was changed during the backup, and <literal>2</> for other
742+ errors.
742743 </para>
743744
744745 <para>
0 commit comments