PostgreSQL 18.7等维护版发布:修复52项漏洞,14系列结束支持
PostgreSQL 18.7、17.12、16.16、15.20和14.25修复了52项安全漏洞及超过140项缺陷。已有部署除了更新对应主版本的维护包,还要检查索引和增量备份;14.25是14系列的最后一次维护发布,应同步安排迁移到仍受支持的版本。
PostgreSQL 18.7、17.12、16.16、15.20和14.25修复了52项安全漏洞及超过140项缺陷。已有部署除了更新对应主版本的维护包,还要检查索引和增量备份;14.25是14系列的最后一次维护发布,应同步安排迁移到仍受支持的版本。
先区分维护更新和跨主版本迁移
18.x升级到18.7、17.x升级到17.12,属于同一主版本内的维护更新。官方说明这类更新无需为了升级而执行全量导出再导入,也不需要使用pg_upgrade;应按现有发行包或托管平台流程停止服务、更新二进制并重新启动。变更前仍应确认备份可恢复、扩展兼容和维护窗口。
14.25可以修复这批问题,却不会恢复14系列的后续支持。生产环境应选择仍受支持的目标主版本,并采用相应的大版本迁移方案。19 RC 2仍是候选版,不能将它误当成已经正式发布的生产维护版本。

升级后怎样检查和重建受影响索引
本次修复包含可能造成GIN索引损坏的问题。怀疑已有索引受到影响时,在升级后重建对应索引:
REINDEX INDEX your_index_name;把示例名称替换为实际索引名。使用pg_trgm的部署,应重建采用gist_trgm_ops操作符类的GiST索引。如果读取表时出现missing chunk number,公告建议在升级后对对应表执行:
REINDEX TABLE your_table_name;表级重建也会处理关联的TOAST表索引。重建会消耗资源并涉及锁,应由数据库维护人员结合业务窗口执行,不要把示例直接当成针对所有数据库的批量命令。

增量备份为什么需要重新建立基线
官方发现多种可能造成增量备份损坏的情况,因此建议升级后重新制作一次完整备份,并将它作为后续增量备份的基线。只更新数据库程序、继续依赖旧增量链,并不能消除旧备份中可能已经存在的问题。
- 按部署现有备份工具完成升级后的新完整备份。
- 在恢复验证环境检查备份能否启动并读取代表性业务数据。
- 将后续增量任务切换到新基线,保留必要的恢复记录。
分区表和bpchar列还需检查什么
公告同时要求排查分区表上的NOT NULL NO INHERIT约束,并提供检查语句:
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 ... ALTER CONSTRAINT ... INHERIT;存在NULL数据时该操作可能失败,先处理实际数据问题。对不带长度的bpchar列所建B-tree索引,升级后也应重建;这一条不涉及声明为char(n)的列。

































