Tuning for PostGreSQL Database

Jason Stone freebsd-performance at dfmm.org
Mon Jul 21 20:35:45 PDT 2003

Hash: SHA1

> > > Softupdates on, async off.  Softupdates is just a better async.
> >
> > postgresql fsync's all its files before returning from a commit in
> > order to ensure durability, right?  Does softupdates interfere with
> > the functioning of sync(2)/fsync(2)?
> It can, yes, but that's the risk of soft updates.  From tuning(7):

Yes, I know - tuning(7) warns that writes may be delayed.  But (data)
writes are always delayed some, and fsync(2) doesn't say anything about a
situation where fsync() would return success and the data would not
actually be written out to disk.

I feel like this is an extremely important point.  If softupdates changes
the semantics of sync(2)/fsync(2), then it absolutely has to be off for a
postgresql server because postgresql counts on fsync in order to make its
durability guarantees.

Additionally, the manpages for sync/fsync should be updated, as I'm sure
there are lots of other consumers of those calls, and, "these calls cause
your dirty buffers to be flushed to disk... except if there's a global
filesystem flag set, in which case they do absolutely nothing," is a
pretty big omission, especially since softupdates is the default these


 Freud himself was a bit of a cold fish, and one cannot avoid the suspicion
 that he was insufficiently fondled when he was an infant.
	-- Ashley Montagu
Version: GnuPG v1.2.1 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg


More information about the freebsd-performance mailing list