PostGIS 3.7.0rc2 发布：升级前先看依赖矩阵与验证方法

2026-09-08 26 预计阅读时间: 1 分钟
来源: postgr.es AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：9 分钟

PostGIS 3.7.0rc2 已经发布。它是 PostGIS 3.7 大版本的第二个候选版本，包含自 3.7.0rc1 以来的修复，同时汇集了相对 PostGIS 3.6.4 的缺陷修复和新功能。对准备升级空间数据库的团队来说，这个版本更适合用于兼容性验证、扩展测试和性能基线采集，而不是不经评估直接替换生产环境。

RC2 的定位：离正式版更近，但仍不是 GA

“Release Candidate”意味着功能和接口通常已经趋于稳定，维护重点转向发现阻断正式发布的问题。不过，RC2 仍然不是最终稳定版。数据库扩展与普通应用依赖不同：它会涉及 PostgreSQL 扩展目录、系统表、空间索引、二进制库以及已有空间数据，因此回滚成本往往更高。

这次发布值得关注的两个层面是：

  • 修复了 3.7.0rc1 之后发现的问题；
  • 作为 3.7 大版本候选版本，包含相对 3.6.4 的修复与新功能。

来源摘要没有逐项列出 RC2 的修复内容，因此不能仅凭版本号推断某个具体缺陷已经解决。若团队正在等待某项修复，应结合发行说明和自己的回归用例进行确认。

官方给出的推荐组合包括 PostgreSQL 19 Beta 3、GEOS 3.15.0、postgis_tiger_geocoder 2025.2 和 address_standardizer。这里的 PostgreSQL 19 仍处于 Beta 阶段，适合联合测试最新能力，但不等于所有生产系统都应该立即跟进。

依赖不是一条线，而是一张能力矩阵

PostGIS 的可用功能取决于多个底层库。3.7.0rc2 的关键要求如下：

组件 最低或推荐版本 影响范围
PostgreSQL 14 至 19 Beta 3 PostGIS 3.7.0rc2 的数据库运行基础
GEOS 最低 3.10 几何计算的基础依赖
GEOS 3.15 或更高 使用 PostGIS 3.7 的完整特性
PROJ 6.1 或更高 坐标参考系与投影转换
libgmp 必需 构建或运行依赖之一
SFCGAL 2.3.0 或更高 使用全部 SFCGAL 功能
GDAL 3 或更高 使用 postgis_raster 扩展

这里最容易踩坑的是“能够安装”与“能够使用全部能力”之间的差异。例如，GEOS 3.10 满足最低要求，但若要覆盖 3.7 的所有功能，应准备 GEOS 3.15 或更高版本。同样，核心 postgis 扩展可用，并不表示 postgis_raster 或 SFCGAL 相关能力已经可用。

对于容器镜像或操作系统软件包，还应确认 PostGIS 实际链接的动态库版本，而不是只检查主机上某个 geos-config 或 proj 命令的输出。一个系统中可能同时存在多套库，最终应以数据库内报告的信息为准。

在隔离数据库中做一次可复制的冒烟测试

下面的脚本适用于已经安装 PostGIS 3.7.0rc2 软件包或已完成源码部署的 PostgreSQL 实例。运行前修改 PGHOST、PGPORT 和 PGUSER；执行用户需要拥有创建数据库与扩展的权限。

脚本会创建一个临时数据库，启用核心扩展，检查实际版本，并验证几何运算、空间索引和坐标转换。确认结果后，它会删除测试数据库。

#!/usr/bin/env bash
set -euo pipefail

export PGHOST="127.0.0.1"
export PGPORT="5432"
export PGUSER="postgres"

DB_NAME="postgis_rc2_smoke"

dropdb --if-exists "$DB_NAME"
createdb "$DB_NAME"

psql -v ON_ERROR_STOP=1 -d "$DB_NAME" <<'SQL'
CREATE EXTENSION postgis;

SELECT current_setting('server_version') AS postgresql_version;
SELECT postgis_full_version();

CREATE TABLE places (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL,
    geom geometry(Point, 4326) NOT NULL
);

CREATE INDEX places_geom_gix ON places USING gist (geom);

