Am 16.11.2016 um 11:37 schrieb Gunnar "Nick" Bluth: > 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.
Uhm, well, the actual problem was a stale replication slot... and tomatoes on my eyes, it seems ;-/. Ashes etc.! However, I still think a warning on (esp. rsync's) RCs >= 128 is worth considering (see -v2 attached). Cheers, -- Gunnar "Nick" Bluth DBA ELSTER Tel: +49 911/991-4665 Mobil: +49 172/8853339
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 6eaed1e..183fd37 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -636,7 +636,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
+ potentially misleading FATAL error in the server log. E.g., <command>rsync</>
+ tends to return an exit status of 255 when it is unable to resolve a
+ hostname, which will cause the archiver process to exit (and restart).
</para>
<para>
signature.asc
Description: OpenPGP digital signature
