Re: Final(?) proposal for wal_sync_method changes
Magnus Hagander <magnus@hagander.net>
From: Magnus Hagander <magnus@hagander.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers@postgresql.org
Date: 2010-12-11T13:27:37Z
Lists: pgsql-hackers
On Wed, Dec 8, 2010 at 15:40, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Wed, Dec 8, 2010 at 02:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> [ win32.h says ] >>> #define fsync(fd) _commit(fd) > >>> What this means is that switching to a simple preference order >>> "fdatasync, then fsync" will result in choosing fsync on Windows (since >>> it hasn't got fdatasync), meaning _commit, meaning Windows users see >>> a behavioral change after all. > >> _commit() != fsync() > > Um, the macro quoted above makes them the same, no? One of us > is confused. Uh, yeah. Sorry, that was the unclear:ness from being too preoccupied with the conference.. Pretty sure I'm the confused one. . _commit() is definitely the same as fsync() on the API level. And this correspond to fsync_writethrough, not fsync, when you talk about the wal_sync_method parameter. It will always sync through the write cache, even if it's hardware BBU'ed cache. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/