After fixing the assorted breakage discussed yesterday, I still wasn't
seeing any ForwardFsyncRequest requests coming from the bgwriter during
a regression test run, which made me wonder if there was yet another
bug. What I find is that because of the recent increase in the
out-of-the-box shared_buffers setting to 128MB, the regression database
fits comfortably in shared buffers (its total footprint appears to be
about 41MB at the moment). This means that the shared-buffer freelist
never becomes empty, so StrategyGetBuffer never advances the clock sweep
pointer, so after one pass over the buffer pool BgBufferSync decides
that it's lapped the clock sweep and never does anything more.
In short, then, the background writer process is entirely useless for
any database that fits completely into shared buffers. The only
background writes that get generated in such a case are from the
checkpoint sweep, and AFAICT the "backend buffer writes" that get
counted by ForwardFsyncRequest are not true buffer writes but mdextend
calls. (Which likely explains why their number is so consistent over
repeated regression test runs --- the variance is well under 1% for me.)
So that raises two independent sets of questions:
1. Do we like the fact that the bgwriter isn't doing anything in this
situation? It seems arguably OK for writes to happen only for
checkpointing purposes if there is no memory pressure. But having the
bgwriter wake up 5 times a second to decide it has nothing to do seems
a bit wasteful. I'm inclined to think maybe it should go into the
recently added "hibernation mode" anytime the buffer freelist isn't
empty. Or maybe you could argue that this scenario isn't worth any
optimization effort, but with many-gig RAM becoming more and more
common, I don't think I agree.
2. It's rather disturbing that a fairly large swath of functionality
just stopped getting tested at all by the buildfarm. Do we want to
rethink the shared_buffers increase? Or artificially bloat the
regression database to make it larger than 128MB? Or do something else
to ensure we still exercise the DB-bigger-than-buffers case?
regards, tom lane