Matthias-Christian Ott wrote: > On 2016-01-25 16:47, Richard Hipp wrote: >> On 1/25/16, Matthias-Christian Ott <ott at mirix.org> wrote: >>> >>> Does this mean that if I use SQLite SQLITE_EXTRA_DURABLE=0, PRAGMA >>> journal_mode=DELETE and PRAGMA synchronous=FULL, SQLite could loose a >>> transaction that it said to be committed depending on the VFS? >> >> Sort of. This appears to be true if you are running on QNX and you >> lose power (or do a hard reset) shortly after the transaction commits. >> It might be the case on other OSes/filesystems but it has never before >> been observed. >> >> This is not new behavior. This is apparently what SQLite has been >> doing for 15 years, across quadrillions of transactions on many >> billions of devices, and it has never before caused any issues, until >> just recently when Mr. Meinlschmidt upgraded to a newer version of >> QNX. > > So it would make sense to add a note that you should check whether your > target VFS and target operating environment needs an fsync after a > journal commit if you want to use this journal mode. Would it be > possible to make SQLITE_EXTRA_DURABLE a pragma? Some GNU/Linux > distributions package SQLite and therefore not every application can > compile SQLite with different options.
The question isn't just whether "an fsync is needed" with journal mode - the question is *which* fsync is needed? The issue here is that file creation/deletion/rename ops require an fsync *on the containing directory*. This is actually quite an unusual requirement; on older Unix systems you couldn't even *open* a directory, let alone obtain write access to it or fsync it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
