Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade if 'postgres' database is dropped

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade if 'postgres' database is dropped
Date: 2011-10-28 13:28:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Thom BrownDate: 2011-10-28 13:34:02
Subject: Re: pg_upgrade if 'postgres' database is dropped
Previous:From: Robert HaasDate: 2011-10-28 13:09:38
Subject: ecpg-related build failure with make 3.82

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group