Re: sqlite problems on Mac OS X 10.4

Jim Correia <[email protected]> writes:

> Any idea about the hangs in t.lock3? (Should I just stick with bdb  
> for now?)

Apparently it isn't hanging, but looping. t.lock3 can take minutes to
finish, particularly on slower drives (Powerbook perhaps?)

> When the tests hang it looks like all the processes have similar  
> backtraces:
>
> #0  0x9001efe8 in select ()
> #1  0x00016284 in bf_sleep (delay=909804) at system.c:57
> #2  0x0000e07c in rand_sleep (min=1000, max=1000000) at rand_sleep.c:20
> #3  0x00015848 in busyhandler (dummy=0x4, count=0) at  
> datastore_sqlite.c:245

The above is bogofilter code (callback stuff).

> #4  0x9436b188 in sqlite3pager_pagecount ()
> #5  0x9436be08 in sqlite3pager_begin ()
> #6  0x94352f50 in sqlite3BtreeBeginTrans ()
> #7  0x9437caf4 in sqlite3VdbeExec ()
> #8  0x9437f26c in sqlite3_step ()
> #9  0x94385a0c in sqlite3_exec ()

#4 - #9 are sqlite3 code.

#10 - #15 are bogofilter code again.

> I do see this in the SQLite bug tracker. I don't know if it is relevant.
>
> http://www.sqlite.org/cvstrac/tktview?tn=263,2

I don't think it is, if it were deadlocked, it wouldn't be calling back
rand_sleep. t.lock3 is however, as connotated above, sensitive to I/O
speed, I/O load, also to context switch overhead, other system load, and
can take several minutes to finish. I'm not sure how to best address this.

-- 
Matthias Andree
_______________________________________________
Bogofilter-dev mailing list
[email protected]
http://www.bogofilter.org/mailman/listinfo/bogofilter-dev