Briefly document in two places that pg_dump and pg_dumpall cannot be

used for continuous archiving.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index feadf2b1d02b2926a507feb0403cb99a924ad43a..f98417d283f30906b156660ce8b23ff5dd5834ce 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Backup and Restore
@@ -484,6 +484,16 @@ tar -cf backup.tar /usr/local/pgsql/data
   
   
 
+  
+   
+    pg_dump and
+    pg_dumpall do not produce file-system-level
+    backups and cannot be used as part of a continuous-archiving solution.
+    Such dumps are logical and do not contain enough
+    information to used by WAL reply.
+   
+  
+
   
    As with the plain file-system-backup technique, this method can only
    support restoration of an entire database cluster, not a subset.
@@ -744,7 +754,9 @@ SELECT pg_start_backup('label', true);
    
     
      Perform the backup, using any convenient file-system-backup tool
-     such as tar or cpio.  It is neither
+     such as tar or cpio (not
+     pg_dump or
+     pg_dumpall).  It is neither
      necessary nor desirable to stop normal operation of the database
      while you do this.