Live data from Hacker News

Tracking down the 16-year-old WAL-reset SQLite bug

tailscale.com

101–110 of 263 posts

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#101
post #87

Was curious so we checked and yep, Antithesis finds this bug in about 15 minutes. Will post a repro/writeup here soon.

Oh wow. I checked your site, but I (still) don't see the ability for average joes (and their pet AI agents) to signup. Could be huge, even if just offered in 5 minute slots. Is your email contact still valid in your profile? Want to reach out (Moose is the name). FYI, got a job at Antithesis a while ago after some rigorous interviewing.

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#102
post #87

Was curious so we checked and yep, Antithesis finds this bug in about 15 minutes. Will post a repro/writeup here soon.

Oh wow. I checked your site, but I (still) don't see the ability for average joes (and their pet AI agents) to signup. Could be huge, even if just offered in 5 minute slots. Is your email contact still valid in your profile? Want to reach out (Moose is the name). FYI, got a job at Antithesis a while ago after some rigorous interviewing.

We are working on getting self-serve signups to you ASAP. For now, just email us. We don’t bite.

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#103
post #3

Earlier quoted context omitted.

Yeah, tailscale seems to have leadership with their head on right, I agree with the way they handle a lot of things.

I wish they'd buy the carcass of Keybase from Zoom. It seems very similar to Tailscale: immense utility from a free-tier product for the general public, which leads to trust and a large enterprise market.

Or instead of buying Keybase, they could fund https://keyoxide.org/?

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#107
See perhaps recent video "Reliability Lessons From SQLite - Richard Hipp | SSW 2026":

> Abstract: SQLite is a C-language library that implements a self-contained, in-process relational database engine supporting full-featured SQL, an advanced query planner, and ACID transactions. By many estimates, SQLite is the most widely used software library in the world today.

> Over its 26-year history, SQLite has gained a reputation as software that "just works". This talk goes over the design choices and development practices that have, at least in the opinion of the lead developer, resulted in that reputation.

* https://www.youtube.com/watch?v=V_qzqY1bb7I

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#109
post #35

SQLite: 92 million lines of tests Dijkstra: Tests can only prove the presence of bugs, never their absence!

I admit to curiosity as to whether static analysis could have caught this. E.g., Rust's type system (yeah yeah I know) catches all data races, unless they originate in unsafe code, which this one might or might not have; a hypothetical Rust SQLite would probably need a lot of unsafe ( https://github.com/tursodatabase/turso has 556 unsafe blocks in the core), and I don't have a sense of whether the particular part tha…

It sounds like it was a bug caused by pushing on performance/safety ratio, it could easily have been avoided by adding enough mutexes in the code, but for performance reasons (I assume) they don't do that. To write it like that in Rust you'd have to use unsafe blocks and then you don't gain much from the typesystem in this case.

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#110

Maybe it's just me, but the explanations of the cause don't align. One clue was that during corruption incidents, our metrics showed that SQLite would report copying more pages from the WAL file than were actually available. If there are 10 pages in the WAL file and 20 pages get copied to the database, something is clearly wrong. vs it thinks some of the pages have been copied from the WAL into the main database file…

Same bug, two angles. Nothing really copies 20 pages, the "20" is just a broken counter. SQLite's internal tally of how many WAL pages it already saved to the main db gets corrupted and reads too high. Since it trusts that tally, it assumes those pages are already saved and skips writing them for real, so when the WAL resets they're gone. The "copied more than existed" number is the bug showing in your metrics; "pages never written" is the actual damage.
Post reply on HN