Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Date
Msg-id 7389.1425679049@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
List pgsql-general
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.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


pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_upgrade failing from 9.3 to 9.4 because "template0" already exists
Next
From: Adrian Klaver
Date:
Subject: Re: How to get plpython2 in /lib?