Re: Proposal: Multiversion page api (inplace upgrade)
| От | Bruce Momjian |
|---|---|
| Тема | Re: Proposal: Multiversion page api (inplace upgrade) |
| Дата | |
| Msg-id | 200806121743.m5CHhpJ03188@momjian.us обсуждение исходный текст |
| Ответ на | Re: Proposal: Multiversion page api (inplace upgrade) ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
| Ответы |
Re: Proposal: Multiversion page api (inplace upgrade)
|
| Список | pgsql-hackers |
Heikki Linnakangas wrote: > Zdenek Kotala wrote: > > 4) Implementation > > > > The main point of implementation is to have several version of > > PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct > > structure will be handled in special branch (see examples). > > (this won't come as a surprise as we talked about this in PGCon, but) I > think we should rather convert the page structure to new format in > ReadBuffer the first time a page is read in. That would keep the changes > a lot more isolated. > > Note that you need to handle not only page header changes, but changes > to internal representations of different data types, and changes like > varvarlen and combocid. Those are things that have happened in the past; > in the future, I'm foreseeing changes to the toast header, for example, > as there's been a lot of ideas related to toast options compression. I understand the goal of having good modularity (not having ReadBuffer modify the page), but I am worried that doing multi-version page processing in a modular way is going to spread version-specific information all over the backend code, making is harder to understand. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: