* Tom Lane <[EMAIL PROTECTED]> [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, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
