On Mon, Dec 5, 2016 at 1:34 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 5 Dec 2016, at 9:26pm, Scott Hess <sh...@google.com> wrote: >> An obvious solution would be to simply not call sqlite3_close(), >> though that has various other unfortunate side effects. > > Yeah. Don’t do that, eh ?
:-). OK, the biggest unfortunate effect is that you don't release the various resources like memory and file descriptors, which in turn means that you spend your time populating exception policies for automated leak detectors and the like. Also, it means you have to have high confidence that you're skipping the close because of shutdown rather than some other reason (like you're closing the database before deleting it). All of this can probably be ground through eventually, but this kind of thing is likely to cause people to wonder if the code is doing the right thing. > What you’re actually trying to do is disable/delay fsync() for > a time for a particular storage device. Can that not be done > at device-driver level ? It would then affect all the programs > writing "I just quit" to their log files too, which would be an > additional benefit. I don't think so, that seems like it could result in corruption. Unless you mean something more like causing the OS to block all fsync calls on the filesystem and release them as a single uber-sync? -scott _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users