Skip site navigation (1) Skip section navigation (2)

Re: Display Pg buffer cache (WIP)

From: Neil Conway <neilc(at)samurai(dot)com>
To: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Display Pg buffer cache (WIP)
Date: 2005-03-04 01:49:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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:

The locking scheme is described here:

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).


In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2005-03-04 04:04:07
Subject: Re: Display Pg buffer cache (WIP)
Previous:From: Mark KirkwoodDate: 2005-03-04 00:30:36
Subject: Re: Display Pg buffer cache (WIP)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group