Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Matt Landry <lelnet(dot)matt(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Date: 2015-03-06 21:57:29
Message-ID: 7389.1425679049@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Perhaps pg_upgrade should deliberately ignore template0 regardless of
>> datallowconn? And/or we should hard-wire that into pg_dumpall?

> My thinking would be that pg_dumpall should be hard-wired for template0
> (just like it is for template1..) and that we should *not* be excluding
> databases that are marked as datallowconn = false.. That said, it's not
> clear to me what to do there instead. Maybe throw an error or a
> warning? The point of pg_dumpall is to dump *all* the databases and at
> least the manpage doesn't appear to say anything about "but ignores
> databases with datallowconn = false".

I think pg_upgrade and pg_dumpall may be two different use-cases.
pg_upgrade should definitely throw a hard error if there are any
non-template0 databases that it can't connect to, because the alternative
is losing such databases during the upgrade. I'm not sure that the
argument is so black-and-white for pg_dumpall, though. Nobody's ever
complained about it skipping unconnectable databases, and that behavior
has been there since we invented datallowconn (cf commit 2cf48ca04bf599).

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2015-03-06 21:58:26 Re: How to get plpython2 in /lib?
Previous Message Stephen Frost 2015-03-06 21:35:57 Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists