On Jan 25, 2016, at 8:47 AM, Richard Hipp <drh at sqlite.org> wrote: > > The feedback I receive is that most users of SQLite would much rather > avoid the extra directory syncs, even if it means having the last > transaction rollback following a power loss.
Why not do the directory fsync in sqlite3_close_v2()? As I understand the original problem, this is happening in a system doing a controlled shutdown, not a crash or spontaneous reboot. I?m close to this problem at the moment because we recently switched to using WAL mode by default, and I noticed that if there is a code path that causes sqlite3_close_v2() to be skipped, the WAL file remains behind, causing a SQLITE_NOTICE_RECOVER_WAL complaint when the app starts back up again. If the last writer to a SQLite DB closes its connection down gracefully, there should be no uncertainty about whether all transactions have durably hit the disk. I can live with such uncertainty if the last writer *doesn?t* gracefully close its connection. That?s kind of concomitant with using an in-process DBMS. (Contrasting with a client-server DBMS, where durability is not compromised if a remote client disappears after COMMIT without gracefully closing its TCP connection afterward.)
