Re: pg_upgrade if 'postgres' database is dropped

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +