来源：https://thebuild.com/blog/2026/05/22/pgvector-082-and-the-trouble-with-parallel-hnsw/
2026年5月22日
4分钟
PostgreSQL
**pgvector 0.8.2解决了并行HNSW索引构建中的CVE-2026-3172漏洞，该漏洞可能导致数据从其他关系中泄漏或数据库服务器崩溃。如果您运行pgvector并且其版本低于0.8.2，请升级。如果您使用托管服务，请检查其实际部署的pgvector版本------有几个非平凡数量的托管服务延迟了上游版本发布数周，"我们支持pgvector"并不意味着"我们使用的是修复了并行HNSW漏洞的版本"。
什么出问题了
HNSW是一个分层图结构。构建HNSW需要选择入口点、在候选集中找到最邻近的邻居、按层进行筛选并减少该集合，然后将图逐层向下传递。构建逻辑并不复杂，但内容密集，每个顶点都需要大量计算。pgvector在并行构建时将这些计算放在共享内存中，这意味着计算现在受到PostgreSQL中的领导者-工人协调约束的限制。
PostgreSQL的并行索引构建由一位领导者和N个工人执行，所有工人都连接到一个动态共享内存段，该段存储构建的共享状态。工人并行处理元组并将结果写入共享结构；领导者在最后阶段将结果拼接起来。这种方法适用于工作负载方法，其中每个工人的状态较小且合并步骤简单，即B树结构。对于HNSW，每个工人的状态是一个部分图，合并步骤是"将几个图合并在一起，同时遵循逐层邻居选择"，这是一个更有趣的问题。
根据公告描述，CVE-2026-3172是构建路径中的缓冲区溢出问题。公告中的描述------"数据从其他关系中泄漏或导致数据库服务器崩溃"------与从每个工人缓冲区溢出的数据进入其他后端映射到的共享内存是一致的，但具体的故障模式取决于合并或每个工人写入代码中的错误。实际影响和操作上重要的是影响范围和补丁。
为什么这比漏洞计数更值得关注
pgvector是生产级RAG架构中的默认向量扩展。所有托管PostgreSQL服务都支持它，其中一些预装了它，许多客户部署将CREATE INDEX ... USING hnsw作为常规操作。特别是并行HNSW构建，正是当您有几百万个向量且希望在午餐前完成构建时的选择。此漏洞存在于生产用户使用的路径中，而不是您唯一会遇到的路径中。
威胁模型也比常规扩展CVE更广泛。"数据从其他关系中泄漏"不是针对恶意用户，而是关于共享内存布局。用户A的并行构建中缓冲区溢出可能会破坏或读取用户B的数据库服务器映射的内存。没有SQL级别的权限边界来防止这种情况；共享内存模型假设写入是正确的，当它们不正确时，损坏会发生在任何地方。
应对方法
按顺序执行三个步骤。
-
将pgvector升级到0.8.2或更高版本。更改很小。升级操作是在二进制文件部署后进行ALTER EXTENSION pgvector UPDATE------修复本身不需要重新索引。
-
审计您的托管服务。如果您使用RDS、Aurora、AlloyDB、Cloud SQL、Azure Database for PostgreSQL、Tiger Cloud、Lakebase、Snowflake Postgres或其他任何部署了pgvector的托管服务，请检查实例实际加载的版本。SELECT extversion FROM pg_extension WHERE extname = 'pgvector'查询将告诉您实际版本，无论托管服务发布说明如何声明。
-
如果您无法及时升级且正准备重建HNSW索引，在构建期间将max_parallel_maintenance_workers设置为0。它会更慢，但不会出错。
总体情况
关系数据库中的向量索引是两种早已被理解的组件的新组合。HNSW构建是一种启发式图算法，其参考实现是为机器学习工作负载编写的，而不是为事务服务器内的共享内存并行性设计的。将其嵌入到其他框架中需要正确设计协调层，而此漏洞就存在于协调层。
预计更多此类问题会出现。pgvector是生态系统中维护最严格的向量扩展，但仍存在并行构建缓冲区溢出问题。那些维护不严格的扩展存在更多问题。
Prompt: 395.9 t/s \| Generation: 25.3 t/s