Curious if having the automated tests do db operations on a persistent db would catch this.
It would do inserts/deletes/updates/create_table/alter_column etc. randomly for a long time, continue even if an operation fails unless there is a crash. This way the db could grow without bound and queries can get very slow
I wonder why it took so much time among entire team to actually look into the source code. That's probably third thing I would do after encountering that kind of issue. I would even look for a word "gigabyte" considering it is well documented, because bizarre things should be documented.
The worst thing is, it's also documented in the SQLite's documentation. The file format is documented, and it describes the existence of this lock-page located at 1 GiB mark. How they've managed to implement support for SQLite DB file format without reading the file format description is, frankly, beyond me.
> To the point that we have a challenge [...]: if anyone can find a bug that leads to data corruption *and improve our simulator to catch it next time*, we will pay you a cash prize.
Uhh, you should be paying people if you get them to work for you.
I don't even understand the point in rewriting something that is rock solid. And on top of that you guys are asking for full compatibility. This is just nonsense.
6 comments
[ 4.3 ms ] story [ 23.5 ms ] threadIt would do inserts/deletes/updates/create_table/alter_column etc. randomly for a long time, continue even if an operation fails unless there is a crash. This way the db could grow without bound and queries can get very slow
Uhh, you should be paying people if you get them to work for you.