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 hardware. You might learn something more from section 6 of <https://sqlite.org/lockingv3.html> Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
