On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian <br...@momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
