打破 WAL

嗨，我又是卡尔。你可能还记得我是教克劳德使用对偶的人。今年早些时候，SQLite 发布了 (3.51.3)，它修复了预写日志记录 (WAL) 子系统中一个长期存在的错误，称为 WAL-Reset bug。该错误自 2010 年以来一直存在，但 SQLite 团队显然直到今年早些时候才意识到它的存在（更多信息见下文）。正如他们当时所写的：“该错误是一个具有严格时间限制的数据竞争。在普通使用中不太可能发生。开发人员从未能够有机地重现该错误，并且不得不向 SQLite 添加特殊的测试逻辑，故意触发该错误的情况，以验证问题是否已得到解决。”当我读到这篇文章时，我实际上正在和女朋友一起公路旅行，但我也是一个巨大的数据库迷，所以我立即被书呆子狙击了。毕竟，SQLite 中的错误极其罕见。此外，这听起来就像是一个完美的棕色 M&M：一个已知的、具有挑战性的错误，我们可以使用 Antithesis 来追踪它（我们在 POC 中已经做了很多这样的事情）。最重要的是，我最近为克劳德提供了我们的技能。于是，我坐在阳光海岸的一个山坡上，拿出手机，让克劳德去上班。我让它在 Antithesis 中设置 SQL 3.51.2（仍然有问题），然后用一堆 Antithesis 断言来检测代码。您可以在此处查看检测版本。在此向我无比美丽的家乡不列颠哥伦比亚省致敬。然后我要求它编写一个简单的工作负载来执行 WAL 插入和检查点代码。值得注意的是，这是一个完全通用的工作负载。它只是同时运行写入和检查点——您希望在生产中始终发生的事情。这些断言对于该错误来说也是通用的，它们都是您添加到任何数据库的标准断言，例如“没有丢失的已提交写入”和“数据库没有损坏”（在 sqlite 中称为完整性检查）。在我第一次运行时，Antithesis 在 15 分钟内发现了这个错误。这是报告。您正在寻找的部分是：然后我用 3.51.3 重复了这个练习，使用相同的工作量和对偶仪器。果然，跑步回来了。我今天想到这个问题是因为 Tailscale 刚刚写了一篇关于解决他们在 2025 年遇到的正常运行时间问题的优秀博客文章。这些问题就是 SQLite 团队发现 WAL-Reset bug 的原因。 Tailscale 遭受了 6 个月不稳定的正常运行时间，然后他们和 SQLite 团队花了数周的时间寻找 bug，推出并回滚了破坏其他内容的修复程序，然后不得不再等待两个月才能查看“真正的”修复程序 (3.51.3) 是否有效。为了从根本上解决这个问题，他们必须在 Tailscale 中编写一个新的事务日志管道，然后为 SQLite 中的虚拟文件系统层添加一个新的调试工具。在《Antithesis》中，这个过程并不完全需要单击一下，但单击一下即可为您提供因果关系分析，在不到一秒的时间内查明问题，并提供确定性的时间旅行调试，使您可以进行假设分析和破坏性分析。正如 Tailscale 团队所写，“没有人希望我们花六个月的时间寻找 SQLite 中的错误。这对我们的客户和员工来说都是一次非常令人沮丧的经历”。查找像 WAL-Reset bug 这样的 bug 极其困难（甚至可能就像在碎玻璃上爬行一样）——但对于罕见且困难的 bug，真正的折磨可能会在您等待修复是否真正有效时到来。我已经研究过足够多的数据库，并且自己也经历过很多很多次。因此，意识到这种虫子在野外有多么痛苦，既让人清醒又令人振奋。通过向特工提供使用对偶的技能，我坐在阳光下的云杉树下，通过手机在大约一个小时内找到并验证了它。我知道我们的特工技能很有用，但我不知道它们效果这么好。如果您遇到棘手的数据库问题，请给我打电话。