On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian <br...@momjian.us> wrote: > Yes, that would work, but see my summarization email on this. Using > template1 is not a problem for pg_upgrade, it is the modifications to > pg_dumpall that are an issue.
I just did a bit of testing on this. It appears that pg_dumpall, if given a cluster containing no postgres database, will happily try to connect to template1 instead. If template1 isn't available either, you can use "-l SOMEDBNAME" to specify the name of another database to connect to instead. So there is infinite flexibility there. But regardless of which database it uses to *generate* the dump, the dump itself will *always* contain this, right at the very beginning: \connect postgres That line is in fact hard-coded as a literal string in pg_dumpall.c. It seems like the easiest fix here might be to just remove that line from the dump, because AFAICS it's completely pointless. During the time for which that setting is in effect, we're just restoring globals, so it shouldn't matter which database we're connected to; only that we have a valid connection. So trying to switch the connection from whatever the user is connected to currently to postgres doesn't accomplish anything useful, but it does make it possible for dump restoration to unnecessarily fail. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
