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: 4227BEC4.3020607@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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:

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-03-04 04:04:07 Re: Display Pg buffer cache (WIP)
Previous Message Mark Kirkwood 2005-03-04 00:30:36 Re: Display Pg buffer cache (WIP)