Re: pg_upgrade if 'postgres' database is dropped

On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian <bruce(at)momjian(dot)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