Paul Schlie <schlie@comcast.net> 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.
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.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning
