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:[EMAIL PROTECTED] > Sent: 29 September 2003 22:32 > To: Matt Clark; [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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 > <[EMAIL PROTECTED]> > 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. > > > > > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
