On Tue, Oct 4, 2011 at 12:11 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > pg_upgrade doesn't work if the 'postgres' database has been dropped in the > old cluster: > > ~/pgsql.master$ bin/pg_upgrade -b ~/pgsql.91stable/bin -B bin/ -d > ~/pgsql.91stable/data -D data-upgraded/ > Performing Consistency Checks > ----------------------------- > Checking current, bin, and data directories ok > Checking cluster versions ok > Checking database user is a superuser ok > Checking for prepared transactions ok > Checking for reg* system OID user data types ok > Checking for contrib/isn with bigint-passing mismatch ok > Creating catalog dump ok > Checking for prepared transactions ok > > New cluster database "postgres" does not exist in the old cluster > Failure, exiting > > > That's a bit unfortunate. We have some other tools that don't work without > the 'postgres' database, like 'reindexdb -all', but it would still be nice > if pg_upgrade did.
+1. I think our usual policy is to try postgres first and then try template1, so it would seem logical for pg_upgrade to do the same. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
