Given what you wrote, and assuming you are not accidentally writing to memory 
or file handles maintained by SQLite, your corruption is probably caused by

A) Faulty implementation of memory mapping

B) Multiple thread/processes writing to the database at one time, through some 
fault in mutexing.

Of the two, (A) is almost trivial to check.  Turn it off, and see whether the 
fault continues to occur.  I’m aware this will make your program use more 
time/resources, but it’s just for temporary testing.

Testing (B) is more difficult and requires understanding of your own specific 
program design.  You should only have to worry about parts of your code which 
write to the database.  Pay special attention to whether you’re sharing SQLite 
connections or not.  This is so difficult to debug you might try the other 
things mentioned here before you investigate this problem.

> Disk is formatted as ext3 (linux 2.6.31 kernel; relevant mount options: 
> relatime,errors=continue,barrier=1,data=ordered).  Writes are not actually 
> getting coalesced by the kernel disk scheduling (there are reasons for this, 
> but none of which are relevant for this).

I’m not aware of problems on ext3 with barrier=1.  However, you might consider 
trying errors=panic for a while.  This is something I recommend for all servers 
since it allows you to identify faults far more quickly than trying to 
reverse-engineer corruption reports.

In closing, please note that a good proportion of the data-corruption problems 
reported here turn out to be caused by hardware problems.  Some are in 
motherboard data channels, others in a storage subsystem.  Consider that all 
your code may be faultless, SQLite may be faultless, and that the problem is in 

You might learn something more from section 6 of


sqlite-users mailing list

Reply via email to