Re: Page-level version upgrade (was: Block-level CRC checks)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, decibel <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Page-level version upgrade (was: Block-level CRC checks)
Date: 2009-12-02 20:30:07
Message-ID: 407d949e0912021230o5f2b2606o7064eec9302b9ca9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 2, 2009 at 6:34 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-02 20:37:16 Re: Adding support for SE-Linux security
Previous Message Little, Douglas 2009-12-02 20:19:38 Ragged CSV import