Re: Resurrecting pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Resurrecting pg_upgrade
Дата
Msg-id 3313.1071442957@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Resurrecting pg_upgrade  ("Matthew T. O'Connor" <matthew@zeut.net>)
Ответы Re: Resurrecting pg_upgrade  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: Resurrecting pg_upgrade  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-hackers
"Matthew T. O'Connor" <matthew@zeut.net> writes:
>> [ pg_upgrade won't be able to change user table representation ]

> How limiting is the above?  Does this mean that pg_upgrade will be
> rendered invalid if there is an on-disk representation change?  Do we
> think we will make it from 7.4 -> 7.5 without on-disk changes?  Do we
> think at this point most upgrades will be without on-disk changes?  

Per prior discussion, we will enforce some sort of limit on how often
the representation of user tables/indexes can be changed.  The idea will
be to "batch" such changes so that you only have to do a dump/reload
every N major releases instead of every one.  In other words, pg_upgrade
will work for most version upgrades but we reserve the right to
occasionally make releases where it doesn't work.

How large N will be in practice remains to be seen, of course, but I'd
expect something on the order of 4 or 5.

In theory pg_upgrade could be made to apply changes in user data
representation, but I'm unconvinced that such a process would be a big
improvement over dump/reload.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] fork/exec patch
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ORDER BY and DISTINCT ON