Re: Display Pg buffer cache (WIP)

The latest iteration.

I have added documentation and updated the expected output so that the
regression tests pass.

In addition, after looking at the various system view names, I decided
that 'pg_cache_dump' does not fit in nicely - so chose an more Pg
suitable name of 'pg_buffercache'. Some renaming of the backend
functions happened too. Finally, since I was saving blocknum, it went
into the view as well.

Hopefully I am dealing with invalid buffer tags sensibly now. The
per-buffer spin lock is still being held - altho it is obviously trivial
to remove if not actually required.

regards

Mark

P.s : remembered to use diff -c

Mark Kirkwood wrote:
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)