PostgreSQL 14并行数据迁移触发postmaster意外退出崩溃如何解决

问题原因 #

1. Windows平台PG14并行查询与PostGIS兼容bug：你触发崩溃的SQL使用了PostGIS的KNN查询运算符<->、CROSS JOIN LATERAL语法，PG默认会对这类查询自动启用并行执行。PG14的Windows版本存在并行查询与空间扩展交互的底层bug，高并发触发时会出现系统句柄权限冲突，对应日志中的could not duplicate handle for "Global/PostgreSQL.xxxx": Permission denied错误，直接导致postmaster主进程异常退出。
2. 并发度过载：你启动了60个并行迁移进程，而PG默认会为每个大查询额外启动多个并行工作进程，实际运行的PG工作进程数会远高于60。Windows系统对进程句柄的管理限制远严于Linux，高并发下句柄资源耗尽会直接触发postmaster崩溃。
3. SQL逻辑冗余导致资源消耗过高：你写的最近节点查询逻辑存在不必要的CROSS JOIN LATERAL笛卡尔积计算，查询效率极低，高并发下会瞬间打满服务器CPU、内存资源，进一步放大进程崩溃概率。

解决思路 #

• 优先验证并行查询问题：修改postgresql.conf配置，将max_parallel_workers_per_gather设置为0临时禁用并行查询，重启PG后重新运行迁移任务。如果不再崩溃，可确认是并行查询兼容问题，后续可将该参数调整为1~2，或者仅在运行迁移任务时临时禁用。
• 优化冗余SQL逻辑：你的nearest_pgr_node函数里的查询逻辑可以直接简化，无需做两次CTE查询加笛卡尔积，优化后性能提升数倍，避免资源打爆：

-- 优化后的最近节点查询逻辑
SELECT id
FROM swn.pni_route_vertices_pgr
WHERE st_distance(the_geom, _point) < _dist
ORDER BY the_geom <-> _point
LIMIT 1;

• 降低并发连接数：Windows平台下PG的稳定并发连接数建议不超过32，你开启的60个并行进程明显超过阈值。可将Python并行数调整为20~30，或者引入数据库连接池限制实际的PG活跃连接数。
• 升级修复兼容bug：如果以上调整仍未解决问题，可将PG14升级到14.10及以上的最新稳定小版本，同时升级PostGIS到对应PG版本的最新稳定版，官方已修复多个Windows平台下并行查询与空间扩展的兼容bug。
• 单点验证：可单独循环调用数百次出错的swn.nearest_pgr_node函数，不开并行任务，确认是否会触发崩溃，如果仍崩溃可直接定位为PostGIS版本兼容问题，优先升级扩展即可。

内容的提问来源于stack exchange，提问作者Ulrik Balslev