Re: Proposal: Multiversion page api (inplace upgrade) - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Proposal: Multiversion page api (inplace upgrade)
Date
Msg-id 484FF0B5.5030005@sun.com
Whole thread Raw
In response to Re: Proposal: Multiversion page api (inplace upgrade)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> There are examples:
> 
>> void PageSetFull(Page page)
>> {
>>     switch ( PageGetPageLayoutVersion(page) )
>>     {
>>         case 4 : ((PageHeader_04) (page))->pd_flags |= PD_PAGE_FULL;
>>                   break;
>>         default elog(PANIC, "PageSetFull is not supported on page layout version %i",
>>                 PageGetPageLayoutVersion(page));
>>     }
>> }
> 
>> LocationIndex PageGetLower(Page page)
>> {
>>     switch ( PageGetPageLayoutVersion(page) )
>>     {
>>         case 4 : return ((PageHeader_04) (page))->pd_lower);
>>     }
>>     elog(PANIC, "Unsupported page layout in function PageGetLower.");
>> }
> 
> I'm fairly concerned about the performance impact of turning what had
> been simple field accesses into function calls.  

I use functions now because it is easy to track what's going on. Finally it 
should be (mostly) macros.

> I argue also that since
> none of the PageHeader fields have actually moved in any version that's
> likely to be supported, the above functions are actually of exactly
> zero value.

Yeah, it is why I'm thinking to use page header with unions inside (for example 
TSL/flag field)
and use switch only in case like TSL or flags fields. What I don't know if 
fields in this structure will be placed on same place on all platforms.

> The proposed PANIC in PageSetFull seems like it requires more thought as
> well: surely we don't want that ever to happen.  Which means that
> callers need to be careful not to invoke such an operation on an
> un-updated page, but this proposed coding offers no aid in making sure
> that won't happen.  What is needed there, I think, is some more global
> policy about what operations are permitted on old (un-converted) pages
> and a high-level approach to ensuring that unsafe operations aren't
> attempted.

ad) PANIC
PANIC shouldn't happen because page validation in BufferRead should check 
supported page version.

ad) policy - it is good catch. I think all read page operation should be allowed 
on old page version. Only tuple, LSN, TSL, and special modification should be 
allowed for writing. Addpageitem should invokes page conversion before any 
action happen (if there is free space for tuple, it is possible to convert page 
in to the new format, but after conversion space could be smaller then tuple.).
    Zdenek









pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: Multiversion page api (inplace upgrade)
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: Proposal: Multiversion page api (inplace upgrade)