Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Stephen Frost wrote: > >> Yes, they would have removed it because they didn't want it. As I > >> recall, part of the agreement to create an extra database by default was > >> that it could be removed if users didn't want it. Turning around and > >> then saying "but things won't work if it's not there" isn't exactly > >> supporting users who decide to remove it. > > > Well, you would have to remove it _after_ you did the pg_upgrade. > > As far as the *target* cluster is concerned, I have no sympathy for > someone who messes with its contents before running pg_upgrade. > That's an RTFM matter: you're supposed to upgrade into a virgin > just-initdb'd cluster. > > However, it would be nice if pg_upgrade supported transferring from a > *source* cluster that didn't have the postgres DB.
I have this C comment in pg_upgrade about this: * If someone removes the 'postgres' database from the old cluster and * the new cluster has a 'postgres' database, the number of databases * will not match. We actually could upgrade such a setup, but it would * violate the 1-to-1 mapping of database counts, so we throw an error * instead. We would detect this as a database count mismatch during * upgrade, but we want to detect it during the check phase and report * the database name. Is this worth fixing? Another problem is that pg_dumpall doesn't remove the postgres database in the new cluster if it was not in the old one, so they are going to end up with a postgres database in the new cluster anyway. I could argue that pg_upgrade is better because reports it cannot recreate the new cluster exactly, while pg_dumpall just keeps a postgres database that was not in the old cluster. > What about creating a new, single-purpose database in the source > cluster and then removing it again after we're done? That is not a problem --- I can easily use template1. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
