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

From Robert Haas
Subject Re: Block-level CRC checks
Date
Msg-id 603c8f070912041130h4ce63e74x49d2966deb5202a1@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Dec 4, 2009 at 2:04 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>> > Heikki Linnakangas escribi?:
>> >> Simon Riggs wrote:
>> >> > On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
>> >> >
>> >> >> BTW with VACUUM FULL removed I assume we're going to get rid of
>> >> >> HEAP_MOVED_IN and HEAP_MOVED_OFF too, right?
>> >> >
>> >> > Much as I would like to see those go, no. VF code should remain for some
>> >> > time yet, IMHO.
>> >>
>> >> I don't think we need to keep VF code otherwise, but I would leave
>> >> HEAP_MOVED_IN/OFF support alone for now for in-place upgrade. Otherwise
>> >> we need a pre-upgrade script or something to scrub them off.
>> >
>> > CRCs are going to need scrubbing anyway, no? ?Oh, but you're assuming
>> > that CRCs are optional, so not everybody would need that, right?
>>
>> If we can make not only the validity but also the presence of the CRC
>> field optional, it will simplify things greatly for in-place upgrade,
>> I think, because the upgrade won't itself require expanding the page.
>> Turning on the CRC functionality for a particular table may require
>> expanding the page, but that's a different problem.  :-)
>
> 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.

...Robert


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: First feature patch for plperl - draft [PATCH]
Next
From: Alvaro Herrera
Date:
Subject: Re: Block-level CRC checks