From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Multiversion page api (inplace upgrade) |
Date: | 2008-06-11 15:35:17 |
Message-ID: | 484FF0B5.5030005@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2008-06-11 15:42:54 | Re: Proposal: Multiversion page api (inplace upgrade) |
Previous Message | Tom Lane | 2008-06-11 15:15:06 | Re: Proposal: Multiversion page api (inplace upgrade) |