pgsql@mohawksoft.com writes:
>> That actually seems like a really good idea.
> I don't think it make sense at all!!!
> If you are going to double buffer, one presumes that for some non-zero
> period of time, the block must be locked during which it is copied. You
> wouldn't want it changing "mid-copy" would you? How is this any less of a
> hit than just calculating the checksum?
It only has to be share-locked. That locks out every change *but* hint
bit updates, and we don't really care whether we catch a hint bit update
or not, so long as it doesn't break our CRC. This is really exactly the
same way it works now: there is no way to know whether the page image
sent to the kernel includes hint bit updates made after the write() call
starts. But we don't care. (The JUST_DIRTIED business ensures that
we'll catch any such hint bit update next time.)
Thought experiment: suppose that write() had some magic option that made
it calculate a CRC on the data after it was pulled from userspace, while
it's sitting in a kernel buffer. Then we'd have exactly the same
guarantees as we do now about the consistency of data written to disk,
except that the CRC magically got in there too. The double-buffer idea
implements exactly that behavior, without any magic write option.
regards, tom lane