Re: Release cycle length

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Release cycle length
Дата
Msg-id 23265.1069441708@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Release cycle length  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: Release cycle length
Список pgsql-hackers
Jan Wieck <JanWieck@Yahoo.com> writes:
> Alvaro Herrera wrote:
>> One of the most complex would be to avoid the need of pg_dump for
>> upgrades ...

> We don't need a simple way, we need a way to create some sort of catalog 
> diff and "a safe" way to apply that to an existing installation during 
> the upgrade.

I still think that pg_upgrade is the right idea: load a schema dump from
the old database into the new one, then transfer the user data files and
indexes via cheating (doubly linking, if possible).  Obviously there is
a lot of work still to make this happen reliably, but we have seen
proof-of-concept some while ago, whereas "catalog diffs" are pie in the
sky IMHO.  (You could not use either the old postmaster version or the
new version to apply such a diff...)

A big advantage of the pg_upgrade concept in my mind is that if it fails
partway through, you need have made no changes to the original
installation.  Any mid-course problem with an in-place-diff approach
leaves you completely screwed :-(
        regards, tom lane


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

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: logical column position
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Build farm