FYI: If you use "PRAGMA journal_mode=WAL;" with "PRAGMA synchronous=NORMAL;", then fsync()s will only occur during a checkpoint operation. And, you can turn off automatic checkpointing and run checkpoints from a separate thread or process, and let that separate thread or process take the fsync() delays, if you want.
On Thu, Jan 16, 2014 at 4:46 PM, Ward Willats <sqlite-us...@wardco.com>wrote: > > On Jan 16, 2014, at 12:02 PM, Richard Hipp <d...@sqlite.org> wrote: > > > Do not compile with SQLITE_NO_SYNC. > > Okay. Thanks. > > > On Jan 16, 2014, at 1:29 PM, Roger Binns <rog...@rogerbinns.com> wrote: > > > > >> On 16/01/14 11:43, Ward Willats wrote: > >> So it looks like fsync() is taking more than the 5 second timeout I've > >> set. > > > > This is not uncommon on mobile devices using flash based storage. There > > is a lot of volatility in read and write performance. > > I knew 5 seconds was a lot, but I've also seen multi-second delays working > with (erasing) flash in other contexts, so it didn't seem impossible. > Also, this is very rare, we test A LOT and this has only happened once. > > I am assuming the "BEGIN IMMEDIATE" the other thread that gets the busy > error is doing *does* go through the default busy handler usleep() > machinery if it can't get its lock right away though, yes? > > If so, I'll just crank up the timeout. If not, I'll have to put in some > retry logic of my own. > > Thanks both, > > -- Ward > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
