Neon数据库在GiST索引清理时出现数据读取错误的分析

在Neon数据库项目中，开发团队发现了一个与GiST索引清理相关的数据读取错误问题。这个问题最初是在PostgreSQL回归测试中发现的，表现为在执行VACUUM操作时无法找到特定键的数据。

问题现象

当执行包含以下操作的SQL脚本时会出现错误：

1. 创建一个包含数组和点类型的测试表
2. 插入1000条测试数据
3. 在点类型列上创建GiST索引
4. 执行VACUUM操作

错误信息显示，页面服务无法从LSN(日志序列号)0/00000001处读取关系1663/16384/16420.0的块1，并返回了"Read error"错误。

技术分析

通过深入分析日志和代码，团队发现问题的核心在于LSN处理逻辑上。具体表现为：

1. 页面服务尝试获取关系大小时，在LSN 0/1F7B678处无法找到关系大小键(000000067F000040000000400600FFFFFFFF)
2. 实际上，这个关系大小键是在稍后的LSN 0/1F7B6A8和0/1F86B70处写入的
3. 读取路径正确地报告了键缺失，因为查询的LSN早于键实际写入的LSN

问题的根源在于计算节点和页面服务之间的LSN协调机制。计算节点在确定有效请求LSN时，由于not_modified_since_lsn参数被设置为0/1，导致使用了最后摄入的LSN(0/1F7B678)作为查询点，而实际上应该使用0/1F86B70。

解决方案

PostgreSQL内核团队针对这个问题提交了三个修复补丁，分别针对不同版本的PostgreSQL(v14-v16)。这些补丁修正了计算节点在处理GiST索引清理时的LSN传递逻辑，确保not_modified_since_lsn参数被正确设置。

值得注意的是，这个问题在PostgreSQL 17及更高版本中不会出现，说明相关逻辑在后续版本中已经得到了改进。

技术背景

对于不熟悉数据库内部机制的读者，这里简要解释几个关键概念：

1. LSN(日志序列号)：PostgreSQL中用于标识WAL(预写日志)记录位置的唯一标识符，是数据库恢复和复制的基础。
2. GiST索引：通用搜索树索引，PostgreSQL中支持扩展索引类型的基础设施，可用于实现各种复杂数据类型的索引。
3. VACUUM操作：PostgreSQL的维护操作，用于回收死元组占用的空间并更新统计信息。

总结

这个问题的发现和解决展示了Neon数据库团队对系统稳定性的高度重视。通过细致的日志分析和版本比对，团队快速定位了问题根源并提供了针对性的解决方案。这类问题的解决不仅提高了系统的可靠性，也为后续的架构改进提供了宝贵经验。