Re: Why dump/restore to upgrade?
От | mlw |
---|---|
Тема | Re: Why dump/restore to upgrade? |
Дата | |
Msg-id | 3C63C4BD.E6C17805@mohawksoft.com обсуждение исходный текст |
Ответ на | Why dump/restore to upgrade? (mlw <markw@mohawksoft.com>) |
Ответы |
Re: Why dump/restore to upgrade?
Re: Why dump/restore to upgrade? |
Список | 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 по дате отправления: