Re: pg_upgrade if 'postgres' database is dropped

On Tue, Nov 1, 2011 at 2:36 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> 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.
>
> Please clarify?  We already check that all the new cluster databases are
> empty, so we are effectively skipping the transfering of files into
> empty new cluster databases.  It processes all old cluster databases and
> forces a new cluster match --- it is only empty new cluster database
> that are being skipped.

Aren't you saying that if a postgres database exists in the old
database (and potentially contains data) but is missing in the new
database, we'll just fail to migrate it?

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