Re: Why dump/restore to upgrade?
mlw <markw@mohawksoft.com>
From: mlw <markw@mohawksoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2002-02-08T12:29:49Z
Lists: pgsql-hackers
Tom Lane wrote: > > mlw <markw@mohawksoft.com> writes: > > but I'd like to make a general call to arms that this (or 7.3) should be the > > last release to require this. > > We will never make such a commitment, at least not in the foreseeable > future. Here's the problem. If you have a database that is in service, you can not upgrade postgres on that machine without taking it out of service for the duration of a backup/restore. A small database is not a big deal, a large database is a problem. A system could be out of service for hours. For a mission critical installation, this is really unacceptable. > > I would like to see more attention paid to supporting cross-version > upgrades via pg_upgrade (or some improved version thereof) when > practical, which it should be more often than not. But to bind > ourselves forever to the current on-disk format is sheer folly. > And if you have to convert the datafile format then you might as > well dump and reload. The backup/restore to upgrade will be a deal breaker for many installations. If you want more people using PostgreSQL, you need to accept that this is a very real problem, and one which should be addressed as an unacceptable behavior. I don't want to say "Other databases do it, why can't PostgreSQL" because that isn't the point. Databases can be HUGE, pg_dumpall can take an hour or more to run. Then, it takes longer to restore because indexes have to be recreated.