On 2 Oct 2008, at 05:51 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> So if PG currently doesn't care about the hit-bits being updated,
> during
> the write, then why should introducing a double-buffer introduce the a
> torn-page problem Tom mentions? I admit, I'm fishing for information
> from those in the know, because I haven't been looking at the code
> long
> enough (or all of it enough) to to know all the ins-and-outs...
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.
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.
Writing this explanation did bring to mind one solution which we had
already discussed for other reasons: not marking blocks dirty after
hint bit setting.
Alternatively if we detect a block is dirty but the lsn is older than
the last checkpoint is that the only time we need to worry? Then we
could either discard the writes or generate a noop wal log record just
for the full page write in that case.