Re: Block-level CRC checks

Gregory Stark wrote:
> Paul Schlie writes:
>
>> Heikki Linnakangas wrote:
>>>> Gregory Stark wrote:
>>>> However you still have a problem that someone could come along and set the
>>>> hint bit between calculating the CRC and actually calling write.
>>>
>>> The double-buffering will solve that.
>>
>> Or simply require that hint bit writes acquire a write lock on the page
>> (which should be available if not being critically updated or flushed);
>> thereby to write/flush, simply do the same, calc it's crc, write/flush to
>> disk, then release it's lock; and which seems like the most reliable thing
>> to do (although no expert on pg's implementation by any means).
>>
>> As I would guess although there may be occasional lock contention, its
>> likely minor, and greatly simplify the whole process it would seem?
>
> Well it would be a lot more locking than now. You're talking about locking
> potentially hundreds of times per page scanned as well as locking when doing
> a write which is potentially a long time since the write can block.

- I guess one could define another lock, specifically for hint bits; thereby
a page scan would not need that lock, but hint bit updates could use it in
combination with a page flush requiring both a share lock and the hint bit
lock. (but don't know if its overall better than copying)

> It would be the simplest option. Perhaps we should test whether it's actually
> a problem.
>
>> (unless I misunderstand, even double buffering requires a lock, as if
>> multiple hint bits may be updated during the copy, the resulting copy may be
>> inconsistent if only partially reflecting the updates in progress)
>
> No you only need a share lock to do the copy since there's nothing wrong
> "inconsistent" sets of hint bits as long as you're checksumming the same copy
> you're putting on disk.

Understood, thanks.