冯若航：我为何维护 VectorChord 分支
内容提要
因VectorChord上游维护停滞，作者在TensorChord邀请下于pgsty组织接管其分支，并获Immich社区支持。团队审计三个扩展，修复索引崩溃、权限缺失、VACUUM可见性等二三十个问题，发布vchord 1.2.0、vchord_bm25 1.0.0和pg_tokenizer 1.0.0，支持PostgreSQL 14至18，兼容旧索引无需重建。作者强调开源自由与供应链维护成本，认为社区使用有助于提升可靠性。
延伸解读
维护停滞为何在当下成为紧迫风险
文章指出，过去数据库扩展停更六到十个月或许无碍，但如今PostgreSQL新大版本、pgrx框架更新以及自动化漏洞发现都在加速。作者强调，LLM让大规模代码审计和漏洞挖掘成本骤降，无人维护的代码会迅速积累未修复缺陷，不再是“稳定”而是“敞开的门”。这解释了为何上游停摆仅半年多，接管就变得必要。
审计暴露的问题比版本号更值得关注
团队在三个扩展中修复了约二三十个问题，其中几类直接影响生产安全：索引构建时无界递归可导致后端崩溃并触发恢复；权限检查缺失让普通角色能读取他人采样向量或执行预热；VACUUM后可见性缺陷可能让最近邻查询返回无关行。这些不是边缘瑕疵，而是索引崩溃、越权访问和结果错误，说明长期未维护的扩展风险会落在查询正确性与权限边界上。
升级兼容性降低了接管门槛
vchord 1.2.0与上游0.2.0至1.1.1的索引二进制和磁盘格式兼容，通常无需REINDEX，仅受halfvec fp16溢出影响的索引例外。升级路径是安装新包、重启PostgreSQL加载新vchord.so，再执行ALTER EXTENSION和版本查询。对已部署用户而言，这意味着接管分支不必重建索引即可延续使用，迁移成本主要集中在验证和重启窗口。
分支能否存活取决于分发与验证闭环
作者以Silo为例总结分支成功的四个条件：自身是重度生产用户、具备领域判断、有现成分发渠道、能讲清背景并获得信任。对应到vchord，Pigsty扩展仓库直接触达用户，博客提供解释渠道，社区报告和测试则补上异构环境验证。文章的核心判断是：代码免费，但可靠交付的供应链需要持续工程投入，社区使用本身就是在帮助发现边缘缺陷。
Q&A
为什么冯若航要接管 VectorChord 分支？
因为 VectorChord 上游维护停滞：pg_tokenizer 自 2025 年 9 月后无新版本，VectorChord 最后上游版本 1.1.1 于 2026 年 2 月发布，提交活动在 2026 年 4 月下旬后停止，超过六个月无实质维护。同时 TensorChord 主动邀请，下游 Immich 社区也愿意贡献 bug 报告、测试和补丁，因此他决定接手。
VectorChord 分支在 pgsty 下发布了哪些版本？
发布了三个扩展的首个版本：vchord 1.2.0（2026 年 11 月 4 日）、vchord_bm25 1.0.0（2026 年 11 月 3 日）和 pg_tokenizer 1.0.0（2026 年 11 月 3 日）。
从上游 VectorChord 升级到 1.2.0 需要重建索引吗？
不需要。vchord 1.2.0 与上游 0.2.0 至 1.1.1 的现有索引在二进制和磁盘格式上兼容，无需 REINDEX，除非索引使用了受 fp16 溢出影响的 halfvec 值。升级步骤：安装 1.2.0 包，重启 PostgreSQL 使新的 vchord.so 通过 shared_preload_libraries 加载，然后执行 ALTER EXTENSION vchord UPDATE TO '1.2.0'; 和 SELECT vchord_version();。
审计中修复了哪些严重问题？
修复了约 20-30 个问题，包括：索引构建崩溃和 OOM（递归溢出导致 SIGSEGV、采样缓冲区预分配过大触发 OOM killer）；缺失权限检查（未授权角色可读取采样查询向量或执行 prewarm）；VACUUM 后可见性 bug 和 PostgreSQL 17/18 read_stream 结果截断；距离、运算符和量化边缘情况（如 MaxSim 默认 -Infinity、球面运算符比较错误、halfvec SIMD 溢出、rabitq L2 距离返回 NaN）；以及升级和打包阻塞问题（宏 bug 破坏 pg_upgrade、SQL 文件被原地修改）。
维护开源分支为什么需要供应链成本？
开源代码虽然免费，但维护可靠的企业级制品供应链需要真实成本。以 MinIO 为例，上游归档仓库并删除官方 Docker 镜像导致全球 CI/CD 中断。对于 vchord，投入生产后依赖活跃维护的供应链。作者维护的 PGEXT.CLOUD 仓库每月服务数亿请求和近 2 TB 流量，带宽虽便宜（主要靠 Cloudflare 吸收），但真正的成本是持续的工程时间、构建维护和人力投入。
维护一个成功的分支需要具备哪些条件？
根据维护 Silo 的经验，需要同时具备四个条件：1. 切身利益（自己是重度生产用户，出问题首当其冲）；2. 领域判断力（能界定问题、权衡取舍、做设计决策并验收）；3. 内置分发渠道（如 Pigsty 分发系统，修复能直接到达用户）；4. 影响力和叙事（清晰解释背景、技术理由，吸引用户尝试）。缺少这些基础，分支很容易停滞。
