PostgreSQL 18.7 等五个版本与 19 RC 2 发布：自建数据库该不该马上升级

PostgreSQL 全球开发组于 2026 年 11 月 12 日发布 18.7、17.12、16.16、15.20、14.25 五个小版本更新，以及 PostgreSQL 19 的第二个候选版本 19 RC 2。官方称本次修复 52 个安全漏洞和 140 多个缺陷。对在云服务器上自建 PostgreSQL 的个人站长和中小企业运维来说，这是一次应当尽快安排的安全更新；但升级不止替换二进制，部分实例还需要重建索引、重做全量备份，所以要先确认自己的索引类型和备份方式，再定维护窗口。

这次发布了什么，谁需要关注

本次更新覆盖当前仍受支持的五个主要分支，同时给出 PostgreSQL 19 正式版前的最后一个候选版本。官方公告明确 PostgreSQL 14 已进入生命周期结束（EOL），14.25 是它的最后一个版本，之后不再获得安全与缺陷修复。

18.7、17.12、16.16、15.20：常规小版本更新，累积包含此前所有修复。
14.25：PostgreSQL 14 的收尾版本，生产环境继续使用意味着后续漏洞没有官方补丁。
19 RC 2：候选版本，官方说明其内容与 19 正式版基本一致，正式版计划于 2026 年 11 月 19 日发布，该日期属官方计划，可能调整。

如果你的数据库只在内网、访问来源可控，风险相对低一些，但小版本更新同时包含缺陷修复，仍建议按计划跟进。如果实例暴露在公网、承载多用户业务，或跑着 WordPress 这类依赖数据库的站点，优先级应提高。

版本对照：该升到哪个分支

当前版本	建议动作	说明
18.x	升级到 18.7	当前主要支持分支，小版本直接替换二进制
17.x	升级到 17.12	仍在支持期，按小版本流程更新
16.x	升级到 16.16	仍在支持期，按小版本流程更新
15.x	升级到 15.20	仍在支持期，需留意该分支剩余支持时间
14.x	规划大版本升级	14.25 为最后版本，无后续安全补丁，应通过 pg_upgrade 或 dump/restore 迁移到受支持分支

小版本更新是累积的，通常不需要 dump/reload，也不需要 pg_upgrade，停止服务、替换二进制再启动即可。大版本升级则必须走升级工具或导出导入流程，两者不要混为一谈。

52 个安全漏洞怎么理解

官方公告列出的一批 CVE 中，多个条目 CVSS v3.1 评分为 8.8，问题类型集中在类型混淆、释放后使用（use-after-free）、整数回绕等，官方描述为可导致执行任意代码。也有评分较低的信息泄露、权限绕过类问题。逐个背 CVE 编号意义不大，更实用的判断是：

高分漏洞多与扩展、类型转换、备份恢复工具相关，说明攻击面不只在 SQL 查询本身。
pg_dump、pg_restore、vacuumdb、reindexdb 等运维工具也在修复范围内，日常备份恢复流程同样需要更新后的二进制。
具体某个 CVE 影响哪些版本、触发条件是什么，应以官方 release notes 和对应 CVE 页面为准，本文不逐条展开。

换句话说，只升级数据库服务端而保留旧版客户端工具，并不能覆盖全部修复。

升级后必须补做的操作

这是本次更新最容易被忽略的部分。官方在 Updating 章节说明了几类需要额外处理的情况，以下按操作类型整理。

1. 重建可能受影响的索引

本次修复了 GIN 索引可能导致索引损坏的问题，以及 pg_trgm 的 GiST 索引可能漏行的问题。如果怀疑索引受影响，更新后需要重建：

-- 重建单个索引，将 your_index_name 替换为实际索引名
REINDEX INDEX your_index_name;

-- 重建整张表及其 TOAST 表，适用于出现 missing chunk number 报错的情况
REINDEX TABLE your_table_name;

REINDEX 会持有较重的锁，大表上执行前应评估对业务的影响，必要时使用 CONCURRENTLY 变体，但它耗时更长、对系统资源要求更高。

2. 检查 bpchar 列上的 B-tree 索引

声明为 bpchar 但不带长度的列，其 B-tree 索引在本次更新后需要重建，否则 index-only scan 可能返回错误结果。声明为 char(n) 的列不受影响。先确认是否存在这类列和索引，再安排重建。

3. 排查分区表的 NOT NULL 约束

官方给出了查找语句，用于定位分区表上带 NO INHERIT 的 NOT NULL 约束：

SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n'
  AND connoinherit
  AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

不需要的约束可以用 ALTER TABLE … DROP CONSTRAINT 删除；需要保留的应改为继承约束，若分区中已存在 NULL 值，该操作会失败，需要先处理数据。

