Hi,
I ran into this issue (see patch) a few times over the past years, and
tend to forget it again (sigh!). Today I had to clean up a few hundred
GB of unarchived WALs, so I decided to write a patch for the
documentation this time.
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 6eaed1e..460a4f2 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -636,7 +636,13 @@ 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 and
<emphasis>not
+ </> try to archive the affected WAL segment anymore. E.g.,
<command>rsync</>
+ tends to return an exit status of 255 when it is unable to resolve a
+ hostname, which - when returned unfiltered - will result in permanent
+ failure to archive the segment, even if the resolving problem is only
+ temporarily.
</para>
<para>
Best regards,
--
Gunnar "Nick" Bluth
DBA ELSTER
Tel: +49 911/991-4665
Mobil: +49 172/8853339
