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
|
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: