Hi Clemens, Here are some of the settings and the integrity check that we always prints at start up of our process:
[query:PRAGMA synchronous=OFF][changes:0][total changes:0] [query:PRAGMA foreign_keys=ON][changes:0][total changes:0] [query:PRAGMA cache_size=10000][changes:0][total changes:0] [query:PRAGMA journal_mode=WAL][changes:0][total changes:0] OrderCallbackStorage::checkDatabaseIntegrity: row 1 [ok] No virtualization and also no network file system. What do you exactly mean with "But in any case, as others have already said, it is not possible for a write transaction to lock out a read transaction _in the middle_."? I do see that records are being inserted while I made those stack traces. I have a fifteen minute window / 24hours, is it enough for VACUUM? the database file and wal file are at the moment around 700KiB and 500KiB resp. Probably that can't be answered and I should just try it. We'll check the disk for bad sector(s). Thanks for your help! Gunnar On 09/25/2015 03:40 PM, Clemens Ladisch wrote: > gunnar wrote: >> (select uuid from session where date = (select max(date) from session)) > This can be optimized to > (select uuid from session order by date desc limit 1) > but the speed of this subquery does not matter. > >> (SELECT max(cb_seq_num) FROM ordercallback WHERE >> server_order_id=cb.server_order_id AND sessionuuid=cb.sessionuuid AND >> working=1) >> 3|0|0|SEARCH TABLE ordercallback USING INDEX ordercallback_index3 >> (server_order_id=? AND sessionuuid=? AND working=?) > You could try to speed this up with a covering index by adding the > cb_seq_num column to the index. > > > But in any case, as others have already said, it is not possible for > a write transaction to lock out a read transaction _in the middle_. > > Are you using WAL? Some network file system? Virtualization? > > If neither the CPU nor the disk are busy, but SQLite is not sleeping, > then what is it waiting for? This sounds like a defective disk sector. > > Try running "PRAGMA integrity_check" on (a copy of) the DB. > Try VACUUM. > > > Regards, > Clemens > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
