Robert Haas wrote:
> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian <bruce@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.
If you remove that line, I can modify pg_upgrade to use template1
instead of postgres, and then the user should just remove the postgres
database from the new cluster before the upgrade --- we can give them a
clear error message on that.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +