Re: Block-level CRC checks - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Block-level CRC checks
Date
Msg-id 200912042000.nB4K0nB02130@momjian.us
Whole thread Raw
In response to Re: Block-level CRC checks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Block-level CRC checks
List pgsql-hackers
Robert Haas wrote:
> > Well, I am not sure how we would turn the _space_ used for CRC on and
> > off because you would have to rewrite the entire table/database to turn
> > it on, which seems unfortunate.
> 
> Well, presumably you're going to have to do some of that work anyway,
> because even if the space is set aside you're still going to have to
> read the page in, CRC it, and write it back out.  However if the space
> is not pre-allocated then you also have to deal with moving tuples to
> other pages.  But that problem is going to have to be dealt with
> somewhere along the line no matter what we do, because if you're
> upgrading an 8.3 or 8.4 system to 8.5, you need to add that space
> sometime: either before migration (with a pre-upgrade utility), or
> after migration (by some sort of page converter/tuple mover), or only
> when/if enabling the CRC feature.
> 
> One nice thing about making it the CRC feature's problem to make space
> on each page is that people who don't want to use CRCs can still use
> those extra 4 bytes/page for data.  That might not be worth the code
> complexity if we were starting from scratch, but I'm thinking that
> most of the code complexity is a given if we want to also support
> in-place upgrade.

My guess is we can find somewhere on a 8.4 heap/index page to add four
bytes.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tim Bunce
Date:
Subject: Re: First feature patch for plperl - draft [PATCH]
Next
From: Dimitri Fontaine
Date:
Subject: Re: First feature patch for plperl - draft [PATCH]