Re: pg_upgrade if 'postgres' database is dropped

On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Bruce Momjian wrote:
>> > 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.
>
> I fixed this a different way.  I originally thought I could skip over
> the 'postgres' database in the new cluster if it didn't exist in the old
> cluster, but we have do things like check it is empty, so that was going
> to be awkward.
>
> It turns out there was only one place that expected a 1-1 mapping of old
> and new databases (file transfer), so I just modified that code to allow
> skipping a database in the new cluster that didn't exist in the old
> cluster.

Urp. But that means that if someone has any data in that database,
pg_upgrade will basically eat it. That does not seem like a step
forward.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company