On 24 Mar 2014, at 5:23am, Roger Binns <rog...@rogerbinns.com> wrote:
> On 21/03/14 15:24, Simon Slavin wrote: >> Checksums stored with the page index lists, > > SQLite already has the ability to carve out data on each page for other > uses. For example the encryption extension uses this. This would be better than nothing, but there is a problem with writing the checksum in the same operation that writes the page. The two standard unlikely scenarios for data corruption (cosmic rays and static discharge) flip bits inside wires lines or inside RAM bits, and it's possible that the bit that gets flipped will be for the address of the sector being written/read rather than in the data being written/read. So by storing the checksum in the page it checks you will get a sector that passes the checksum test, but has been written to the wrong place in storage and therefore corrupts the file. So the checksum should be stored away from the page it checks. My understanding of the SQLite file format suggests that the checksum could usefully be stored with the pointer to the page in the page store (TABLE / INDEX page list or whatever it's called) since it would be needed at the same time and the two could be retrieved in one operation. > It couldn't be on by default for backwards compatibility reasons. (WAL is > another example of that.) Agreed. Backward compatibility would be a problem for SQLite3 so it's not going to happen either way unless the file format is revised and more PRAGMAs added. Maybe in SQLite4. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
