=== https://www.sqlite.org/src/timeline?y=ci&c=af92401826f5cf49e62c
=== To clarify: Is it correct to say that, under Linux, if SQLITE_EXTRA_DURABLE is set (and all other settings are left as default values), and with the further assumption that the hardware reports write status accurately to the OS, then SQLITE_OK will only be returned after a transaction is irreversably fixed on the disk? Best regards On Sat, Feb 6, 2016 at 2:45 PM, Richard Hipp <drh at sqlite.org> wrote: > On 2/6/16, Bernard McNeill <bm.email01 at gmail.com> wrote: > > Please can I formally propose that, for Linux: > > 1. A Pragma or other compile-time option is created such that SQLITE_OK > is > > not issued on file writes/modifications/deletes until the hardware > > indicates that all associated Directory syncs, etc., are done. > > https://www.sqlite.org/src/timeline?y=ci&c=af92401826f5cf49e62c > > > 2. Since the absence of 1. appears to break the 'D' in ACID, the option > is > > set on by default, > > No. This would be a serious performance hit for billions and billions > of devices that have soldered-in batteries and generally do not care > about durability in the event of an OS crash. Remember that SQLite > has never synced directories like this before in its 15+ year history > and that was never a problem for anyone until a few weeks ago. If > handset manufacturers, and/or OS vendors, want to make it the default > on their systems, there is a compile-time option for that: > https://www.sqlite.org/draft/compile.html#extra_durable > -- > D. Richard Hipp > drh at sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
