* Tom Lane <tgl@sss.pgh.pa.us> [081113 14:43]:
> Well, if we adopt the double buffering approach then the ex-lock would
> only need to be held for long enough to copy the page contents to local
> memory. So maybe this would be acceptable. It would certainly be a
> heck of a lot simpler than any workable variant of the current patch
> is likely to be; and we could simplify some existing code too (no more
> need for the BM_JUST_DIRTIED flag for instance).
Well, can we get rid of the PD_UNLOGGED_CHANGE completely?
I think that if the buffer is dirty (FlushBuffer was called, and you've gotten
through the StartBufferIO and gotten the lock), you can just WAL log the hint
bits from the *local double-buffered* "page" (don't know if the current code
allows it easily)
If I understand tom's objections its that with the shared lock, other hint bits
may still change... But we don't relly care if we get all the hint bits to WAL
in our write, what we care about is that we get the hint-bits *that we
checksummed* to WAL. You'll need throw the CRC in the WAL as well for the
really paranoid. That way, if the write is torn, on recovery, the correct hint
bits and matching CRC will be available.
This means your chewing up more WAL. You get the WAL record for all the hint
bits on every page write. For that you get:
1) Simplified locking (and maybe with releasing the lock before the write shorter lock hold-times)
2) Simplified CRC/checksum (don't have to try and skip hint-bits)
3) HINT bits WAL logged even for blocks written that aren't hint-bit only
You trade WAL and simplicity for verifiable integrety.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.