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

Reply via email to