INSERT INTO places (name, geom) VALUES
    ('Beijing', ST_SetSRID(ST_MakePoint(116.4074, 39.9042), 4326)),
    ('Shanghai', ST_SetSRID(ST_MakePoint(121.4737, 31.2304), 4326));

-- 以米为单位计算两点的球面距离。
SELECT
    round(
        ST_Distance(
            (SELECT geom::geography FROM places WHERE name = 'Beijing'),
            (SELECT geom::geography FROM places WHERE name = 'Shanghai')
        )
    ) AS distance_meters;

-- 验证 PROJ 支持的坐标转换是否可用。
SELECT ST_AsText(
    ST_Transform(
        ST_SetSRID(ST_MakePoint(116.4074, 39.9042), 4326),
        3857
    )
) AS web_mercator_point;

-- 检查空间索引查询路径；测试数据较少时规划器可能仍选择顺序扫描。
EXPLAIN
SELECT name
FROM places
WHERE ST_DWithin(
    geom,
    ST_SetSRID(ST_MakePoint(116.4, 39.9), 4326),
    0.1
);
SQL

dropdb "$DB_NAME"

重点查看 postgis_full_version() 的结果。它比单独执行 SELECT postgis_version() 更适合环境审计，因为可以帮助确认实例实际使用的 GEOS、PROJ 等组件版本。

若系统还需要栅格能力，可以在测试数据库中追加：

CREATE EXTENSION postgis_raster;
SELECT postgis_full_version();

这一步要求环境中具备 GDAL 3 或更高版本。需要 SFCGAL 功能时，也应在同一套预发布环境中安装对应扩展，并确认 SFCGAL 至少为 2.3.0。不要把“扩展创建成功”当作完整验证，还应运行业务实际使用的三维运算、栅格处理或拓扑查询。

从现有实例升级时，测试业务对象而不只是版本号

可以先在克隆数据库或脱敏备份中列出当前扩展状态：

SELECT
    e.extname,
    e.extversion,
    n.nspname AS schema_name
FROM pg_extension AS e
JOIN pg_namespace AS n ON n.oid = e.extnamespace
WHERE e.extname LIKE 'postgis%'
   OR e.extname IN ('address_standardizer', 'fuzzystrmatch')
ORDER BY e.extname;

在操作系统或容器中安装目标版本文件后，可以在测试副本中更新扩展：

ALTER EXTENSION postgis UPDATE;

-- 仅在这些扩展已经安装且目标环境提供升级文件时执行：
ALTER EXTENSION postgis_raster UPDATE;
ALTER EXTENSION postgis_topology UPDATE;

执行前应先备份，并通过 pg_available_extension_versions 确认服务器确实提供目标升级路径：

SELECT name, version, installed
FROM pg_available_extension_versions
WHERE name LIKE 'postgis%'
ORDER BY name, version;

升级验证不能止于扩展版本。建议抽取业务中代价最高、边界条件最多的 SQL，至少覆盖：

  • ST_Intersects、ST_Contains、ST_DWithin 等空间谓词；
  • GiST 或 SP-GiST 空间索引的执行计划；
  • 常用 SRID 之间的 ST_Transform；
  • 无效几何、空几何与混合维度数据；
  • 若启用栅格、拓扑或 SFCGAL，对应的核心业务操作；
  • 驱动、ORM 和连接池对 PostgreSQL 目标版本的兼容性。

采用建议：把 RC2 当成演练版本

更稳妥的落地顺序是：

  1. 在与生产环境相同的 PostgreSQL 主版本上安装 3.7.0rc2；
  2. 用 postgis_full_version() 核对实际链接的 GEOS、PROJ、GDAL 和 SFCGAL；
  3. 恢复一份脱敏生产数据，执行扩展升级与应用回归测试；
  4. 比较关键空间 SQL 的结果、执行计划和耗时；
  5. 验证备份恢复与回退方案，再决定是否等待 3.7.0 正式版。

如果目标只是保持生产稳定，可以继续使用已验证的稳定分支，并把 RC2 用于提前发现兼容性问题。如果团队维护 PostGIS 扩展、空间算法平台或数据库发行镜像，那么 RC2 正是验证 PostgreSQL 14 至 19 Beta 3 兼容性、补充回归用例和反馈问题的合适窗口。

# AI # PostgreSQL # 数据库

相关推荐