Re: [WIP] In-place upgrade

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [WIP] In-place upgrade
Дата
Msg-id 49106E41.90302@enterprisedb.com
обсуждение исходный текст
Ответ на Re: [WIP] In-place upgrade  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Ответы Re: [WIP] In-place upgrade  ("Robert Haas" <robertmhaas@gmail.com>)
Re: [WIP] In-place upgrade  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Список pgsql-hackers
Zdenek Kotala wrote:
> Robert Haas napsal(a):
>> Really, what I'd ideally like to see here is a system where the V3
>> code is in essence error-recovery code.  Everything should be V4-only
>> unless you detect a V3 page, and then you error out (if in-place
>> upgrade is not enabled) or jump to the appropriate V3-aware code (if
>> in-place upgrade is enabled).  In theory, with a system like this, it
>> seems like the overhead for V4 ought to be no more than the cost of
>> checking the page version on each page read, which is a cheap sanity
>> check we'd be willing to pay for anyway, and trivial in cost.
> 
> OK. It was original idea to make "Convert on read" which has several 
> problems with no easy solution. One is that new data does not fit on the 
> page and second big problem is how to convert TOAST table data. Another 
> problem which is general is how to convert indexes...

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.

2. It follows from point 1, that you *will* need to solve the problems 
with pages where the data doesn't fit on the page in new format, as well 
as converting TOAST data.

We've discussed various solutions to those problems; it's not 
insurmountable. For the "data doesn't fit anymore" problem, a fairly 
simple solution is to run a pre-upgrade utility in the old version, that 
reserves some free space on each page, to make sure everything fits 
after converting to new format. For TOAST, you can retoast tuples when 
the heap page is read in. I'm not sure what the problem with indexes is, 
but you can split pages if necessary, for example.

Assuming everyone agrees with point 1, could we focus on these issues?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Ron Mayer
Дата:
Сообщение: Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Spurious Kerberos error messages