* Greg Stark <greg.stark@enterprisedb.com> [081002 13:37]:
> It's not the buffeting it's the checksum. The problem arises if a page
> is read in but no wal logged modifications are done against it. If a
> hint bit is modified it won't be wal logged but the page is marked
> dirty.
>
> When we write the page there's a chance only part of the page actually
> makes it to disk if the system crashes before the whole page is flushed.
Yup, Brucess message pointed me in the right direction..
> Wal logged changes are safe because of full_page_writes. Hint bits are
> safe because either the old or the new value will be on disk and we
> don't care which. It doesn't matter if some hint bits are set and some
> aren't.
>
> However the checksum won't match because the checksum will have been
> calculated on the whole block and part of it was never written.
Correct. But now doesn't full-page-writes give us the same protection
here against a half-write as it did for the previous case?
On recovery after a torn-page write, won't the recovery of the
full_page_write WAL + WAL changes get us back to the page as it was
before the buffer+checksum+write? The checksum on that block *now in
memory* is irrelevant, because it wasn't "read from disk", it was
completely constructed from WAL records, which are protected by
checksums themselves individually..., and is now ready to be "written to
disk" which will force a valid checksum to be on it.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