4. 增量备份重新做一次全量

本次修复了增量备份可能产生损坏备份的问题。使用增量备份的团队，更新后应重新做一次全量备份，并以它作为后续增量的基础，避免继续沿用可能已损坏的备份链。

在云服务器上执行小版本升级的步骤

以下流程适用于 Linux 上通过包管理器安装的 PostgreSQL，具体包名和路径随发行版与安装方式不同，执行前请对照自己的环境。全程需要数据库超级用户权限和服务器 root 或 sudo 权限。

确认当前版本与安装方式：执行 SELECT version();，并确认是系统包、官方仓库还是源码编译，这决定后续替换方式。
盘点索引与备份策略：检查是否存在 GIN 索引、pg_trgm 的 GiST 索引、bpchar 无长度列的 B-tree 索引，以及是否使用增量备份。
做一次可恢复的备份：至少完成一次全量逻辑或物理备份，并在测试环境验证可恢复。备份文件不要与数据库放在同一块磁盘。
安排停机窗口：小版本更新需要停止服务，通知业务方，避开流量高峰。
停止服务并更新软件包：先停数据库，再执行包管理器更新，避免运行中替换二进制。
启动服务并验证：检查启动日志无报错，执行 SELECT version(); 确认版本号，再抽查关键业务查询。
按上文清单执行补做步骤：重建必要索引、处理分区表约束、重做全量备份。
观察一段时间：关注慢查询、错误日志和复制延迟，确认无异常后再结束维护窗口。

操作提醒

升级前务必确认备份可用，REINDEX 和约束变更都可能影响业务读写；生产环境不要直接照搬示例中的表名和索引名。若使用流复制或逻辑复制，订阅端也应同步更新，否则可能因修复项差异出现行为不一致。

19 RC 2 要不要现在用

19 RC 2 适合做兼容性验证：在独立测试实例上跑一遍业务查询和应用集成测试，提前发现大版本升级中的问题。官方提示，如果从 19 RC 1 升级，曾在测试中创建过基于 JSON_ARRAY()、JSON_OBJECT() 的表达式索引、生成列或分区键的对象，需要先删除或重定义，否则 pg_dump/pg_restore 和 pg_upgrade 会失败。另外，使用全文检索、pg_trgm 或 fuzzystrmatch 索引的实例，升级到 19 后可能需要重建索引，具体见 release notes 的迁移章节。

生产环境不建议在正式版发布前切换。候选版本仍可能有修复，且大版本升级涉及应用兼容性、扩展插件和驱动版本，需要单独规划。

按场景的行动建议

个人站长、单机 WordPress 站点：先备份数据库和站点文件，在低流量时段按包管理器流程升级到当前分支最新小版本，升级后检查插件是否正常，再按需重建索引。
中小企业运维、多实例环境：先在预发环境完整走一遍升级和补做步骤，记录耗时，再分批在生产执行；同时更新备份恢复工具链的版本。
仍在跑 PostgreSQL 14：把大版本升级列入近期计划，评估 pg_upgrade 或逻辑导出导入的停机成本，不要继续等待不存在的小版本补丁。
计划上 19 的团队：用 RC 2 做兼容性测试，正式版发布后再安排生产切换。

数据库跑在云服务器上时，升级窗口还要考虑同机应用的停机范围，以及磁盘快照能否作为回滚手段。先确认回滚路径，再动手升级，比事后补救更省事。

常见问题

小版本更新需要导出再导入吗？

不需要。小版本更新是累积的，停止服务替换二进制后启动即可。只有跨大版本才需要 pg_upgrade 或 dump/restore。

不重建索引会怎样？

受影响的 GIN 索引可能已损坏，导致查询漏行或返回无关行；pg_trgm 的 GiST 索引可能漏掉匹配结果；bpchar 列上的 B-tree 索引可能导致 index-only scan 返回错误值。是否受影响取决于索引类型和数据，无法一概而论。

只升级服务端、不升级客户端工具可以吗？

不建议。本次修复涉及 pg_dump、pg_restore、vacuumdb、reindexdb 等工具，备份恢复流程也应使用更新后的版本。

19 RC 2 能直接用于生产吗？

官方将其定位为候选版本，正式版计划于 2026 年 11 月 19 日发布。生产环境应等待正式版，并完成兼容性测试后再切换。

PostgreSQL 14 还能继续用吗？

可以运行，但 14.25 之后不再有安全与缺陷修复，暴露在公网或处理敏感数据的实例风险会随时间上升，应尽快规划迁移。

本文由网上采集发布，不代表我们立场，转载联系作者并注明出处：https://www.uuccloud.com/11938.html