Re: Proposal: Multiversion page api (inplace upgrade)

Bruce Momjian napsal(a):
> 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.

I don't think so. Page already contains page version information inside and
currently we have macros like PageSetLSN. Caller needn't know nothing about
PageHeader representation. It is responsibility of page API to correctly handle
multi version.

The same we can use for tuple access. It is more complicated but I think it is
possible. Currently we several macros (e.g. HeapTupleGetOid) which works on
TupleData structure. "Only" what we need is extend this API as well.

I think in final we will get more readable code.

Zdenek