Re: A sniffer for the buffer - Mailing list pgsql-hackers

From Greg Smith
Subject Re: A sniffer for the buffer
Date
Msg-id 4B1BE40A.2050709@2ndquadrant.com
Whole thread Raw
In response to A sniffer for the buffer  (Jonas J <autoramajj@gmail.com>)
Responses Re: A sniffer for the buffer  (Daniel Farina <drfarina@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error message translation, with variable reason text
Next
From: Heikki Linnakangas
Date:
Subject: Re: Hot standby, recent changes