Re: SRA Win32 sync() code - Mailing list pgsql-patches

From Jan Wieck
Subject Re: SRA Win32 sync() code
Date
Msg-id 3FB7D758.20608@Yahoo.com
Whole thread Raw
In response to Re: SRA Win32 sync() code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SRA Win32 sync() code  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Tom Lane wrote:
>>> Seriously though, if we can move the bulk of the writing work into
>>> background processes then I don't believe that there will be any
>>> significant penalty for regular backends.
>
>> If the background writer starts using fsync(), we can have normal
>> backends that do a write() set a shared memory boolean.  We can then
>> test that boolean and do sync() only if other backends had to do their
>> own writes.
>
> That seems like the worst of both worlds --- you still are depending on
> sync() for correctness.
>
> Also, as long as backends only *seldom* do writes, making them fsync a
> write when they do make one will be less of an impact on overall system
> performance than having a sync() ensue shortly afterwards.  I think you
> are focusing too narrowly on the idea that backends shouldn't ever wait
> for writes, and failing to see the bigger picture.  What we need to
> optimize is overall system performance, not an arbitrary restriction
> that certain processes never wait for certain things.

Removing sync() entirely requires very accurate fsync()'ing in the
background writer, the checkpointer and the backends. Basically none of
them can mark a block "clean" if he fails to fsync() the relation later!
This will be a mess to code.


Jan

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


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: SIGPIPE handling
Next
From: Tom Lane
Date:
Subject: Re: SRA Win32 sync() code