Re: Proposal: Multiversion page api (inplace upgrade)

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 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.

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.

regards, tom lane