pgvector项目中HNSW索引构建时的并发锁问题分析

背景介绍

在pgvector项目的实际应用场景中，开发团队发现了一个与HNSW(可导航小世界图)索引构建相关的并发问题。当使用并行工作线程创建HNSW索引时，系统偶尔会出现崩溃情况，特别是在设置较大并行度(max_parallel_maintenance_workers=20)时更为明显。

问题现象

在构建HNSW索引过程中，系统在UpdateNeighborsInMemory函数中发生崩溃。核心问题表现为：

1. 在多线程环境下访问HNSW元素时出现空指针异常
2. 崩溃发生在索引构建的早期阶段
3. 通过反复中断和重启索引创建过程可以增加问题复现概率

技术分析

根本原因

问题的根本原因在于HNSW索引构建过程中的并发控制不足。具体表现为：

1. 竞态条件：当线程A正在更新元素E的邻居时，线程B可能同时将E作为其他元素的邻居进行修改
2. 内存可见性：由于缺乏适当的锁保护，邻居元素的指针可能被其他线程修改而当前线程无法感知
3. 临界区保护不足：UpdateNeighborsInMemory函数在遍历和修改邻居关系时没有对整个操作过程进行完整的锁保护

原实现缺陷

原UpdateNeighborsInMemory实现存在以下问题：

1. 仅对当前元素E获取共享锁(LW_SHARED)
2. 对每个邻居元素获取排他锁(LW_EXCLUSIVE)进行更新
3. 但在获取邻居元素指针和加锁之间存在时间窗口，可能导致数据不一致

解决方案

pgvector团队通过以下方式解决了该问题：

1. 增加锁范围：在UpdateNeighborsInMemory函数开始时即获取元素E的排他锁
2. 内存拷贝保护：在锁保护下创建邻居数组的副本，避免在操作过程中原始数据被修改
3. 保持锁一致性：确保在整个邻居更新过程中持有必要的锁

关键修改点包括：

• 使用LW_EXCLUSIVE模式而非LW_SHARED模式锁定当前元素
• 在锁保护下分配内存并复制邻居数组
• 维持原有的邻居元素更新锁机制

实现细节

优化后的实现采用了PostgreSQL的轻量级锁(LWLock)机制，确保：

1. 原子性：更新操作要么完全执行，要么完全不执行
2. 一致性：在更新过程中数据结构始终保持有效状态
3. 隔离性：并发更新操作不会相互干扰

内存管理方面，解决方案利用PostgreSQL的内存上下文机制，在每次处理元组时重置内存上下文，自动释放临时分配的内存，避免了内存泄漏问题。

验证结果

经过修复后：

1. 在高并发场景下(index并行度为20)不再出现崩溃
2. 通过30+次中断重启测试验证了稳定性
3. 系统性能未受明显影响

经验总结

该问题的解决为分布式向量数据库系统设计提供了重要经验：

1. 并发控制：在复杂数据结构操作中必须考虑完整的并发场景
2. 防御性编程：对关键数据访问应添加断言验证
3. 测试方法：对于并发问题，需要通过压力测试和反复操作来验证修复效果
4. 锁粒度选择：需要平衡并发性能和数据安全性

这类问题在实现类似HNSW这样的复杂图算法时尤为常见，开发者在设计并行算法时需要特别注意数据结构的线程安全保护。