From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Final(?) proposal for wal_sync_method changes |
Date: | 2010-12-11 13:27:37 |
Message-ID: | AANLkTinZR_N4HgEJ2SH7ZWx-w6Qvrzwm__yAL__f8=rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 8, 2010 at 15:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Wed, Dec 8, 2010 at 02:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2010-12-11 14:17:44 | Re: proposal: auxiliary functions for record type |
Previous Message | Magnus Hagander | 2010-12-11 13:18:26 | Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags |