↑↓ 选择↵ 打开⌫ 切换范围完整搜索

PG.CENTER 连接 PostgreSQL 文档、百科与生态知识。由 Pigsty 维护。

支持中的版本: 14

E.2. 发布版本 14.23 #

发布日期:. 2026-05-14

本次发布包含来自 14.22 的多项修复。有关 14 主版本新特性的说明,请参见第 E.25 节。

PostgreSQL 社区将于 2026 年 11 月停止发布 14.X 发布系列的更新。建议用户尽快升级到较新的发布分支。

E.2.1. 迁移到版本 14.23 #

对于运行 14.X 的用户,不需要执行导出/恢复。

但是,如果是从早于 14.19 的版本升级,请参见第 E.6 节。

E.2.2. 变更 #

  • 防止处理启动包时发生无界递归(Michael Paquier)§ §

    恶意客户端可以通过无限交替发送被拒绝的 SSL 和 GSS 加密请求,使已连接的后端崩溃。

    PostgreSQL 项目感谢 Calif.io(与 Claude 和 Anthropic Research 协作)报告此问题。(CVE-2026-6479)

  • 修复内存分配计算中的多处整数溢出问题(Tom Lane,Nathan Bossart,Heikki Linnakangas)§ § § § § § § § § §

    多处代码在计算需要分配多少内存时,未充分注意整数溢出的可能性。溢出会导致分配过小的缓冲区,调用者随后会写过该缓冲区的末尾。这至少会触发服务器崩溃,并且很可能可被利用来执行任意代码。在许多但绝非所有情况下,这种风险只存在于 32 位构建中。

    PostgreSQL 项目感谢 Xint Code、Bruce Dang、Sven Klemm 和 Pavel Kohout 报告这些问题。(CVE-2026-6473)

  • 拒绝 ts_headline() 中过长的选项(Michael Paquier)§

    StartSel、StopSel 和 FragmentDelimiter 字符串的长度不得超过 32Kb,但此前没有对此进行检查。过长的值通常会使服务器崩溃。

    PostgreSQL 项目感谢 Xint Code 报告此问题。(CVE-2026-6473)

  • 防范 timeofday() 和 pg_strftime() 中的恶意时区名(Tom Lane)§ §

    精心构造的时区设置可能将 % 序列传递给 snprintf(),从而可能造成崩溃或泄露服务器内存。另一条导致类似结果的路径,是让 pg_strftime() 使用的固定大小输出缓冲区溢出。

    PostgreSQL 项目感谢 Xint Code 报告此问题。(CVE-2026-6474)

  • 创建多范围类型时,确保用户在为该多范围类型指定的模式上拥有 CREATE 权限(Jelte Fennema-Nio)§

    多范围类型可以放入不同于其父范围类型的模式中,但此前在这样做时遗漏了必需的权限检查。

    PostgreSQL 项目感谢 Jelte Fennema-Nio 报告此问题。(CVE-2026-6472)

  • 在认证代码中使用时序安全的字符串比较(Michael Paquier)§ §

    在检查口令、hash 等值时,使用 timingsafe_bcmp() 而不是 memcmp() 或 strcmp()。尚不清楚这些函数的数据依赖性在这些位置是否真的可被有效利用,但为安全起见,将其替换。

    PostgreSQL 项目感谢 Joe Conway 报告此问题。(CVE-2026-6478)

  • 将 PQfn() 标记为不安全,并避免在 libpq 内部使用它(Nathan Bossart)§

    对于非整数结果类型,PQfn() 不会获得输出缓冲区的大小,因此它无法检查服务器返回的数据能否放入缓冲区。恶意服务器因而可能覆盖客户端内存。若不改变 API 就无法修复这一点,所以将该函数标记为已废弃。在 libpq 内部,改用一个能够执行缺失检查的变体版本。

    PostgreSQL 项目感谢 Yu Kunpeng 和 Martin Heistermann 报告此问题。(CVE-2026-6477)

  • 防止 pg_basebackup 和 pg_rewind 中的路径遍历(Michael Paquier)§

    这些应用未能验证从其输入中读取的输出文件路径,因而恶意来源可以覆盖这些应用可写的任意文件。通过拒绝绝对路径或包含父目录引用的路径,约束数据可以写入的位置。

    PostgreSQL 项目感谢 Tencent Xuanwu Lab 的 XlabAI Team 和 Valery Gubanov 报告此问题。(CVE-2026-6475)

  • 防范 contrib/intarray 的 query_int 类型以及 contrib/ltree 的 ltxtquery 类型中的字段溢出(Tom Lane)§ §

    这些查询结构的解析没有检查 16 位字段溢出,因而可能构造出无效的查询树。执行该查询时,这可能使服务器崩溃。

    PostgreSQL 项目感谢 Xint Code 报告此问题。(CVE-2026-6473)

  • 防范 contrib/ltree 的 lquery 类型中过长的值(Michael Paquier)§

    包含超过 64K 个项的值会导致内部溢出,可能造成栈破坏或错误结果。

    PostgreSQL 项目感谢 Vergissmeinnicht、A1ex 和 Jihe Wang 报告此问题。(CVE-2026-6473)

  • 防止 contrib/spi 中的 SQL 注入和缓冲区越界写(Nathan Bossart)§

    check_foreign_key() 在为键值加引号时不够谨慎,并且还使用固定长度缓冲区构造查询。虽然该模块只是作为示例代码,但仍然不应包含此类危险错误。

    PostgreSQL 项目感谢 Nikolay Samokhvalov 报告此问题。(CVE-2026-6637)

  • 在假定支持排序规则的类型上的等值条件意味着唯一性之前,检查是否存在非确定性排序规则(Richard Guo)§ §

    许多规划器优化都会假定,例如,如果 x 上存在唯一索引,则最多只有一个表行能满足 WHERE x = 'abc'。不过,如果该索引和 WHERE 子句附加了不同的排序规则,一般来说这个结论是不安全的。当两个排序规则都是确定性排序规则时这是安全的,因为该属性本质上要求两个字符串相等就意味着逐位相等。但非确定性排序规则并不如此,因此如果 WHERE 子句或索引任一方具有非确定性排序规则,基于唯一匹配假设进行优化就可能给出错误的查询结果。

  • 修正规则动作和规则限定条件中对 NEW 生成列的错误处理(Richard Guo,Dean Rasheed)§

    此前,在 INSERT 情况下,此类列引用会生成 NULL;在 UPDATE 情况下,则等同于 OLD 值。

  • 修复虚假的“generated columns are not supported in COPY FROM WHERE conditions”错误(Tom Lane)§

    在 COPY FROM WHERE 条件中使用系统列时,有时会错误报告此错误。

  • 修复源表包含已删除列时的 CREATE TABLE ... LIKE ... INCLUDING STATISTICS(Julien Tachoires)§

    在这类情况下,扩展统计信息对象可能会被错误复制,或该命令可能给出错误的报错。

  • 允许 ALTER INDEX ... ATTACH PARTITION 在适当时将父索引标记为有效(Sami Imseih)§

    存在一些边界情况:即使分区索引的所有叶子索引均有效,该分区索引仍可能保持被标记为无效。此变更提供了一种机制,使用户可以在不借助手工更新系统目录的情况下纠正这种情况。

  • 修复 ALTER FOREIGN DATA WRAPPER,使其不要删除包装器对象对其处理器函数的依赖(Jeff Davis)§

  • 不允许复合类型通过多范围成为自身的成员(Heikki Linnakangas)§

    当中间类型是域、数组、复合类型或范围时,我们已经禁止此类情况;但此前遗漏了多范围。

  • 修复 Datum 镜像比较,使其不受符号扩展差异影响(David Rowley)§

    这修复了一些此前会导致“could not find memoization table entry”错误或错误查询结果的情况。

  • 修复带非严格等值操作符的 hash IN/NOT IN 的错误逻辑(Chengpeng Yan)§

    此前的代码可能崩溃或给出错误结果。所有内置数据类型都有严格的等值操作符,因此此问题只可能出现在扩展数据类型上。

  • 在 to_char() 中截断过长的区域设置相关数字符号(Tom Lane)§

    如果某个区域设置指定了长度超过 8 字节的货币符号、千位分隔符、小数符号或正负号符号,就可能出现缓冲区越界写。现实世界中不存在这样的区域设置,而且非特权攻击者也不太可能在 Postgres 服务器下安装恶意区域设置定义;但为安全起见,检查过长符号并在需要时截断。

  • 防止解析 Ispell 字典的词缀文件时发生缓冲区越界写(Tom Lane)§ §

    损坏或恶意的词缀文件可能使服务器崩溃。这不被视为安全问题,因为文本检索配置文件被假定为可信,但仍然值得修复。

  • 防范窗口聚合的帧起始和结束位置计算中的整数溢出(Richard Guo)§

    用户指定的极大偏移量(接近 INT64_MAX)可能导致错误或错误的查询结果。

  • 修复 pglz_decompress() 接收损坏输入时的缓冲区越界读问题(Andrew Dunstan)§

    此前可能读取输入末尾之后的几个字节,在极其不走运的情况下可能导致崩溃。

  • 确保即使发生错误后,tuplestore 数据结构在内部也保持一致(Tom Lane)§

    此前代码对此不够谨慎,这在大多数时候没有问题,但对于支撑 WITH HOLD 游标的 tuplestore 则有问题。在 v15 及更早版本中,这会导致容易重现的崩溃;目前尚不知道较新分支是否易受影响,但最好在所有分支中保持一致性。

  • 修复 pg_stat_replication 中过早报告 NULL 延迟的问题(Shinya Kato)§

    即使复制活动正在发生,延迟列也经常读作 NULL。

  • 避免处理不记录 WAL 的 GiST 索引时罕见的刷盘失败(Tomas Vondra)§

    不记录 WAL 的 GiST 索引有时仍可能产生“xlog flush request n/nnnn is not satisfied”错误,原因是错误地选择了一个“假 LSN”来表示插入点。

  • 修复对非常规大小的段所需 DSA 页面映射大小的低估问题(Paul Bunn)§

    此误算导致越界访问,并进而造成服务器崩溃。

  • 修复处理扩展数据类型表达式上的扩展统计信息时可能发生的服务器崩溃(Michael Paquier)§

    如果该数据类型的 typanalyze 函数没有计算任何有用的统计信息,就可能发生 NULL 指针解引用。核心内置的 typanalyze 函数都不会这样表现,但扩展可能会如此。

  • 修复检查点 WAL 重放与多事务 ID 创建之间的竞态条件(Heikki Linnakangas)§

    跟随来自较旧小版本主库的 WAL 的备库,可能陷入反复崩溃和重启的循环,并抱怨“could not access status of transaction”。

  • 防止 WAL 发送进程关闭时无限期等待(Anthonin Bonnefoy)§ §

    在发布逻辑复制数据的集簇关闭时,WAL 发送进程会等待所有待处理 WAL 被写出。但它没有正确请求执行此操作,因此在某些情况下这可能变成无限期等待。

  • 确保恢复期间对表空闲空间映射的更改会被持久化(Alexey Makhmutov)§

    此前,在重放应当改变空闲空间映射的操作时,WAL 重放确实会更新该映射;但如果启用了校验和,映射页缓冲区不会被标记为脏,因此这些更改可能永远不会被写出。在备库上,随着时间推移,这会导致映射与表的实际内容严重不符。虽然该映射只作为提示使用,但在备库被提升为活跃服务器后,直到大部分映射被更新修复之前,这种情况可能在一段时间内造成显著性能下降。

  • 修复某些 ecpg 函数在没有已建立连接的情况下被调用时的崩溃(Shruthi Gowda)§

  • 在 pg_upgrade 中,连接到较旧源服务器时注意使用正确的协议版本(Jacob Champion)§

    在尝试从 2018 年以前的服务器升级时,这可能会造成问题。

  • 修复 contrib/ltree,使其能够处理大小写折叠改变字符串字节长度的情况(Jeff Davis)§

    此前,指定大小写不敏感匹配的 lquery 模式,可能无法匹配本应匹配的标签。

  • 在 contrib/pg_stat_statements 中,如果解析 pgss_query_texts.stat 文件时发生错误,不要泄漏内存(Heikki Linnakangas)§

  • 在 contrib/postgres_fdw 中,避免因过早清理失败连接而崩溃(Etsuro Fujita)§

    如果远程连接的中止清理失败,我们就不能再使用它。但要将关闭连接对象延迟到事务结束时执行,因为打开的游标等数据结构中可能仍有对它的引用。

  • 将时区数据文件更新到 tzdata 2026b 发布版本(Tom Lane)§

    British Columbia(America/Vancouver)将从 2026 年 11 月开始全年采用 UTC-07(实际上就是永久 DST)。本次发布假定其 TZ 缩写从那时起为 MST。这看起来可能会改变,但尚不清楚会使用什么新缩写。另外还有一项针对 Moldova 的历史修正:自 2022 年以来,他们一直遵循 EU 的 DST 转换时间。

报告文档问题

阅读 上游文档. 通过 PostgreSQL 文档反馈表单.