From: | mlw <markw(at)mohawksoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why dump/restore to upgrade? |
Date: | 2002-02-08 12:29:49 |
Message-ID: | 3C63C4BD.E6C17805@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> mlw <markw(at)mohawksoft(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2002-02-08 13:06:40 | Re: Threaded PosgreSQL server |
Previous Message | Vince Vielhaber | 2002-02-08 11:54:59 | Re: PostgreSQL 7.2 on SlashDot |