Re: [WIP] In-place upgrade

I don't think this really qualifies as "in place upgrade" since it
would mean creating a whole second copy of all your data. And it's
only online got read-only queries too.

I think we need a way to upgrade the pages in place and deal with any
overflow data as exceptional cases or else there's hardly much point
in the exercise.

greg

On 5 Nov 2008, at 07:32 AM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:

>> An old page which never goes away. New page formats are introduced
>> for a
>> reason -- to support new features. An old page lying around
>> indefinitely means
>> some pages can't support those new features. Just as an example,
>> DBAs may be
>> surprised to find out that large swathes of their database are
>> still not
>> protected by CRC checksums months or years after having upgraded to
>> 8.4 (or
>> even 8.5 or 8.6 or ...). They would certainly want a way to ensure
>> all their
>> data is upgraded.
>
> OK, I see your point. In the absence of any old snapshots,
> convert-on-write allows you to forcibly upgrade the whole table by
> rewriting all of the tuples into new pages:
>
> UPDATE table SET col = col
>
> In the absence of page expansion, you can put logic into VACUUM to
> upgrade each page in place.
>
> If you have both old snapshots that you can't get rid of, and page
> expansion, then you have a big problem, which I guess brings us back
> to Heikki's point.
>
> ...Robert