发布说明

PostgreSQL 14.6

E.17. 发布版本 14.6 #

发布日期:. 2022-11-10

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

E.17.1. 迁移到版本 14.6 #

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

但是,如果是从早于 14.4 的版本升级,请参见 Section E.19

E.17.2. 变更 #

  • 避免在与 VACUUM 并发执行更新时出现罕见的 PANIC (Tom Lane,Jeff Davis) § §

    如果并发的 VACUUMUPDATEDELETE 正在修改的页面上设置了 all-visible 标志位, 更新命令需要再次清除该位;但某些代码路径未能做到这一点, 最终导致 PANIC 退出和数据库重启。

    已知此问题在版本 14 和 15 中是可能发生的。在之前的分支中可能只是潜在的。

  • 修复在可更新视图的 INSERT 的多行 VALUES 子句中出现的 DEFAULT 令牌的处理(Tom Lane) §

    此疏忽可能导致 cache lookup failed for type 错误,或在较旧的分支中甚至导致崩溃。

  • 不允许名为 _RETURN 但不是 ON SELECT 的规则(Tom Lane) §

    这避免了视图的 ON SELECT 规则与其可能拥有的任何其他规则之间的混淆。

  • 修复为 AFTER 触发器保存元组时的资源管理错误 (Tom Lane) §

    在合适的条件下,这表现为 tupdesc reference NNNN is not owned by resource owner 错误,随后是 PANIC 退出。

  • 避免在使用带常量初始值的 SEARCH BREADTH FIRST 查询时 EXPLAIN VERBOSE 失败 (Tom Lane) §

  • 修复在执行 ALTER TABLE ATTACH PARTITION 时按分区构建外键约束的问题 (Jehan-Guillaume de Rorthais,Álvaro Herrera) § §

    之前,可能会为新添加的分区构建不正确或重复的约束。

  • 修复按分区外键约束的约束名称生成 (Jehan-Guillaume de Rorthais) §

    如果最初给定的名称已被分区的某个约束使用,会选择一个新名称; 但新名称的拼写方式与预期不符。

  • 修复在创建分区索引时索引表达式和谓词的错误匹配 (Richard Guo,Tom Lane) §

    在创建分区索引时,我们尝试识别分区上与分区索引匹配的任何现有索引, 以便将它们作为子索引吸收而不是构建新的索引。 表达式匹配处理不正确,因此可用的子索引可能被忽略, 导致创建重复的索引。

  • 防止备库提升后 WAL 损坏(Dilip Kumar,Robert Haas) §

    当一个执行归档恢复(但未使用备库模式)的 PostgreSQL 实例被提升, 且其尝试读取的最后一个 WAL 段以部分记录结尾时, 该实例将在新时间线上写入无效的 WAL 段。

  • 修复 GIN 索引快速插入路径中 WAL 操作的错误排序 (Matthias van de Meent,Zhang Mingli) §

    此错误在核心 PostgreSQL 中没有已知的负面后果, 但确实导致了一些扩展的问题。

  • 修复在重放起始点位于事务开始和其子事务开始之间时 逻辑解码中的错误 (Masahiko Sawada,Kuroda Hayato) § §

    这些错误可能导致调试构建中的断言失败, 否则会导致内存泄漏。

  • 防止在逻辑解码期间使用错误的快照检查系统目录 (Masahiko Sawada) §

    如果解码从修改系统目录的事务中途开始,解码器可能无法识别这一点, 导致未能将该事务视为进行中的事务来进行目录查找。

  • 在逻辑解码的更多位置接受中断 (Amit Kapila,Masahiko Sawada) § §

    这改善了复制工作进程缓慢关闭的问题。

  • 防止在复制工作进程中尝试复制到外部表分区 (Shi Yu,Tom Lane) §

    虽然分区表可以有外部表作为分区,但目前不支持复制到此类分区。 如果尝试这样做,逻辑复制工作进程会崩溃。 现在会抛出一个错误。

  • 移除对分区表副本标识设置的无意义检查 (Hou Zhijie) §

    重要的是叶子分区的副本标识设置, 因此如果父表上没有设置,无需抛出错误。

  • 避免在复制工作进程中函数语法错误后崩溃 (Maxim Orlov,Anton Melnikov,Masahiko Sawada,Tom Lane) §

    如果在逻辑复制工作进程中执行的 SQL 语言或 PL/pgSQL 语言 CREATE FUNCTIONDO 命令中发生语法错误,工作进程会因空指针解引用或断言失败而崩溃。

  • 修复传递给 SQL 函数的读写扩展数据的处理 (Tom Lane) §

    如果一个非内联 SQL 函数在多个位置使用一个参数, 且其中一个函数期望能够就地修改读写数据, 则后续使用该参数时会观察到错误的值。 (在核心 PostgreSQL 中, 扩展数据机制仅用于数组和复合类型值; 但扩展可能将其用于其他结构化类型。)

  • 修复 circle 类型的等值比较器以正确处理 NaN (Ranier Vilela) §

    如果左侧的圆的半径为浮点 NaN, 它将被认为等于具有相同圆心和任意半径的圆。

  • 在 Snowball 词典中,不尝试对过长的单词进行词干提取 (Olly Betts,Tom Lane) §

    如果输入单词超过 1000 字节,在大小写折叠后直接返回, 而不是尝试通过 Snowball 代码处理。 此限制防止了土耳其语词干提取器中已知的递归导致堆栈溢出的问题, 并且可以作为对 Snowball 词干提取器中可能存在的其他安全或性能问题的保障。 如此长的字符串肯定不是任何人类语言中的单词, 因此词干提取器对其也不太可能做出任何有意义的处理。

  • 修复字符串比较中的释放后使用隐患(Tom Lane) §

    字符串比较函数中的不当内存管理可能导致在已不再分配的缓冲区上写入, 可能破坏正在使用该内存的其他内容。 这只会在相当长的字符串(超过 1kB)且使用 ICU 排序规则时才会发生。

  • 增加对尝试访问没有表访问方法的表的规划时检查 (Tom Lane) §

    这防止了某些目录损坏场景中的崩溃,例如使用了 ON SELECT 规则缺失的视图。

  • 防止共享内存状态损坏时 postmaster 崩溃 (Tom Lane) §

    postmaster 进程应该在共享内存损坏时存活并启动数据库重启, 但有一段代码在这方面不够谨慎。

  • 增加更多防止递归至堆栈溢出的防护措施 (Richard Guo,Tom Lane) § §

  • 避免在 work_mem 非常小且元组较大时 选择哈希表大小的错误行为(Zhang Mingli) §

  • 避免自动清理启动器进程中的长期内存泄漏 (Reid Thompson) §

    缺乏用户报告表明此问题在 v15 之前的分支中只是潜在的; 但原因不太清楚,因此仍然后移了此修复。

  • 改进 PL/pgSQL 处理声明为 RECORD 的参数的能力(Tom Lane) §

    在会话期间为传递给 RECORD 参数的每个具体类型 构建单独的函数缓存条目,与我们对多态参数所做的类似。 这使一些此前会失败并报告 type of parameter does not match that when preparing the plan 的用法正常工作。

  • libpq 中,正确处理管道模式下的单行模式 (Denis Laxalde) §

    如果管道模式同时激活,单行标志未在正确的时间重置。

  • libpq 中为 NULL 连接指针增加缺失的保护检查 (Daniele Varrazzo,Tom Lane) §

    有一个惯例是 libpq 函数应检查 NULL 的 PGconn 参数,并优雅地失败而不是崩溃。 PQflush()PQisnonblocking() 没有遵循这个惯例, 因此予以修复。

  • ecpg 中,修复在同一声明中 声明多个 varcharbytea 变量时遗漏变量存储类的问题(Andrey Sokolov) §

    例如,ecpg 在翻译 static varchar str1[10], str2[20], str3[30]; 时,只有 str1 被标记为 static

  • 允许在 pg_basebackup 中进行跨平台表空间重定位 (Robert Haas) §

    允许 --tablespace-mapping 中的远程路径 为 Unix 风格或 Windows 风格的绝对路径, 因为源服务器可能与本地系统运行在不同的操作系统上。

  • pg_stat_statements 中,修复对已释放内存的访问 (zhaoqigui) §

    pg_stat_statements 跟踪通过扩展查询协议发出的 ROLLBACK 命令时会出现此问题。 在调试构建中,这始终导致断言失败。 在生产构建中,通常没有可见的不良影响;但如果释放的内存已经被重用, 很可能的结果是存储查询字符串的垃圾数据。

  • postgres_fdw 中,确保为 EvalPlanQual 计划构建的目标列表包含所有必需的列 (Richard Guo,Etsuro Fujita) §

    这避免了在罕见情况下出现 variable not found in subplan target list 错误。

  • 拒绝平台的 uuid_create() 函数产生的意外输出 (Nazir Bilal Yavuz) §

    uuid-ossp 模块期望 libc 的 uuid_create() 产生版本 1 的 UUID, 但最近的 NetBSD 版本改为产生版本 4(随机)的 UUID。 检查这一点,如果是则抛出错误。删除文档中关于 NetBSD 实现可用于 uuid-ossp 的声明。 (如果版本 4 的 UUID 对你的目的来说没问题,你根本不需要 uuid-ossp;只需使用 gen_random_uuid() 即可。)

  • 将新的 Perl 测试模块包含在标准安装中 (Álvaro Herrera) §

    在 15 之前的版本分支中将 PostgreSQL/Test/Cluster.pmPostgreSQL/Test/Utils.pm 添加到标准安装文件集中。这是为了方便那些希望在旧版本分支中 使用新编写的测试代码的扩展。

  • 在 NetBSD 上,强制在 postmaster 启动时解析动态符号 (Andres Freund,Tom Lane) §

    这避免了 NetBSD 10 上动态链接器中的死锁风险。

  • 修复与 LLVM 15 的不兼容问题(Thomas Munro,Andres Freund) §

  • 允许在任何机器上使用 __sync_lock_test_and_set() 实现自旋锁(Tom Lane) §

    这简化了向新机器架构的移植,至少在使用支持此 GCC 内置函数的编译器时。

  • 将符号 REF 重命名为 REF_P 以避免在最近的 macOS 上编译失败(Tom Lane) §

  • 避免使用 sprintf,以避免编译时的弃用警告 (Tom Lane) §

  • 消除 clang 15 及更高版本的各种编译器警告(Tom Lane) § § §

  • 将时区数据文件更新为 tzdata 2022f 版本,包含智利、斐济、伊朗、约旦、 墨西哥、巴勒斯坦和叙利亚的夏令时法规变更, 以及智利、克里米亚、伊朗和墨西哥的历史修正。(Tom Lane) §

    此外,Europe/Kiev 时区已重命名为 Europe/Kyiv。 另外,以下时区已合并到附近的、人口更多的、 自 1970 年以来时钟一致的时区中: Antarctica/Vostok、Asia/Brunei、 Asia/Kuala_Lumpur、Atlantic/Reykjavik、Europe/Amsterdam、 Europe/Copenhagen、Europe/Luxembourg、Europe/Monaco、Europe/Oslo、 Europe/Stockholm、Indian/Christmas、Indian/Cocos、Indian/Kerguelen、 Indian/Mahe、Indian/Reunion、Pacific/Chuuk、Pacific/Funafuti、 Pacific/Majuro、Pacific/Pohnpei、Pacific/Wake 和 Pacific/Wallis。 (这间接影响了已经是这些时区别名的时区: Arctic/Longyearbyen、Atlantic/Jan_Mayen、Iceland、 Pacific/Ponape、Pacific/Truk 和 Pacific/Yap。) America/Nipigon、America/Rainy_River、America/Thunder_Bay、 Europe/Uzhgorod 和 Europe/Zaporozhye 也被合并到附近的时区中, 因为发现它们声称的 1970 年后与这些时区的差异似乎是错误的。 在所有这些情况下,之前的时区名称仍作为别名保留; 但实际数据是所合并到的时区的数据。

    这些时区合并导致被合并时区的 1970 年前时区历史丢失, 这对于期望 timestamptz 显示一致性的应用程序可能造成困扰。 例如,存储的值 1944-06-01 12:00 UTC 在选择 Europe/Stockholm 时区时,之前会显示为 1944-06-01 13:00:00+01, 但现在会显示为 1944-06-01 14:00:00+02

    可以使用选项构建时区数据文件来恢复旧的时区数据, 但该选择也会插入大量其他旧的(且通常缺乏充分证据的)时区数据, 导致相比接受这些上游更改,总变化更多。 PostgreSQL 选择按照推荐方式发布 tzdb 数据, 据我们所知,大多数主要操作系统发行版也在这样做。 但是,如果这些更改给你的应用程序造成了严重问题, 一个可能的解决方案是使用 tzdb 的向后兼容选项安装本地构建的时区数据文件 (参见其 PACKRATDATAPACKRATLIST 选项)。