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

From Greg Stark
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id CAM-w4HOV41T6tXXS6n4o-GMW61jkxgo-8DQ-Px62Yy90COGgoA@mail.gmail.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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.

The problem is that there is no WAL indicating the hint bit change.
And if the torn page includes the new checksum but not the new hint
bit or vice versa it will be a checksum mismatch.

The strategy discussed in the past was moving all the hint bits to a
common area and skipping them in the checksum. No amount of double
writing or buffering or locking will avoid this problem.

-- 
greg


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Moving more work outside WALInsertLock
Next
From: Simon Riggs
Date:
Subject: Re: 16-bit page checksums for 9.2