SQLite recently patched a rare, 16-year-old bug in its Write-Ahead Log (WAL) checkpointing system that could lead to database corruption. This post from Canonical's dqlite (distributed SQLite) team walks through how they used TLA+ to formally model SQLite's internal behavior, isolate the exact sequence of steps needed to trigger the corruption, and determine whether their own system was vulnerable.
So there's \in, \subseteq and probably many others that are written just like in Latex. Notably \cap and \cup were also copied from Latex, which describe the shape of the symbol instead of its meaning. But not \to, \mapsto, \Vee and \Wedge, they're written as ASCII art ->, |->, \/ and /\.
Then there's SUBSET, which means power set ... yeah. -_-
If the LaTeX-like syntax worries you, several projects aimed at providing PL-like syntaxes for TLA+. They vary by their degree of how much of the logic they throw away. I am not going to advertise these projects here, but you would find them on GitHub search by typing the tags like "#tlaplus #language", "#tlaplus #library", and "#tlaplus #pluscal".
For local only high level modelling. Its not a full tie into the actual model checker, but its meant to serve as a first step into system modelling for state machine modelling for beginners
Thanks for the nice article. The SQLite docs that explain this bug are emphatic about how utterly rare, even irreproducible it is. How, then, was it found, one wonders?
My guess is that they noticed something was not quite right when inspecting the code and then tested their hypothesis manually to see if it was actually a real bug.
Something similar happened to me when I was working on some code that should clear the state and, by inspection, I noticed some field was not properly cleared under specific circumstances. Then I tested the hypothesis and indeed found a bug. Sometimes intuition and guessing is what it takes.
It's in Chrome, Firefox, Safari, Windows 10, macOS because it efficiently solves a huge number of use cases while giving plenty of headroom for flexible querying.
If you have data more complicated than a single CSV or tab-separated text file that you will only ever process in sequential order, and you don't need inter-process interaction, you should be asking why not use SQLite.
sqlite is useful everywhere CSV files are useful but you'd like them to have more data integrity and faster updates. sqlite can replace some uses of MySQL, but more commonly it replaces fopen. https://sqlite.org/whentouse.html
You’re in a desert walking along in the sand when all of the sudden you look down, and you see a tortoise, it’s crawling toward you. You reach down, you flip the tortoise over on its back. The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over, but it can’t, not without your help. But you’re not helping. Why is that?
I don't like the title. The article actually describes the process of proving that dqlite does not have the same bug as SQLite, using a TLA+ specification. The SQLite bug fix was entirely separate from what is described here.
This is so cool and I wonder how effective it would be using this technique when using LLMs to generate code. Have the llm generate code and a TLA+ model. Use the TLA+ model as the test bed of the code (instead of writing tests in the original language).
35 comments
[ 5.8 ms ] story [ 48.7 ms ] threadhttps://lamport.azurewebsites.net/tla/tla.html
Then there's SUBSET, which means power set ... yeah. -_-
[0] https://en.wikipedia.org/wiki/LaTeX [1] https://en.wikipedia.org/wiki/Donald_Knuth [2] https://en.wikipedia.org/wiki/TeX
I wonder if anyone has worked on porting it to Lean and making tactics for it
I made https://github.com/RCSnyder/tlaplus-process-studio
https://tlaplus-process-studio.com/
For local only high level modelling. Its not a full tie into the actual model checker, but its meant to serve as a first step into system modelling for state machine modelling for beginners
Also congratulations to the author, I'll try and reproduce this over the weekend.
Something similar happened to me when I was working on some code that should clear the state and, by inspection, I noticed some field was not properly cleared under specific circumstances. Then I tested the hypothesis and indeed found a bug. Sometimes intuition and guessing is what it takes.
We should probably blog about it.
If you have data more complicated than a single CSV or tab-separated text file that you will only ever process in sequential order, and you don't need inter-process interaction, you should be asking why not use SQLite.
Is this an allusion?
[1] https://bladerunner.fandom.com/wiki/Voight-Kampff_test