Re: [WIP] In-place upgrade

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: [WIP] In-place upgrade
Дата
Msg-id 491194EE.8040603@sun.com
обсуждение исходный текст
Ответ на Re: [WIP] In-place upgrade  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:

> 
> 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.

Yes. Agree. The basic idea is to create new empty page and copy+convert tuples 
into new page. This new page will overwrite old one I have already code which 
converts heap table (excluding arrays and composite datatype).

> 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.

Yes or no. It depends if we will want live with old pages forever. But I think 
convert all pages to the newest version is good idea.

> 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. 

I think it will not work. you need protect also PotgreSQL to put any data extra 
data on a page. Which requires modification into PostgreSQL code in old branches.


> For TOAST, you can retoast tuples when 
> the heap page is read in. 

Yes you have to retosted it which is only possible method but problem is thet 
you need workinig toastable index ... yeah, indexes are different story.
> I'm not sure what the problem with indexes is,> but you can split pages if necessary, for example.

Indexes is different story. In first step I prefer to use reindex. But in the 
future a prefer to extend pg_am and add ampageconvert which will point to 
conversion function. Maybe we can extend it now and keep this column empty.

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

Yes, OK I'm going to cleanup code which I have and I will send it soon. Tuple 
conversion is already part of patch which I already send. See 
access/heapam/htup_03.c.
Zdenek


-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



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

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: WIP parallel restore patch
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: Re: some strange bugs related to upgrade from 8.1 to 8.3