On Sep 30, 2010, at 5:02 PM, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Oh, I missed that. Actually, I wasn't really so concerned with >> whether his benchmark is correct. I *am* concerned about being broken >> out of the box on MacOS X. > > Actually, the problem with OSX is that OSX is broken out of the box, > at least by that standard. The system's normal configuration is that > fsync() does nothing,
That is not correct. fsync and friends on Darwin synchronizes I/O and flushes dirty kernel caches to the disk which meets the specification and is distinctly different from doing nothing. "The fsync() function can be used by an application to indicate that all data for the open file description named by fildes is to be transferred to the storage device associated with the file described by fildes in an implementation-dependent manner." http://opengroup.org/onlinepubs/007908799/xsh/fsync.html "On MacOS X, fsync() always has and always will flush all file data from host memory to the drive on which the file resides." http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html > I'm not sure whether we should select fsync_writethrough as the default > on OSX. We don't make an equivalent attempt to prevent OS or storage > malfeasance on other Unixoid platforms --- in fact, I'd say OSX is a bit > ahead of the game in that you *can* force writethrough without resorting > to arcane hacks with hdparm or some such. > > We could definitely stand to be a bit more verbose about documenting > the platform-specific issues in this area. Not only is this issue platform-specific, it is also bus-, controller- and disk-specific. Luckily, hardware that ships from Apple responds properly to F_FULLFSYNC. It's too bad there is no cross-platform way to ask what level of hardware-syncing is available. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
