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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
