On Sat, Dec 24, 2011 at 4:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2011-12-25 10:08:09|
|Subject: Re: 16-bit page checksums for 9.2|
|Previous:||From: Greg Stark||Date: 2011-12-24 19:41:04|
|Subject: Re: Moving more work outside WALInsertLock|