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

On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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.

Uh, really?  I don't think that's possible at all.

>> 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.

Me neither.

...Robert