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

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 #