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