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" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
