From: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Display Pg buffer cache (WIP) |
Date: | 2005-03-06 22:47:44 |
Message-ID: | 422B8890.7050805@coretech.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway wrote:
> Tom Lane wrote:
>
>> It'd be possible to dispense with the per-buffer spinlocks so long as
>> you look only at the tag (and perhaps the TAG_VALID flag bit). The
>> tags can't be changing while you hold the BufMappingLock.
>
>
> That's what I had thought at first, but this comment in buf_internals.h
> dissuaded me: "buf_hdr_lock must be held to examine or change the tag,
> flags, usage_count, refcount, or wait_backend_id fields." The comment
> already notes this isn't true if you've got the buffer pinned; it would
> be worth adding another exception for holding the BufMappingLock, IMHO.
>
>> I'm dubious that there's any point in recording information as
>> transient as the refcounts and dirtybits
>
>
> I think it's worth recording dirty bits -- it provides an indication of
> the effectiveness of the bgwriter, for example. Reference counts could
> be done away with, although I doubt it would have a significant effect
> on the time spent holding the lock.
>
>
Let's suppose refcount is eliminated. I will then be examining the tag,
flags and buf_id elements of the buffer. Holding the BufMappingLock
prevents the tag changing, but what about the flags?
In addition Tom pointed out that I am not examining the BM_TAG_VALID or
BM_VALID flag bits (I am only checking if tag.blockNum equals
InvalidBlockNumber). My initial thought is to handle !BM_TAG_VALID or
!BM_VALID similarly to InvalidBlockNumber i.e all non buf_id fields set
to NULL.
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2005-03-07 01:19:31 | Re: Continue transactions after errors in psql |
Previous Message | Pavel Stehule | 2005-03-06 20:51:49 | Re: Implementation of SQLCODE and SQLERRM variables for |