2. PostgreSQL版本演进与兼容性基线
PostgreSQL 的版本节奏相对稳定：每年发布一个大版本，主版本号递增（如 13、14、15、16、17），小版本号用于修复缺陷与安全问题。理解这一节奏是建立兼容性基线的前提——大版本之间可能存在系统目录、默认参数、扩展接口的变化，而小版本升级通常只涉及安全补丁和错误修复，风险低得多。因此，升级前的兼容性检查，核心是围绕“跨大版本”的差异展开。
主要大版本特性差异与影响面
从迁移与升级视角看，值得重点关注的大版本特性往往集中在几个方面：分区能力、逻辑复制、并行查询、索引与存储、权限与安全模型、以及系统目录结构。下面按版本梳理对升级影响较大的变化。
| 版本 | 关键变化 | 升级关注点 |
|---|---|---|
| 12 | 分区表性能提升、支持外键引用分区表、CTE 内联控制 | 分区表 DDL 行为变化，需回归验证 |
| 13 | 逻辑复制支持分区表、B-tree 去重、增量排序 | 逻辑复制槽与订阅端兼容性 |
| 14 | VACUUM 并行、TOAST 压缩可配置、连接管理改进 | vacuum 相关参数与维护窗口 |
| 15 | public schema 默认权限收紧、逻辑复制支持行过滤与列列表 | 权限模型变化，应用账号可能报权限错误 |
| 16 | 逻辑复制支持双向、并行 apply、pg_stat_io 视图 | 复制拓扑与监控指标变化 |
| 17 | 逻辑复制槽故障转移、增量备份、vacuum 内存管理 | 备份恢复流程与复制槽管理 |
其中，15 版本对 public schema 权限的调整是升级中最容易被忽视、却最容易引发应用报错的变化。在 15 之前，普通用户默认可以在 public schema 中创建对象；15 之后，public schema 的 CREATE 权限被收回，只有数据库所有者或显式授权者才能创建。若应用依赖在 public 下建表或建函数，升级后会出现 permission denied for schema public。处理方式是在升级前确认应用账号的建对象需求，必要时显式授权：
-- 升级前检查：哪些角色在 public 下有建对象需求
SELECT nspname, nspacl FROM pg_namespace WHERE nspname = 'public';
-- 升级后按需授权（示例）
GRANT CREATE ON SCHEMA public TO app_user;
系统目录变化与扩展兼容性
系统目录（catalog）是 PostgreSQL 内部元数据的存储位置，大版本升级时目录结构可能新增、删除或调整字段。例如，15 引入了 pg_publication_namespace，16 调整了部分统计视图，17 新增了与增量备份相关的目录项。这些变化对普通 SQL 查询通常透明，但对以下三类对象影响明显：
- 扩展模块：扩展若直接访问系统目录或依赖特定字段，跨大版本可能失效。升级前应逐一确认扩展是否支持目标版本。
- 监控与运维脚本：直接查询
pg_stat_*或pg_catalog的脚本，字段名或含义可能变化。 - 逻辑复制与备份工具：依赖复制槽、WAL 格式或目录结构的工具，需与目标版本匹配。
扩展兼容性是升级检查中最容易“踩坑”的环节。常见扩展如 PostGIS、pg_stat_statements、pgcrypto、uuid-ossp、pg_partman、Citus 等，其版本与 PostgreSQL 大版本存在对应关系。升级前应执行一次扩展清单核对：
-- 查看当前已安装扩展及其版本
SELECT extname, extversion FROM pg_extension ORDER BY extname;
-- 查看可用扩展（需目标版本已安装对应包）
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE installed_version IS NOT NULL;
若某扩展在目标版本中尚无对应版本，升级路径就需要调整：要么先升级扩展、要么暂缓升级、要么寻找替代方案。这一步必须在升级窗口前完成，而不是等到升级当天才发现。
默认参数调整与行为变化
大版本升级时，部分默认参数会发生变化。这些变化不会自动应用到已有集群，但会影响新集群或新会话的行为。典型例子包括：
wal_keep_size在 13 中取代了wal_keep_segments，旧参数名不再生效。- 15 中
publicschema 权限默认收紧，属于安全模型变化而非参数变化。 - 16 中
log_parameter_max_length等日志相关参数默认值调整。 - 17 中 vacuum 内存管理相关参数引入新默认值。
升级前应导出当前集群的非默认参数，与目标版本的默认值逐项比对，判断哪些参数需要显式保留、哪些可以接受新默认值。可使用如下方式导出：
-- 导出当前非默认参数（示例思路）
SELECT name, setting, source
FROM pg_settings
WHERE source NOT IN ('default', 'override')
ORDER BY name;
兼容性检查清单
综合以上分析，升级前应形成一份可执行的兼容性检查清单。清单不是形式，而是升级窗口前的“排雷表”。建议至少覆盖以下条目：
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 扩展兼容性 | 查询 pg_extension，核对目标版本支持情况 | 所有扩展均有目标版本对应包 |
| public schema 权限 | 检查应用账号是否依赖 public 建对象 | 已显式授权或应用已调整 |
| 非默认参数 | 导出 pg_settings 中非默认项 | 逐项确认保留或接受新默认 |
| 系统目录依赖 | 排查监控脚本、运维工具的直接目录查询 | 字段名与目标版本一致 |
| 逻辑复制 | 检查复制槽、订阅端版本与拓扑 | 复制链路支持目标版本 |
| 备份恢复 | 验证备份工具与目标版本兼容 | 可完成一次恢复演练 |
| 应用回归 | 在预升级环境执行核心业务 SQL | 无权限、语法、行为差异报错 |
这份清单的价值在于把“升级当天可能遇到的问题”提前到“升级前可验证的项”。其中，扩展兼容性与 public schema 权限是最常见的两类阻塞项，建议优先处理。参数比对和目录依赖排查则属于“隐性风险”，不一定会立即报错，但可能在升级后数天或数周内暴露。
把上述检查项落实到具体操作时，建议在预升级环境完整走一遍“备份—恢复—应用回归”链路，而不是只做静态检查。静态检查能发现扩展缺失、参数冲突、权限模型变化；动态回归则能暴露 SQL 行为差异、执行计划变化和复制延迟问题。两者结合，才能形成真正可用的兼容性基线。