Not in general. Besides, with a write-back cache an fsync() is very nearly
'free', as the controller will report the write as completed as soon as it's
written to cache.
I keep meaning to benchmark the difference, but I only have the facility on
a production box, so caution gets the better of me every time :-)
AFAIK the fsync calls are used to guarantee the _ordering_ of writes to
permanent storage (i.e. fsync() is called before doing something, rather
than after doing something. So PG can be sure that before it does B, A has
definitely been written to disk).
But I could well be wrong. And there could well be strategies exploitable
with the knowledge that a write-back cache exists that aren't currently
implemented - though intuitively I doubt it.
M
> -----Original Message-----
> From: Palle Girgensohn [mailto:girgen@pingpong.net]
> Sent: 29 September 2003 22:32
> To: Matt Clark; rj@last.fm; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] advice on raid controller
>
>
> Stupid question, perhaps, but would a battery-backed cache make
> it safe to
> set fsync=false in postgresql.conf?
>
> /Palle
>
> --On söndag, september 28, 2003 13.07.57 +0100 Matt Clark
> <matt@ymogen.net>
> wrote:
>
> > As others have mentioned, you really ought to get
> battery-backed cache if
> > you're doing any volume of writes. The ability to do safe write-back
> > caching makes an *insane* difference to write performance.
>
>
>
>
>
