Mark Kirkwood wrote:
> If so, it looks like I need to do some stuff with ResourceOwners,
> otherwise ReleaseBuffer will fail (or am I wandering up the wrong track
> here?). I am using anoncvs from yesterday, so if Tom's new scheme is
> *very* new I may be missing it.
It's so new, in fact, it's not in CVS yet :) I believe the latest
revision of the patch is here:
http://archives.postgresql.org/pgsql-patches/2005-02/msg00115.php
The locking scheme is described here:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00391.php
Holding the per-buffer header spinlock should be enough to ensure the
tag doesn't change. To get a globally consistent snapshot of the state
of the bufmgr, I believe it should be sufficient to also share-lock the
BufMappingLock for the duration of the scan. The latter will prevent new
pages from being loaded in the buffer pool, so I'm not sure if it's
worth doing. If you do decide to hold the BufMappingLock, it might make
sense to:
1. allocate an array of NBuffers elements
2. acquire BufferMappingLock in share mode
3. sequentially scan through the buffer pool, copying data into the array
4. release the lock
5. on each subsequent call to the SRF, format and return an element of
the array
Which should reduce the time to lock is held. This will require
allocating NBuffers * size_of_stats memory (where size_of_stats will be
something like 16 bytes).
-Neil
