On 14 Jul 2010, at 1:30am, Jim Wilcoxson wrote: > This problem of not doing writes, or doing them in > the wrong order, is a different animal IMO.
If writes are not happening, or are happening in the wrong order, you're in trouble. It's almost impossible to figure out how to even detect that hardware problem without a time-consuming scan of each unit that should be written which, in SQLite, means reading every page. Since SQLite doesn't run a server process, it has no opportunity to use slack time to check integrity. Under the conditions described on the web page, this problem can happen only because of a power failure or an OS (not an application) crash. Under these conditions, the ext3 file system doesn't support ACID at all: any system that relies on ACID is not going to work. And if the file system doesn't support ACID, the software can't. I don't see any fast way of solving that kind of problem. It might be useful to figure out whether we're aiming for detection or correction. By 'correction' I don't mean recovery of all information, I mean restoring the database to some state it was in just after a COMMIT took effect. There's no point in implementing a detection system if the users consider "This database is corrupt" something worth complaining about. On the other hand, implementing a correction system may well slow down every write operation and perhaps '_open' too. It's not worth doing that if slowing down SQLite will decrease usability. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
