From eb06e6d1820f0c253021257094ea3e097ccd4f44 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 1 Aug 2003 01:01:52 +0000 Subject: [PATCH] Improve description of restoring pg_dumpall backups, per gripe from Havard Eidnes. --- doc/src/sgml/backup.sgml | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 24ea265f23..6e7e9cbf0b 100644 --- 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. -- 2.40.0