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