Re: Proposal: Multiversion page api (inplace upgrade)
От | Decibel! |
---|---|
Тема | Re: Proposal: Multiversion page api (inplace upgrade) |
Дата | |
Msg-id | 2803D35A-ED9D-4914-BC4D-7097D6A46DF3@decibel.org обсуждение исходный текст |
Ответ на | Re: Proposal: Multiversion page api (inplace upgrade) ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Список | pgsql-hackers |
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 по дате отправления: