> A disk-block CRC would detect partially written blocks (ie, power drops
> after disk has written M of the N sectors in a block). The disk's own
> checks will NOT consider this condition a failure.
But physical log recovery will rewrite every page that was changed
after last checkpoint, thus t
> > No, I thought we agreed disk block CRC was way overkill. If the CRC on
> > the WAL log checks for errors that are not checked anywhere else, then
> > fine, but I thought disk CRC would just duplicate the I/O subsystem/disk
> > checks.
>
> A disk-block CRC would detect partially written block
At 21:55 11/01/01 -0500, Tom Lane wrote:
>
>Oh. I thought we'd agreed that a CRC on each stored disk block would
>be a good idea as well. I take it you didn't do that.
>
>Do we want to consider doing this (and forcing another initdb)?
>Or shall we say "too late for 7.1"?
>
I thought it was comi
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Oh. I thought we'd agreed that a CRC on each stored disk block would
>> be a good idea as well. I take it you didn't do that.
> No, I thought we agreed disk block CRC was way overkill. If the CRC on
> the WAL log checks for errors that are not check
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> Actually, I'd expect the CRC check to catch an all-zeroes page (if
> >> it fails to complain, then you misimplemented the CRC), so that would
> >> be the place to deal with it now.
>
> > I've used standard CRC32 implementation you pointed me to
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Actually, I'd expect the CRC check to catch an all-zeroes page (if
>> it fails to complain, then you misimplemented the CRC), so that would
>> be the place to deal with it now.
> I've used standard CRC32 implementation you pointed me to -:)
> But CR
