Re: [WIP] In-place upgrade

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [WIP] In-place upgrade
Дата
Msg-id 603c8f070811040801x13031ba4sa07a8024ea29644c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [WIP] In-place upgrade  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: [WIP] In-place upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
> We've talked about this many times before, so I'm sure you know what my
> opinion is. Let me phrase it one more time:
>
> 1. You *will* need a function to convert a page from old format to new
> format. We do want to get rid of the old format pages eventually, whether
> it's during VACUUM, whenever a page is read in, or by using an extra
> utility. And that process needs to online. Please speak up now if you
> disagree with that.

Well, I just proposed an approach that doesn't work this way, so I
guess I'll have to put myself in the disagree category, or anyway yet
to be convinced.  As long as you can move individual tuples onto new
pages, you can eventually empty V3 pages and reinitialize them as new,
empty V4 pages.  You can force that process along via, say, VACUUM,
but in the meantime you can still continue to read the old pages
without being forced to change them to the new format.  That's not the
only possible approach, but it's not obvious to me that it's insane.
If you think it's a non-starter, it would be good to know why.

...Robert


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: libpq and sslmode=require