From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-09 16:43:05 |
Message-ID: | 20150309164305.GA28714@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote:
> Technically, there haven't been any complaints about either pg_dumpall's
> behavior in this regard, or pg_upgrade's, but pg_upgrade's post-upgrade
> scripts would happily remove any databases which were marked as
> 'datallowconn = false' and that scares the daylights out of me. To that
> end, I'd suggest patching (and back-patching) pg_upgrade to check early
> on that:
>
> template0 is set to 'datallowconn = false'
>
> AND
>
> all databases except template0 are set to 'datallowconn = true'
>
> The first is required or anyone who has done that will get the funny
> error that started this thread and things won't work anyway, but I
> believe the latter is also necessary to patch and back-patch as it could
> lead to data loss. It's not a high potential as, hopefully, people will
> check first, but I can imagine a hosting provider or environments where
> there are lots of independent clusters not catching this issue in their
> testing, only to discover someone set their database to 'datallowconn =
> false' for whatever reason and now that database is gone...
Agreed. I will work on a patch for this.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | John McKown | 2015-03-09 16:49:50 | Re: Creating composite keys from csv |
Previous Message | Martin Caverly | 2015-03-09 16:35:12 | FW: Installation |