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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers