On 12/31/2013 09:25 PM, Török Edwin wrote:

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: 

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 
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:



sqlite-users mailing list

Reply via email to