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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
