Яндекс.Метрика
← Дайджест от 12 августа 2026

Библиотека SQLite шестнадцать лет теряла данные при сбросе журнала

Tailscale разбирала повреждения своей базы данных и нашла причину в SQLite — самой распространённой встраиваемой базе данных, которая стоит внутри браузеров, телефонов и множества серверных сервисов. Ошибка живёт в коде шестнадцать лет и срабатывает при сбросе журнала предзаписи WAL: изменения, которые считались сохранёнными, теряются или база остаётся в несогласованном состоянии.

Нашли её не чтением кода: компания Antithesis прогоняла SQLite в детерминированной среде, где сбои воспроизводятся точно, и поймала расхождение. Инструмент, лежащий под всей отраслью, включая ИИ-сервисы с локальным хранением, оказался неоттестированным именно в редком пути сброса журнала — том, который в обычной работе почти не встречается.

Что говорят
ec109685Hacker News
Формально всё так, но формулировка занижает серьёзность: «баг — это гонка с жёсткими таймингами, в обычном использовании маловероятна». При этом крупный клиент реально получил повреждение данных, так что всем с конфигурацией как у Tailscale стоит обновиться немедленно. Разработчики так и не смогли воспроизвести баг естественным образом — пришлось добавлять в SQLite специальную тестовую логику, которая нарочно создаёт нужные условия.
calmingsolitudeHacker News
Из фразы «единственный Go-процесс монопольно обращается к этой базе — именно так SQLite и задуман» я решил, что писатель и чекпоинтер живут на одном соединении, и не понимал, откуда гонка. Но по описанию бага на сайте SQLite он возможен только при нескольких открытых соединениях, то есть писатель и чекпоинтер были в разных потоках.
simonwHacker News
Интересный пример корпоративного финансирования open source: они оплатили разработку нового и очень специфичного инструмента отладки — shim для VFS SQLite, который помог почти сразу локализовать гонку и пригодится для похожих багов в будущем.