[ Not subscribed; please CC me. ] The attached Testcase.hs is a haskell program using sqlite, that demonstrates what I think may be a bug in WAL mode. Based on the documentation, readers in WAL mode are supposed to not be blocked by concurrent writers. However, this test case demonstrates that a SELECT can fail with busy in a WAL mode database that is getting a large volume of writes.
To build: apt-get install haskell-platform cabal update cabal install persistent-sqlite persistent-template esqueleto IfElse ghc --make Testcase I've been building it on Debian unstable. Note that by default, persisten-sqlite includes its own embedded copy of sqlite, which is rather out of date. It can be modified to build with the system library. I have reproduced the crash when the test case is linked to version 3.8.7.4; I have not yet tried a newer version. To run: rm test.db* (if ran before) Run one Testcase process, and wait for it to print the Migrating line. Then immediately run a second Testcase process. One of the two processes will quickly crash: ..Testcase: user error (SQLite3 returned ErrorBusy while attempting to perfor While running, it outputs '.' every time it successfully changes the database. It's expected that some write attempts fail, as there are multiple concurrent writers; if a write fails, it prints '!' and ignores the failure. The crash comes when a *read* fails. WAL documentation indicates that writers should not block reads, but this test case seems to demonstrate otherwise! Also attached is a TestcaseReader.hs. This only does reads, no writes. TestcaseReader can be run while Testcase is running, and will also demonstrate the problem: user error (SQLite3 returned ErrorBusy while attempting to perform prepare "SELECT \"fscked\".\"key\"\nFROM \"fscked\"\nWHERE \"fscked\".\"key\" = ?\n": database is locked) finally succeeded after 1 retries all 1..100000 followup selects succeeded The interest thing about this is that it shows that the failing SELECT is always the first one made on a new database connection. I've seen it need to retry 60+ times to get that first SELECT to succeed, but once a SELECT does succeed, it seems it's past the danger zone and the database can be used without problems. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: Digital signature URL: <http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/attachments/20150219/8a937849/attachment.pgp>
