Re: [WIP] In-place upgrade - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [WIP] In-place upgrade
Date
Msg-id 603c8f070811050432i2495bc94i8ab8fff65bf60c33@mail.gmail.com
Whole thread Raw
In response to Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: [WIP] In-place upgrade  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
> 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


pgsql-hackers by date:

Previous
From: "Ibrar Ahmed"
Date:
Subject: pg_dump roles support [Review]
Next
From: Dmitry Turin
Date:
Subject: Re: SQL5 budget