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

Robert Haas wrote:
>> Some additional catalog support was suggested to mark what the pre-upgrade
>> utility had processed. I'm sure I could find the messages about again if I
>> had to.
>>
> And that's a perfectly sensible solution, except that adding a catalog
> column to 8.4 at this point would force initdb, so that's a
> non-starter. I suppose we could shoehorn it into the reloptions.
>
There's no reason the associated catalog support had to ship with the
old version. You can always modify the catalog after initdb, but before
running the pre-upgrade utility. pg_migrator might make that change for
you.

> 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?
>
I believe the main problem here is making sure that the server doesn't
turn around and fill pages right back up again. The logic that needs to
show up here has two parts:

1) Don't fill new pages completely up, save the space that will be
needed in the new version
2) Find old pages that are filled and free some space on them

The pre-upgrade utility we've been talking about does (2), and that's
easy to imagine implementing as an add-on module rather than a
backport. I don't know how (1) can be done in a way such that it's
easily backported to 8.4.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com