Re: Page-level version upgrade (was: Block-level CRC checks) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Page-level version upgrade (was: Block-level CRC checks)
Date
Msg-id 407d949e0912021230o5f2b2606o7064eec9302b9ca9@mail.gmail.com
Whole thread Raw
In response to Re: Page-level version upgrade (was: Block-level CRC checks)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Page-level version upgrade (was: Block-level CRC checks)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 2, 2009 at 6:34 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Also, your logic seems to presume that no backports are possible to the old
>> server.
>
> The problem on the table at the moment is that the proposed CRC
> feature will expand every page by a uniform amount - so in this case a
> fixed-space-per-page reservation utility would be completely adequate.
>  Does anyone think this is a realistic thing to backport to 8.4?

This whole discussion is based on assumptions which do not match my
recollection of the old discussion. I would suggest people go back and
read the emails but it's clear at least some people have so it seems
people get different things out of those old emails. My recollection
of Tom and Heikki's suggestions for Zdenek were as follows:

1) When 8.9.0 comes out we also release an 8.8.x which contains a new
guc which says to prepare for an 8.9 update. If that guc is set then
any new pages are guaranteed to have enough space for 8.9.0 which
could be as simple as guaranteeing there are x bytes of free space, in
the case of the CRC it's actually *not* a uniform amount of free space
if we go with Tom's design of having a variable chunk which moves
around but it's still just a simple arithmetic to determine if there's
enough free space on the page for a new tuple so it would be simple
enough to backport.

2) When you want to prepare a database for upgrade you run the
precheck script which first of all makes sure you're running 8.8.x and
that the flag is set. Then it checks the free space on every page to
ensure it's satisfactory. If not then it can do a noop update to any
tuple on the page which the new free space calculation would guarantee
would go to a new page. Then you have to wait long enough and vacuum.

3) Then you run pg_migrator which swaps in the new catalog files.

4) Then you shut down and bring up 8.9.0 which on reading any page
*immediately* converts it to 8.9.0 format.

5) You would eventually also need some program which processes every
page and guarantees to write it back out in the new format. Otherwise
there will be pages that you never stop reconverting every time
they're read.

--
greg


pgsql-hackers by date:

Previous
From: "Little, Douglas"
Date:
Subject: Ragged CSV import
Next
From: Tom Lane
Date:
Subject: Re: Adding support for SE-Linux security