Re: [WIP] In-place upgrade

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [WIP] In-place upgrade
Дата
Msg-id 603c8f070811050432i2495bc94i8ab8fff65bf60c33@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: [WIP] In-place upgrade  (Greg Stark <greg.stark@enterprisedb.com>)
Список pgsql-hackers
> An old page which never goes away. New page formats are introduced for a
> reason -- to support new features. An old page lying around indefinitely means
> some pages can't support those new features. Just as an example, DBAs may be
> surprised to find out that large swathes of their database are still not
> protected by CRC checksums months or years after having upgraded to 8.4 (or
> even 8.5 or 8.6 or ...). They would certainly want a way to ensure all their
> data is upgraded.

OK, I see your point.  In the absence of any old snapshots,
convert-on-write allows you to forcibly upgrade the whole table by
rewriting all of the tuples into new pages:

UPDATE table SET col = col

In the absence of page expansion, you can put logic into VACUUM to
upgrade each page in place.

If you have both old snapshots that you can't get rid of, and page
expansion, then you have a big problem, which I guess brings us back
to Heikki's point.

...Robert


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

Предыдущее
От: "Ibrar Ahmed"
Дата:
Сообщение: pg_dump roles support [Review]
Следующее
От: Dmitry Turin
Дата:
Сообщение: Re: SQL5 budget