Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 74709685-CEFB-4B64-8599-F3F05D6F9BAC@nasby.net
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Jan 6, 2012, at 4:36 AM, Andres Freund wrote:
> On Friday, January 06, 2012 11:30:53 AM Simon Riggs wrote:
>> On Fri, Jan 6, 2012 at 1:10 AM, Stephen Frost <sfrost@snowman.net> wrote:
>>> * Simon Riggs (simon@2ndQuadrant.com) wrote:
>>>> I discover that non-all-zeroes holes are fairly common, just not very
>>>> frequent.
>>>
>>> Curious, might be interesting to find out why.
>>>
>>>> That may or may not be a problem, but not something to be dealt with
>>>> here and now.
>>>
>>> But I agree that it's not the job of this patch/effort.  It sounds like
>>> we have clear indication, however, that those areas, as they are not
>>> necessairly all zeros, should be included in the checksum.
>>
>> Disagree. Full page writes ignore the hole, so its appropriate to do
>> so here also.
> Well, ignoriging them in fpw has clear space benefits. Ignoring them while
> checksumming doesn't have that much of a benefit.

I agree with Andres... we should checksum zero bytes, because if they're screwed up then something is wrong with your
system,even if you got lucky with what data got trashed. 

As I mentioned before, 2 separate checksums would be nice, but if we can't have that I think we need to fail on any
checksumerror. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Buffer overflow in contrib/test_parser/test_parser.c
Next
From: Greg Smith
Date:
Subject: Re: Why is CF 2011-11 still listed as "In Progress"?