On 5 Dec 2016, at 9:46pm, Scott Hess wrote:
> 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?
Yeah, that’s what I meant.
On Mon, Dec 5, 2016 at 1:34 PM, Simon Slavin wrote:
> On 5 Dec 2016, at 9:26pm, Scott Hess 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 ?
On Mon, Dec 5, 2016 at 1:38 PM, Richard Hipp wrote:
> On 12/5/16, Scott Hess wrote:
>> Is there any clean way to request no WAL checkpoint on sqlite3_close()?
>
> sqlite3_db_config(SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, db). See
>
On 12/5/16, Scott Hess wrote:
>
> Is there any clean way to request no WAL checkpoint on sqlite3_close()?
sqlite3_db_config(SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, db). See
https://www.sqlite.org/draft/c3ref/c_dbconfig_enable_fkey.html at the
bottom.
--
D. Richard Hipp
On 5 Dec 2016, at 9:26pm, Scott Hess 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 ?
What you’re actually trying to do is disable/delay fsync() for a time for a
At Chromium shutdown, various services desire to write data to their
SQLite databases, which results in a (small) thundering herd of
fsyncs, which makes shutdown slower than it could be. Normally, one
could enable WAL mode to amortize the fsync cost across longer periods
than a single
6 matches
Mail list logo