Am 23.11.2016 um 21:41 schrieb Stephen Frost: > Greetings, Greetings, and excuse my persistence on this ;-),
> * Gunnar "Nick" Bluth (gunnar.bl...@pro-open.de) wrote: >> Now, what could happen is -- discussion of different disaster scenarios, boiling down to a differing definition of the term "data loss"... I myself took a slightly more generous approach, based on the idea that after an outage of the archiving destination, a DBA would probably initiate a full backup straight away (and/or try a restore). -- However, to get this on track again...: > One of the very important things that should be done as part of a backup > is to ensure that all of the archive files required to restore the > database to a consistent state are safely stored in the archive. If > that isn't done then it's possible that an incomplete archive may also > render backups invalid. Well, the need to have a complete archive is described in the docs already. Maybe the potential consequences of an incomplete archive should be pointed or more drastically...? >> Am I missing something? > > For my 2c, at least, the archive should be viewed with nearly the same > care and consideration as the primary data. As with your database, you > really want your backups to work when you need them. We're certainly on the same page! Now, the main purpose of my patch was to document a behaviour that many of us have run into, namely that FATAL error showing up in the log when the archive_command exits with RC > 127. It's a nuisance only, but it does send people on false tracks and should at least be mentioned in the documentation. And since a couple of people does use rsync (or some wrappers around it) for archiving, and that is notoriously giving RCs > 127, it seems legit to at least mention it, no? What think you? -- Gunnar "Nick" Bluth RHCE/SCLA Mobil +49 172 8853339 Email: gunnar.bl...@pro-open.de _____________________________________________________________ In 1984 mainstream users were choosing VMS over UNIX. Ten years later they are choosing Windows over UNIX. What part of that message aren't you getting? - Tom Payne
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 6eaed1e..a8f574e 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -587,7 +587,8 @@ tar -cf backup.tar /usr/local/pgsql/data
the administrator specify a shell command to be executed to copy a
completed segment file to wherever it needs to go. The command could be
as simple as a <literal>cp</>, or it could invoke a complex shell
- script — it's all up to you.
+ script — it's all up to you. There however are some things to
consider
+ when creating such a command, most of which are covered below.
</para>
<para>
@@ -636,7 +637,11 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065
&& cp pg_wal/0
<productname>PostgreSQL</> will assume that the file has been
successfully archived, and will remove or recycle it. However, a nonzero
status tells <productname>PostgreSQL</> that the file was not archived;
- it will try again periodically until it succeeds.
+ it will try again periodically until it succeeds. Note that an exit
+ status of 128 or higher will cause the archiver to exit, resulting in a
+ <literal>FATAL</> error in the server log. It will be restarted by the
+ postmaster and continue where it left. E.g., <command>rsync</> is known
+ for returning exit statuses of 255 on network issues.
</para>
<para>
@@ -696,6 +701,16 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065
&& cp pg_wal/0
preserve the file name (<literal>%f</>).
</para>
+ <para>
+ Depending on your specific requirements (and datacenter layout), you may
+ want to make sure that the archived WAL segments have been written out to
+ persistent storage before the <command>archive_command</> returns.
+ Otherwise, a WAL segment that is assumed by <productname>PostgreSQL</>
+ to be archived could be recycled or removed prematurely, rendering your
+ archive incomplete (and thus disabling a recovery) in case of an outage of
+ the archiving destination.
+ </para>
+
<para>
Note that although WAL archiving will allow you to restore any
modifications made to the data in your <productname>PostgreSQL</> database,
signature.asc
Description: OpenPGP digital signature
