Mark Kirkwood wrote:
A couple of minor amendments here:
- remove link to libpq (from cut+past of dblnk's Makefile)
- add comment for pg_buffercache module in contrib/README
- change my listed email to this one (I have resigned)
Applied, thanks for the patch.
BTW, I removed the REGRESS=... line
A couple of minor amendments here:
- remove link to libpq (from cut+past of dblnk's Makefile)
- add comment for pg_buffercache module in contrib/README
- change my listed email to this one (I have resigned)
regards
Mark
diff -Nacr pgsql.orig/contrib/Makefile pgsql/contrib/Makefile
***
Tom Lane wrote:
I would rather see this as a contrib module. There has been *zero*
consensus that we need this in core, nor any discussion about whether
it might be a security hole.
Hmmm, I guess my motivation for thinking it might be useful in core was
that it was similar to 'pg_locks' and
Neil Conway wrote:
Mark Kirkwood wrote:
+ TupleDescInitEntry(tupledesc, (AttrNumber) 5, relblockbumber,
+ NUMERICOID, -1, 0);
I think this should be an int4, not numeric.
I was looking for an UINT4OID :-), but numeric seemed the best
compromise (safer
Tom Lane wrote:
One reason for making it contrib is that I don't think you've got it
entirely right yet, and there will be several iterations before it
settles down. In a contrib module that is no problem, in core it's a
forced initdb each time.
Yeah - certainly less intrusive as a contrib if
Mark Kirkwood wrote:
Tom Lane wrote:
One reason for making it contrib is that I don't think you've got it
entirely right yet, and there will be several iterations before it
settles down. In a contrib module that is no problem, in core it's a
forced initdb each time.
Yeah - certainly less
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
Mark Kirkwood wrote:
+ tupledesc = CreateTemplateTupleDesc(NUM_BUFFERCACHE_PAGES_ELEM,
false);
+ TupleDescInitEntry(tupledesc, (AttrNumber) 1, bufferid,
+
INT4OID, -1, 0);
+
Neil Conway [EMAIL PROTECTED] writes:
Mark Kirkwood wrote:
+TupleDescInitEntry(tupledesc, (AttrNumber) 5, relblockbumber,
+
NUMERICOID, -1, 0);
I think this should be an int4, not numeric.
needs spell check too
Tom Lane wrote:
Perhaps OID would be a good choice even though it's horribly wrong on
one level.
Either that or add unsigned numeric types to PG :-)
I would rather see this as a contrib module.
I don't really have an opinion either way. Does anyone else have
thoughts on this?
There has been
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
Only two things to add: you forgot to add `cachedump.o' to the list of
OBJS in the utils/adt Makefile.
Mark Kirkwood wrote:
+typedef struct
+{
+ uint32 bufferid;
+ Oid relfilenode;
+ Oid reltablespace;
+ Oid
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
Neil Conway wrote:
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
Mark Kirkwood [EMAIL PROTECTED] writes:
In addition to holding the BufMappingLock, each buffer header is (spin)
locked before examining it, hopefully this is correct - BTW, I like the
new buffer lock design.
It'd be possible to dispense with the per-buffer spinlocks so long as
you look only at
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
I am using anoncvs from yesterday, so if Tom's new scheme is
*very* new I may be missing it.
It's not committed yet ;-)
Yep - that's pretty new, apologies for slow grey matter... I have been
following the discussion about the new buffer
Neil Conway wrote:
I don't like accessing shared data structures without acquiring the
appropriate locks; even if it doesn't break anything, it seems like just
asking for trouble. In order to be able to inspect a buffer's tag in
Tom's new locking scheme (not yet in HEAD, but will be in 8.1),
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
Mark Kirkwood [EMAIL PROTECTED] writes:
I am using anoncvs from yesterday, so if Tom's new scheme is
*very* new I may be missing it.
It's not committed yet ;-)
regards, tom lane
---(end of broadcast)---
TIP 5: Have you
I found it useful to be able to look at what relations are occupying the
cache (mainly for debugging and comparing with page estimates).
I am wondering if it might be a useful addition generally?
How it works a SRF called dump_cache() is created, which is then exposed
as system view pg_dump_cache.
Mark Kirkwood wrote:
does not worry too much about a consistent view of the buffer
contents (as I didn't want it to block all other activity!).
I don't like accessing shared data structures without acquiring the
appropriate locks; even if it doesn't break anything, it seems like just
asking for
21 matches
Mail list logo
