拓冰建站拓冰建站
首页 / 资讯中心 / 正文

折腾两天终于跑通:pgvector向量搜索扩展在Windows 11下的编译排坑实录

折腾两天终于跑通pgvector向量搜索扩展在Windows 11下的编译排坑实录【免费下载链接】pgvectorOpen-source vector similarity search for Postgres项目地址: https://gitcode.com/GitHub_Trending/pg/pgvectorpgvector是PostgreSQL的向量相似度搜索扩展让Postgres能对向量列做最近邻查询。我在Windows 11 PostgreSQL 16上编译它被报错卡了两天最后发现是选错了编译器位数。卡在哪里最先吓到我的报错我照着常规流程走拉源码、开命令行、执行nmake。构建先是刷出一大片warning C4141: dllexport: used more than once符号被重复声明导出。我一开始以为这是主犯后来发现它只是警告。真正的拦路虎是这个tupmacs.h(65): error C2196: case value 4 already used tupmacs.h(197): error C2196: case value 4 already used报错位置在PostgreSQL内部头文件tupmacs.h里不在pgvector自己的源码文件里。switch分支里同一个case值被用了两次编译器直接报错中断DLL根本出不来。排查路径我先往错的方向走了我先怀疑是符号冲突去数据库里查了已装扩展列表确认没有别的扩展重复定义同名符号又执行了clean重新构建结果一模一样。接着怀疑PostgreSQL版本不兼容。我逐行看了Makefile.win确认PGROOT指向的就是实际安装的PG16目录头文件和库文件路径都对得上排除环境配置问题。转折点是我又看了一眼报错文件tupmacs.h是PG头文件里面的分支是靠SIZEOF_DATUM宏Datum的大小Datum可理解为Postgres通用的数据载体做条件编译的。64位下它是8分支不冲突用32位编译器编译时它是4switch里的分支就撞上了。绕了一圈回头看我的命令行窗口——我一直用的是x86的Developer Command Prompt。项目Windows安装说明里写明了要用x64 Native Tools Command Prompt我当时没留意这一句。关键修复切到x64编译环境的四步T 换环境不复杂难在一把过打开 x64 Native Tools Command Prompt for VS别用普通Developer Command Prompt——原因编译目标架构必须和64位Postgres对齐。拉源码并进入目录git clone https://gitcode.com/GitHub_Trending/pg/pgvector这就是扩展的完整源码。声明PGROOT并执行构建set PGROOTC:\Program Files\PostgreSQL\16 nmake /F Makefile.win clean nmake /F Makefile.win nmake /F Makefile.win installclean那一步不能省——把32位编译留下的obj清干净否则新旧产物混着链接还是会挂。✅ 装完后执行CREATE EXTENSION vector;能建向量列和索引就算彻底通了。踩坑备忘这些细节容易再犯⚠️ 别凭窗口标题判断编译器位数。不确定就执行where cl路径里带x86_amd64说明是32位。换完环境先clean再构建32位的obj混进来一定失败。C4141重复导出警告不影响DLL生成成功别在它上面耗时间。PG 17.0到17.2会在链接阶段报float_to_shortest_decimal_bufn那是PG自身问题升到17.3以上。install阶段报 Access is denied 就是权限不够用管理员身份重跑。一句话总结Windows上编译扩展先查编译器位数再怀疑代码。建议把x64命令行固定成你的默认环境。【免费下载链接】pgvectorOpen-source vector similarity search for Postgres项目地址: https://gitcode.com/GitHub_Trending/pg/pgvector创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门