sqlite problems on Mac OS X 10.4

Jim Correia jim.correia at pobox.com
Sat Sep 10 15:04:14 CEST 2005


Well from looking at the code I see this:

     /* using IMMEDIATE or DEFERRED here locks up in t.lock3
      * or t.bulkmode */
     if (sqlexec(dbh->db, "BEGIN EXCLUSIVE TRANSACTION;")) goto barf;

Building against SQLite 3.1.3 on Mac OS X, that comment isn't  
accurate. (Is it for other platforms?)

If I remove the lock modifier, or change it to DEFERRED (which I  
understand is the default) the all tests pass on my machine. Here is  
the summary.

PASS: "BEGIN TRANSACTION;"

PASS: "BEGIN DEFERRED TRANSACTION;"

FAIL: "BEGIN IMMEDIATE TRANSACTION;"

     bogofilter[13532]: Error on database ./checks. 
13493.20050910T085306/wordlist.db: database is locked_
     bogofilter[13531]: Error executing "BEGIN IMMEDIATE  
TRANSACTION;": database is locked (#5)_

FAIL: "BEGIN EXCLUSIVE TRANSACTION;"

     in the previously described fashion


http://www.sqlite.org/lang_transaction.html
http://www.sqlite.org/lockingv3.html

This seems explainable by the description of the EXCLUSIVE lock if we  
have other read locks on the database.

EXCLUSIVE    An EXCLUSIVE lock is needed in order to write to the  
database
             file. Only one EXCLUSIVE lock is allowed on the file and no
             other locks of any kind are allowed to coexist with an  
EXCLUSIVE
             lock. In order to maximize concurrency, SQLite works to  
minimize
             the amount of time that EXCLUSIVE locks are held.

Am I barking in the wrong tree here? It seems to solve the problem  
(here at least.)

While reading the first page I also noticed:

     An attempt to execute COMMIT might result in an SQLITE_BUSY  
return code.
     This indicates that another thread or process had a read lock on  
the
     database that prevented the database from being updated. When  
COMMIT
     fails in this way, the transaction remains active and the COMMIT  
can be
     retried later after the reader has had a chance to clear.

A quick search of the source shows that this result is handled in  
sql_fastpath and nowhere else (not as a response to commit as far as  
I could tell in a first-pass search.) Is this something to be  
concerned about? (I'm not an expert on the bogofilter source, or  
sqlite, so I don't want to claim the sky is falling if it is not.)

Thanks,
Jim




More information about the bogofilter-dev mailing list