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(at)2ndQuadrant(dot)com www.2ndQuadrant.com