Re: Upgrading a database dump/restore

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Upgrading a database dump/restore
Дата
Msg-id 20061009160730.GB8620@svana.org
обсуждение исходный текст
Ответ на Re: Upgrading a database dump/restore  ("Mark Woodward" <pgsql@mohawksoft.com>)
Ответы Re: Upgrading a database dump/restore  ("Mark Woodward" <pgsql@mohawksoft.com>)
Re: Upgrading a database dump/restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Oct 09, 2006 at 11:50:10AM -0400, Mark Woodward wrote:
> > That one is easy: there are no rules.  We already know how to deal with
> > catalog restructurings --- you do the equivalent of a pg_dump -s and
> > reload.  Any proposed pg_upgrade that can't cope with this will be
> > rejected out of hand, because that technology was already proven five
> > years ago.

<snip>

> Dumping out a database is bad enough, but that's only the data, and that
> can takes (mostly) only hours. Recreating a large database with complex
> indexes can take days or hours for the data, hours per index, it adds up.

I think you missed the point of the email you replied to. *catalog*
changes are quick and (relativly) easy. Even with 10,000 tables, it
would only take a few moments to rewrite the entire catalog to a new
version.

> If it is a data format issue, maybe there should be a forum for a "next
> gen" version of the current data layout that is extensible without
> restructuring. This is not something that a couple people can go off and
> do and submit a patch, it is something that has to be supported and
> promoted from the core team, otherwise it won't happen. We all know that.

Actually, the data format is not the issue either. The tuple structure
hasn't changed that often. What has changed is the internal format of a
few types, but postgresql could support both the old and the new types
simultaneously. There has already been a statement from core-members
that if someone comes up with a tool to handle the catalog upgrade,
they'd be willing to keep code from older types around with the
original oid so they'd be able to read the older version.

> The question is whether or not you all think it is worth doing. I've done
> consulting work for some very large companies that everyone has heard of.
> These sorts of things matter.

People are working it, someone even got so far as dealing with most
catalog upgrades. The hard part going to be making sure that even if
the power fails halfway through an upgrade that your data will still be
readable...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: width_bucket function for timestamps
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Prepared Statement Question