Skip site navigation (1) Skip section navigation (2)

Re: pgsql-server/src backend/storage/buffer/bufmgr ...

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server/src backend/storage/buffer/bufmgr ...
Date: 2004-01-24 20:57:42
Message-ID: 4012DC46.80009@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-committers
Tom Lane wrote:

> wieck(at)svr1(dot)postgresql(dot)org (Jan Wieck) writes:
>> 	Added GUC variable bgwriter_flush_method controlling the action
>> 	done by the background writer between writing dirty blocks and
>> 	napping.
> 	
>> 	none (default)   no action
>> 	sync             bgwriter calls smgrsync() causing a sync(2)
> 
> Why would that be useful at all?  I thought the purpose of the bgwriter
> was to avoid I/O storms, not provoke them.

Calling sync(2) every time the background writer naps means calling it 
every couple hundred milliseconds. That can hardly be called an IO 
storm, it's more like a constant breeze.

So far nobody bothered to make any other proposal how to cause the 
kernel to actually do some writing at all. A lot of people babble about 
fsync(), fdatasync() and fadvise and whatnot. A week ago I posted the 
proposal for this and got exactly zero response.

Before this, the bgwriter did only write the dirty blocks, so that the 
checkpoint (doing the sync() call) still caused all the physical IO to 
happen at once. Sure, with the bgwriter doing the major write IO, he'd 
know what files have been written to and can do fsync() and fdatasync() 
on the. But even with that, the checkpoint doing sync() will be in 
danger to cause a lot of unexpected IO from wherenot, making the time
the checkpoint takes totally unpredictable.

The whole point of the bgwriter is to give responsetimes a better 
variance, I never claimed that it will improve performance.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #


In response to

Responses

pgsql-committers by date

Next:From: Tom LaneDate: 2004-01-24 21:17:03
Subject: Re: pgsql-server/src backend/storage/buffer/bufmgr ...
Previous:From: Neil ConwayDate: 2004-01-24 20:43:26
Subject: pgsql-server/src/bin/psql print.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group