发布日期：. 2022-11-10
本次发布包含来自 15.0 的多项修复。 有关 15 主版本新特性的说明，请参见 Section E.18。
修复无法删除大表的非首段文件的问题（Tom Lane） §
PostgreSQL 将大表拆分为多个文件（通常每个文件 1GB）。删除表的逻辑存在缺陷，在两种情况下会遗漏除第一个文件之外的所有文件：删除临时表和 WAL 重放删除常规表。经常创建数 GB 临时表的应用程序可能会遭受显著的磁盘空间泄漏。
孤立的临时表文件会在 postmaster 启动时被删除，因此只需更新到 15.1 即可清除任何泄漏的临时表存储。但是，如果你在使用 15.0 时遭遇了数据库崩溃，并且在崩溃之前可能删除了大表，建议检查数据库目录中是否有按照模式 NNNN.NNNNNN. 后缀）的匹配文件，则应手动删除这些文件。NN
修复在可更新视图上的 INSERT 的多行 VALUES 子句中出现的 DEFAULT 标记的处理（Tom Lane） §
此疏忽可能导致 “cache lookup failed for type” 错误，或在较旧的分支中甚至导致崩溃。
禁止名为 _RETURN 但不是 ON SELECT 的规则（Tom Lane） §
这避免了视图的 ON SELECT 规则与它可能拥有的任何其他规则之间的混淆。
避免对使用 SEARCH BREADTH FIRST 和常量初始值的查询执行 EXPLAIN VERBOSE 时失败（Tom Lane） §
防止在具有外部表分区的分区表上使用 MERGE（Álvaro Herrera） §
该情况不被支持，以前会抛出一个难以理解的错误。
修复在执行 ALTER TABLE ATTACH PARTITION 时构建每个分区外键约束的问题（Jehan-Guillaume de Rorthais，Álvaro Herrera） § §
以前，可能会为新添加的分区构建不正确或重复的约束。
修复在分区表或继承表上使用扩展统计时的规划器失败（Richard Guo，Justin Pryzby） §
某些情况会因 “cache lookup failed for statistics object” 而失败。
修复 GIN 索引快速插入路径中 WAL 操作的错误排序（Matthias van de Meent，Zhang Mingli） §
在核心 PostgreSQL 中，此错误没有已知的负面后果，但它确实对某些扩展造成了问题。
修复当重放从事务开始和其子事务开始之间的某个点开始时逻辑解码中的错误（Masahiko Sawada，Kuroda Hayato） § §
这些错误可能导致调试构建中的断言失败，否则导致内存泄漏。
在逻辑解码期间的更多位置接受中断（Amit Kapila，Masahiko Sawada） § §
这缓解了复制工作进程缓慢关闭的问题。
防止在复制工作进程中尝试复制到外部表分区（Shi Yu，Tom Lane） §
虽然分区表可以将外部表作为分区，但目前不支持复制到此类分区。如果尝试这样做，逻辑复制工作进程将崩溃。现在会抛出错误。
避免复制工作进程中函数语法错误后的崩溃（Maxim Orlov，Anton Melnikov，Masahiko Sawada，Tom Lane） §
如果在逻辑复制工作进程中执行的 SQL 语言或 PL/pgSQL 语言的 CREATE FUNCTION 或 DO 命令中发生语法错误，工作进程将因空指针解引用或断言失败而崩溃。
避免对归档模块的关闭回调进行双重调用（Nathan Bossart，Bharath Rupireddy） §
增加计划时检查，以检测对没有表访问方法的表的访问尝试（Tom Lane） §
这可以防止在某些目录损坏场景中的崩溃，例如使用缺少 ON SELECT 规则的视图。
防止在共享内存状态损坏时 postmaster 崩溃（Tom Lane） §
如果共享内存损坏，postmaster 进程应该存活并启动数据库重启，但有一段代码对此不够谨慎。
在 libpq 中，在管道模式下正确处理单行模式（Denis Laxalde） §
如果管道模式也处于活动状态，单行标志没有在正确的时间被重置。
修复 psql 在命令行查询被取消时的退出状态（Peter Eisentraut） §
psql -c 在查询被取消时会以成功状态退出。修复为像其他错误情况一样以非零状态退出。query
允许在 pg_basebackup 中进行跨平台表空间重定位（Robert Haas） §
允许 --tablespace-mapping 中的远程路径为 Unix 风格或 Windows 风格的绝对路径，因为源服务器可能与本地系统使用不同的操作系统。
修复 pg_dump 无法导出某些 CHECK 约束上附加的注释的问题（Tom Lane） §
修复 CREATE DATABASE 以允许其 oid 参数超过 231（Tom Lane） §
此疏忽导致当源安装包含 OID 大于此值的数据库时 pg_upgrade 无法成功。
在 pg_stat_statements 中，修复对已释放内存的访问（zhaoqigui） §
如果 pg_stat_statements 跟踪了通过扩展查询协议发出的 ROLLBACK 命令，就会发生这种情况。在调试构建中，这会始终导致断言失败。在生产构建中通常不会有明显的不良影响；但如果已释放的内存已被重新使用，可能的结果是为查询字符串存储垃圾数据。
修复与 LLVM 15 的不兼容问题（Thomas Munro，Andres Freund） §
允许在任何机器上使用 __sync_lock_test_and_set() 实现自旋锁（Tom Lane） §
这简化了向新机器架构的移植，至少在使用支持此 GCC 内置函数的编译器时是如此。
将符号 REF 重命名为 REF_P 以避免在最近的 macOS 上编译失败（Tom Lane） §
避免使用 sprintf，以避免编译时的弃用警告（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 显示一致性的应用程序可能会造成问题。例如，如果选择了 Europe/Stockholm 时区，存储的值 1944-06-01 12:00 UTC 以前会显示为 1944-06-01 13:00:00+01，但现在会显示为 1944-06-01 14:00:00+02。
可以使用选项构建时区数据文件以恢复较旧的时区数据，但该选择也会插入大量其他旧的（通常缺乏充分证据的）时区数据，导致与上一版本相比的总变更量超过接受这些上游变更。PostgreSQL 选择按照推荐方式发布 tzdb 数据，据我们所知，大多数主要操作系统发行版也是如此。但是，如果这些变更对你的应用程序造成了重大问题，一个可能的解决方案是使用 tzdb 的向后兼容选项安装本地构建的时区数据文件（参见其 PACKRATDATA 和 PACKRATLIST 选项）。