Re: Why dump/restore to upgrade? - Mailing list pgsql-hackers

From mlw
Subject Re: Why dump/restore to upgrade?
Date
Msg-id 3C63C4BD.E6C17805@mohawksoft.com
Whole thread Raw
In response to Why dump/restore to upgrade?  (mlw <markw@mohawksoft.com>)
Responses Re: Why dump/restore to upgrade?
Re: Why dump/restore to upgrade?
List 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.


pgsql-hackers by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: PostgreSQL 7.2 on SlashDot
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Threaded PosgreSQL server