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

From Robert Haas
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id CA+TgmobV-nZmC7y5=ED099Qoc_jAPDCV7sQ+w5OiH4UfeDUJUg@mail.gmail.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Sun, Dec 25, 2011 at 5:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Sat, Dec 24, 2011 at 8:06 PM, Greg Stark <stark@mit.edu> wrote:
>> On Sat, Dec 24, 2011 at 4:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Checksums merely detect a problem, whereas FPWs correct a problem if
>>> it happens, but only in crash situations.
>>>
>>> So this does nothing to remove the need for FPWs, though checksum
>>> detection could be used for double write buffers also.
>>
>> This is missing the point. If you have a torn page on a page that is
>> only dirty due to hint bits then the checksum will show a spurious
>> checksum failure. It will "detect" a problem that isn't there.
>
> It will detect a problem that *is* there, but one you are classifying
> it as a non-problem because it is a correctable or acceptable bit
> error.

I don't agree with this.  We don't WAL-log hint bit changes precisely
because it's OK if they make it to disk and it's OK if they don't.
Given that, I don't see how we can say that writing out only half of a
page that has had hint bit changes is a problem.  It's not.

(And if it is, then we ought to WAL-log all such changes regardless of
whether CRCs are in use.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: reprise: pretty print viewdefs
Next
From: Robert Haas
Date:
Subject: Re: Moving more work outside WALInsertLock