On Saturday 03 January 2009 10:43:09 am Kenneth Lundin wrote: > Tom, > > Well, it's not really "I" that change the password, it happens in the > backup dump file created automatically by pg_dumpall. > > The thing is as an administrator, you want to be able to take a backup at > certain points in time and then later flawlessly be able to restore that > backup and end up in exactly the same state you were in when the backup was > created. And since many times when you are doing a restore, you're in a > time pinch since something probably have gone terribly wrong, then you > don't want to have to muck around manipulating dump files in any way, you > just want to do an instant restore and get your faulty system up and > running asap. > > To my understanding, the prefered way of doing online backups in postgres > is using pg_dump to dump the database. And my point here was that there > seem to be a flaw in this scheme. The script generated by pg_dumpall fails > in my case when I'm doing the restore. > > //Kenneth The problem seem to be here: "When performing restores, I start with a fresh empty database directory that i create using the createdb utility and specify the super-user to be named "super" and always with the same password, let's say "restore"." This is not in fact the case. "super" does not always have the same password. You are using a different password for the restore role of "super" then the regular role. When restoring use the same password as in the database. You might also want to look at pg_dumpall -g which dumps the global parts of the database cluster i.e roles. I generally do a separate pg_dumpall -g and load that first so I have my roles in place before doing the rest of the restore. -- Adrian Klaver aklaver@xxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
