3 ms·
Very interesting read! Although some points might sound too strange to include in this list (like "memory corruption" - in case of faulty memory, everything is
by Lex-2008 7y ago
Very interesting read! Although some points might sound too strange to include in this list (like "memory corruption" - in case of faulty memory, everything is in danger, not only database) - some worth keeping in mind (multiple hardlinks to the file, moving a single DB file around without accompanying *-wal file, etc)
- matsemann 7y ago> strange to include in this list (like "memory corruption" - in case of faulty memory, everything is in danger, not only database) But theoretically one could build something that handles up to X random bit flips, so it's maybe worth mentioning that sqlite doesn't handle this (even though probably no one else does as well)
- Franciscouzo 7y agoCould you? You would also have to take into account that the instruction that make the program could also be randomly flipped
- blattimwind 7y agoIn most cases the size of the code is much smaller than the data handled, so for random errors (perfectly working DRAM has a bit error rate somewhere in the general vicinity of 10^-14/bit*hr) the distribution of errors is in accordance to that proportion.
- mytailorisrich 7y agoThey are not describing cases of faulty memory but explicitly, and very aptly, warn you that since SQLite is a C library that runs in the same address space as the application code, if your application code corrupts memory (by way of buffer overrun, heap corruption, etc) it can impact SQLite's internals and in turn corrupts the SQLite database file.