On 12/31/2013 09:25 PM, Török Edwin wrote:
Hi,
I am using SQLite 3.8.1 compiled from the amalgamation on Debian GNU/Linux
"wheezy", amd64.
I have set a logging callback with sqlite3_config(SQLITE_CONFIG_LOG, qlog,
NULL), and I see the following error sometimes:
Query "INSERT INTO topush (block, size, node, expires_at) VALUES (:b, :s, :n,
:e)" failed: (code 0xf: locking protocol) locking protocol
[...]
SQLite error e: cannot open file at line 28873 of [c78be6d786]
SQLite error e: os_unix.c:28873: (17) open(/var/tmp/etilqs_RxmAVCiy0tddswN) -
File exists
SQLite error e: statement aborts at 25: [UPDATE hashfs SET value = value + 1
WHERE key = 'next_blockno']
Query "UPDATE hashfs SET value = value + 1 WHERE key = 'next_blockno'" failed:
(code 0xe: unable to open database file) unable to open database file
The first error seems to be a known issue:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg57092.html
The second error can be triggered in a sequence of events that can be roughly
described as:
* create an sqlite DB in WAL mode, with synchronous=NORMAL
* open an sqlite DB as soon the application starts, prepare some statements,
run some selects on the DB, then close it
* fork worker processes
* open the same DB in each sub-process
* run queries on the DB in parallel
A closer look at sqlite3.c reveals that the temporary filename generator uses
sqlite3_randomness which is seeded once, globally, by the main process in this
case.
The forked children will share the PRNG's state, possibly generating the same
sequence in each child.
This one (the "second error") is now fixed on the trunk:
http://www.sqlite.org/src/info/e1eba1fb09
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
