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
