Improve description of restoring pg_dumpall backups, per gripe from

Havard Eidnes.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 24ea265f23dfb10eac757c3d822a006c141f4210..6e7e9cbf0be0581e3225f173fc13ce8ea4bea269 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,5 +1,5 @@
 
 
  Backup and Restore
@@ -163,16 +163,21 @@ pg_dump -h host1 dbname | psql -h h
     up an entire database cluster. For this reason the
     pg_dumpall program is provided.
     pg_dumpall backs up each database in a given
-    cluster and also makes sure that the state of global data such as
-    users and groups is preserved. The call sequence for
+    cluster, and also preserves cluster-wide data such as
+    users and groups. The call sequence for
     pg_dumpall is simply
 
 pg_dumpall > outfile
 
-    The resulting dumps can be restored with psql as
-    described above. But in this case it is definitely necessary that
-    you have database superuser access, as that is required to restore
-    the user and group information.
+    The resulting dump can be restored with psql:
+
+psql template1 < infile
+
+    (Actually, you can specify any existing database name to start from,
+    but if you are reloading in an empty cluster then template1
+    is the only available choice.)  It is always necessary to have
+    database superuser access when restoring a pg_dumpall
+    dump, as that is required to restore the user and group information.
    
   
 
@@ -260,7 +265,7 @@ pg_dump -Fc dbname > 
    
     pg_dump (and by implication
     pg_dumpall) has a few limitations which stem from
-    the difficulty to reconstruct certain information from the system
+    the difficulty of reconstructing certain information from the system
     catalogs.