* Tom Lane <[EMAIL PROTECTED]> [081002 11:40]: > "Jonah H. Harris" <[EMAIL PROTECTED]> writes: > > Just to see where to go from here... I want to make sure the options > > I've seen in this thread are laid out clearly: > > > 1. Hold an exclusive lock on the buffer during the call to smgrwrite > > OR > > 2. Doublebuffer the write > > OR > > 3. Do some crufty magic to ignore hint-bit updates > > Right, I think everyone agrees now that #2 seems like the most > preferable option for writing the checksum. However, that still > leaves us lacking a solution for torn pages during a write that > follows a hint bit update. We may end up with some "crufty > magic" anyway for dealing with that.
How does your current "write" strategy handle this situation. I mean, how do you currently guarnetee that between when you call write() and the kernel copies the buffer internally, no hint-bit are updated? #define write(fd, buf, count) buffer_crc_write(fd, buf, count) whatever protection you have on the regular write is sufficient. The time of the protection will need to start before the "buffer" period instead of just the write, (and maybe not the write syscall anymore) but with CPU caches and speed, the buffer period should be <= the time of the write() syscall... Your fsync is your "on disk guarentee", not the write, and that won't change. But I thought you didn't really care about hint-bit updates, even in the current strategy... but I'm fully ignorant about the code, sorry... 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