On 28 October 2011 14:28, Robert Haas <robertmh...@gmail.com> wrote: > 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.
This was the kind of qualm I had with createdb, which I submitted a patch for earlier this year: http://archives.postgresql.org/pgsql-hackers/2011-03/msg00999.php -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: 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
