Robert Haas wrote: > >> 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'm happy to do that, unless someone can see a hole in my logic. > > > 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. > > What I would prefer is to have the upgrade succeed, and just ignore > the existence of a postgres database in the new cluster. Maybe give > the user a notice and let them decide whether they wish to take any > action. I understand that failing is probably less code, but IMHO one > of the biggest problems with pg_upgrade is that it's too fragile: > there are too many seemingly innocent things that can make it croak > (which isn't good, when you consider that anyone using pg_upgrade is > probably in a hurry to get the upgrade done and the database back > on-line). It seems like this is an opportunity to get rid of one of > those unnecessary failure cases.
OK, then the simplest fix, once you modify pg_dumpall, would be to modify pg_upgrade to remove reference to the postgres database in the new cluster if it doesn't exist in the old one. That would allow pg_upgrade to maintain a 1-1 matching of databases in the old and new cluster --- it allows the change to be locallized without affecting much code. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
