Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Tom Lane wrote:
> Well, yes they are.  They cause unnecessary process wakeups and thereby
> consume cycles even when the database is idle.  See for example a
> longstanding complaint here:
> https://bugzilla.redhat.com/show_bug.cgi?id=252129
>
> If we're going to go to the trouble of having a mechanism like this,
> I'd like it to fix that problem so I can close out that bug.
>   

The way the background writer wakes up periodically to absorb fsync 
requests is already way too infrequent on a busy system.  That component 
of the bug report reeks as "not a bug" to me.  Don't like the default?  
Increase bgwriter_delay; move on with your life.  We're not going to 
increase the default, to screw over regular users, just to instead 
prioritize people who prefer low power consumption.  There's a knob for 
it, you can tune the other way if you want.  And based on this pile of 
data I'm sorting through the last few weeks, my guess is that if the 
default is going anywhere in 9.1 it's to make the BGW run *more* often, 
not less.  What those asking for the default change don't realize is 
that if the BGW stops doing useful work, backends will start doing more 
disk writes with their own fsync calls, and now you've just messed with 
out how often the disks have to be powered up.  I could probably 
construct a test case that uses more power with the behavior they think 
they want than the current one does.  The only clear case where this is 
always a win is when the system it totally idle.

The complaint that there's no similar way to detune the logger for lower 
power use, something you can't really tweak on your own, is a much more 
reasonable demand.

I have a patch that adds a new column to pg_stat_bgwriter to count how 
often backend fsync calls happen directly, because the background writer 
couldn't be bothered to absorb them.  If this latching idea goes 
somewhere, that should be a reasonable way to measure if the new 
implementation is getting in the way of that particular processing 
requirement.  It's important to realize that the fsync absorb function 
of the background writer has become absolutely critical on modern 
systems that hit high transaction rates, so any refactoring of its basic 
design needs to stay responsive to those incoming backend requests.  I 
don't see any high-level issues with the latch design approach Heikki 
has proposed in regards to that.  I'll take a look at some of the other 
test cases I have here to see if they can help quantify its impact on 
this aspect of BGW behavior.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us