Re: calculating an aspect of shared buffer state from a background worker

Robert Berry <berrydigital(at)gmail(dot)com> writes:
> I'm looking at doing a calculation to determine the number of free buffers
> available. A n example ratio that is based on some data structures in
> freelist.c as follows:

> (StrategyControl->lastFreeBuffer - StrategyControl->firstFreeBuffer) /
> (double) NBuffers

> Is there a way to get access to the StrategyControl pointer in the context
> of a background worker?

The BufferStrategyControl struct is in shared memory, so you can certainly
get at it. One way would be to modify freelist.c to export its static
pointer variable. Alternatively, you could call ShmemInitStruct an extra
time to look up the struct for yourself, and then save it in your own
static variable.

Having said that, though, I'm pretty dubious of the premise. I trust you
realize that the above calculation is entirely wrong; firstFreeBuffer and
lastFreeBuffer are list head and tail pointers, and have no numerical
relation to the list length. The only way to determine the list length
accurately would be to chase down the whole list, which you'd have to hold
the BufFreelistLock while doing, which'd be disastrous for performance if
the list was long. (If you're okay with modifying the backend code you
could dodge this by teaching freelist.c to maintain a counter, I guess.)

An even bigger issue is that it's not clear that the length of the free
list is actually a useful number to have; in steady-state usage it
frequently is always zero. Buffers only get put back on the freelist if
they're invalidated, eg by dropping the relation they belonged to. Normal
usage tends to allocate buffers by reclaiming ones whose usage_count has
reached zero in the clock sweep algorithm. So a better picture of the
availability of buffers would require scanning the buffer pool to see how
many there are of each usage_count level.

regards, tom lane