>data-only sync does not have a performance advantage over a full sync
Does data-only sync have a perf advantage w/synchronous=normal?
Why does data-only sync exist? Is it a perf thing? Reliability? Other?
>Our experience with various Unix flavors teaches us
Windows != Unix. Although FlushFileBuffers is conceptually equivalent to fsync
we're well into the realm of details mattering.
>Nt*() interfaces may cause portability problems for things like WinCE
Not just CE - NtFlushBuffersFileEx was added in Win8. But SQLite can and does
use functions new in the last decade. A simple LoadLibrary/GetProcAddress can
detect availability at runtime, and there's already plenty of #ifdef options. I
already build a custom DLL from amalgamated source (for reasons) and I'm
targeting Win8+ so adding /DSQLITE_ENABLE_WIN_DATASYNC would be trivial.
Likewise enabling this #ifdef SQLITE_OS_WINRT is safe enough since WinRT only
exists on Win8+
I'm trying to understand (a) if this has been considered, (b) if it's planned,
and (c) if I wanted to hack it myself, do the resident experts have any
implementation advice? Both to make it work, and if it's useful what's
likeliest to be smoothest to be accepted as a patch.
- Howard
-----Original Message-----
From: Joe Mistachkin [mailto:j...@mistachkin.com]
Sent: Friday, April 3, 2015 10:35 AM
To: 'General Discussion of SQLite Database'
Cc: Howard Kapustein
Subject: RE: [sqlite] NtFlushBuffersFileEx for SQLITE_SYNC_DATAONLY onWindows ?
Howard Kapustein wrote:
>
> Has anyone considered supporting SQLITE_SYNC_DATAONLY on Windows using
> NtFlushBuffersFileEx?
>
http://msdn.microsoft.com/en-us/library/windows/hardware/hh967720(v=vs.85).a
spx
>
Our experience with various Unix flavors teaches us that data-only sync does
not have a performance advantage over a full sync. And the Nt*() interfaces
may cause portability problems for things like WinCE.
--
Joe Mistachkin
