Re: Proposal: Multiversion page api (inplace upgrade)

Поиск
Список
Период
Сортировка
Искать
От
Decibel!
Тема
Re: Proposal: Multiversion page api (inplace upgrade)
Дата
Msg-id
2803D35A-ED9D-4914-BC4D-7097D6A46DF3@decibel.org
Ответ на
Список
Дерево обсуждения
Proposal: Multiversion page api (inplace upgrade) Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Re: Proposal: Multiversion page api (inplace upgrade) "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: Proposal: Multiversion page api (inplace upgrade) Bruce Momjian <bruce@momjian.us>
Re: Proposal: Multiversion page api (inplace upgrade) Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Re: Proposal: Multiversion page api (inplace upgrade) Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Re: Proposal: Multiversion page api (inplace upgrade) Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal: Multiversion page api (inplace upgrade) "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: Proposal: Multiversion page api (inplace upgrade) Decibel! <decibel@decibel.org>
Re: Proposal: Multiversion page api (inplace upgrade) Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Re: Proposal: Multiversion page api (inplace upgrade) Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: Proposal: Multiversion page api (inplace upgrade) Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Re: Proposal: Multiversion page api (inplace upgrade) Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal: Multiversion page api (inplace upgrade) Gregory Stark <stark@enterprisedb.com>
Re: Proposal: Multiversion page api (inplace upgrade) "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: Proposal: Multiversion page api (inplace upgrade) Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal: Multiversion page api (inplace upgrade) Zdenek Kotala <Zdenek.Kotala@Sun.COM>
On Jun 11, 2008, at 10:42 AM, Heikki Linnakangas wrote:

>> Another issue is that it might not be possible to update a page for
>> lack of space.  Are we prepared to assume that there will never be a
>> transformation we need to apply that makes the data bigger?
>
> We do need some solution to that. One idea is to run a pre-upgrade  
> script in the old version that scans the database and moves tuples  
> that would no longer fit on their pages in the new version. This  
> could be run before the upgrade, while the old database is still  
> running, so it would be acceptable for that to take some time.

That means old versions have to have some knowledge of new versions.  
There's also a big race condition unless the old version starts  
taking size requirements into account every time a page is dirtied.

> No doubt people would prefer something better than that. Another  
> idea would be to have some over-sized buffers that can be used as  
> the target of conversion, until some tuples are moved off to  
> another page. Perhaps the over-sized buffer wouldn't need to be in  
> shared memory, if they're read-only until some tuples are moved.
>
> This is pretty hand-wavy, I know. The point is, I don't think these  
> problems are insurmountable.

-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828


В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: Ron Mayer
Дата:
FAQ