Re: A sniffer for the buffer

Jonas J wrote:
> Buffer
> ReadBuffer(Relation reln, BlockNumber blockNum)...
>     fprintf(fp,"Read Block n: %d\n",(int) blockNum);
The "key" as it were for database blocks read is both of the things 
passed into ReadBuffer.  You'd need to save both the Relation number 
(which turns into the subdirectory used to store that table in the base/ 
directory) and the block number to do anything useful with this data.


> static void
> write_buffer(Buffer buffer, bool unpin)
> {
>     volatile BufferDesc *bufHdr;
>
>     /*jjeske starts here */
>     FILE *fp;
>     fp = fopen("/home/jjeske/tpccuva/pgsql/saida.txt","a");   
>     fprintf(fp,"Write Block n: %d\n",(int) buffer);
>     fclose(fp);
And that won't work at all.  "Buffer" is a structure, not an integer.  
You need to wait until it's been locked, then save the same data as on 
the read side (relation and block number) from inside the structure.  
You probably want to hook FlushBuffer to do that job.  In fact, there's 
already a DTrace probe in there you could easily use to collect the data 
you want without even touching the source code if you can get a DTrace 
capable system.  Note the following code in bufmgr.c FlushBuffer:
   TRACE_POSTGRESQL_BUFFER_FLUSH_START(buf->tag.forkNum,                                       buf->tag.blockNum,
                               reln->smgr_rnode.spcNode,                                       reln->smgr_rnode.dbNode,
                                     reln->smgr_rnode.relNode);
 

That's exporting everything you're trying to save yourself such that a 
DTrace program can observe it. 

In fact, I'd suggest that any time you're trying to get some data out of 
the internals, start by seeing if there's a DTrace probe point with that 
info in it alread, because those have been thought through to make sure 
they're exporting the right data and in the right way (i.e. after 
locking the structures properly).  On the read side, 
TRACE_POSTGRESQL_BUFFER_READ_START inside of ReadBuffer_common is the 
one you should do the same thing as, if you must export this stuff 
manually rather than use DTrace.

There's more about the locking I'm alluding to inside 
src/backend/storage/buffer/README , you should check out that file for 
more info.

P.S. I think you're using a fairly old version of the PostgreSQL source 
code, which may not have the same names and DTrace points I'm 
mentioning.  That's probably a mistake--if you want to hack on the 
PostgreSQL code, you should be using at least PostgreSQL 8.4, and it's 
better still to checkout from the CVS/git repos.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com