Date: 2020-01-20
Categories: filesystems; research

SQLite assumptions, or how to corrupt an SQLite database

An interesting post on Hacker News reminded me of this very informative page about how SQLite can go wrong:

My favourites:

Continuing to use a file descriptor after it has been closed (the user process interferes with the database process by writing to an fd it had previously closed, which was then in use by the db)
Filesystems with broken or missing lock implementations (unfortunately they are too coy about which filesystems these are... likely all of them)
Failure to sync (including "Disk drives that do not honor sync requests"... "Unfortunately, most consumer-grade mass storage devices lie about syncing.")
Non-powersafe flash memory controllers
The whole "Bugs in SQLite" section