16年前のSQLiteバグを追い詰めたTailscaleの執念
Tailscaleが原因不明のDB破損を追跡し、SQLiteのWALリセット処理に16年間潜んでいたデータ競合バグを突き止めた調査録。
#なぜ今日これを選んだか
HNで808点・147コメントと大きく議論された記事。「自分のコードをまず疑い、それでも直らないなら基盤ライブラリまで掘る」というデバッグの王道を、世界で最も使われるDBであるSQLite相手に実践した事例で、Rustと低レイヤーを学ぶ#130の姿勢にそのまま重なるから。
#要点
- Tailscaleは頻発する原因不明のデータベース破損に悩まされ、調査を開始した
- SQLiteの開発者とも連携して追跡した結果、WAL（Write-Ahead Log）のリセット処理に潜むデータ競合が原因と判明した
- このバグは約16年間、世界中で使われるSQLiteの中に誰にも気づかれず存在していた
#自分にとっての示唆
「枯れた定番ライブラリだから安全」という思い込みは、16年物のバグの前では通用しない。それでも彼らが原因に辿り着けたのは、WALという仕組みの動作原理を理解し、再現条件を粘り強く絞り込んだからだ。今Rustで学んでいる所有権や並行性の知識は、まさにこういうデータ競合を見抜くための土台になる。The Bookを読む30分を「いつか低レイヤーの不具合を自力で追える力」への積立だと思って、今日も1章進めたい。