> Simon Riggs wrote:
> On Sat, Dec 24, 2011 at 8:06 PM, Greg Stark wrote:
>> 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.
With *just* this patch, true. An OS crash or hardware failure could
sometimes create an invalid page.
>> 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.
I don't believe that. Double-writing is a technique to avoid torn
pages, but it requires a checksum to work. This chicken-and-egg
problem requires the checksum to be implemented first.
> I completely agree we should do this, but we are unable to do it
> now, so this patch is a stop-gap and provides a much requested
> feature *now*.
Yes, for people who trust their environment to prevent torn pages, or
who are willing to tolerate one bad page per OS crash in return for
quick reporting of data corruption from unreliable file systems, this
is a good feature even without double-writes.
> In the future, we will be able to tell the difference between an
> acceptable and an unacceptable bit error.
A double-write patch would provide that, and it sounds like VMware
has a working patch for that which is being polished for submission.
It would need to wait until we have some consensus on the checksum
patch before it can be finalized. I'll try to review the patch from
this thread today, to do what I can to move that along.
-Kevin