修复无法删除大表的非第一个段的故障 (Tom Lane)

PostgreSQL将大表拆分为多个文件（通常每个文件1GB）。 删除表的逻辑存在问题，可能会漏掉除第一个文件外的所有文件，有两种情况： 临时表的删除和常规表的WAL重放删除。经常创建多GB临时表的应用可能会 遭受重大磁盘空间泄漏。

孤立的临时表文件在postmaster启动时被删除，因此仅仅更新到15.1版本就足以清除任何泄漏的临时表存储。 但是，如果在使用15.0版本时遇到任何数据库崩溃，并且在这些崩溃之前可能有大表被删除，建议检查数据库目录中是否有按照以下模式命名的文件： NNNN.NN。 如果没有匹配的文件只是命名为NNNN（没有.NN后缀）， 这些文件应该手动删除。

修复在可更新视图上的INSERT命令的多行VALUES 子句中出现的DEFAULT标记的处理问题 （Tom Lane）

这个疏忽可能导致“类型的缓存查找失败”错误，甚至在旧分支中可能导致崩溃。

不允许命名为_RETURN的规则，除非是ON SELECT（Tom Lane）

这样可以避免视图的ON SELECT规则与其它规则混淆。

避免在使用EXPLAIN VERBOSE对使用常量初始值的SEARCH BREADTH FIRST查询时失败（Tom Lane）

防止在具有外部表分区的分区表上使用MERGE (Álvaro Herrera)

该案例不受支持，并且以前会抛出一个难以理解的错误。

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

以前，对于新添加的分区，可能会构建不正确或重复的约束。

修复在分区或继承表上使用扩展统计信息时的计划器故障（Richard Guo，Justin Pryzby）

一些情况下失败了，显示“统计对象的缓存查找失败”。

修复GIN索引的快速插入路径中WAL操作的错误排序（Matthias van de Meent，张明立）

这个错误在核心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)

邮件管理员进程应该在共享内存损坏时能够存活并启动数据库重启，但有一段代码对此并不够谨慎。

在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参数超过2³¹（Tom Lane）

这个疏忽导致pg_upgrade在源安装中包含OID大于该值的数据库时无法成功。

在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版本，以反映智利、斐济、伊朗、约旦、墨西哥、巴勒斯坦和叙利亚的夏令时法律变化，以及智利、克里米亚、伊朗和墨西哥的历史更正。

另外，欧洲/基辅时区已更名为欧洲/基辅。 此外，以下时区已合并到附近人口更多的时区，自1970年以来，这些时区的时钟已经与它们达成一致： 南极洲/沃斯托克，亚洲/文莱，亚洲/吉隆坡，大西洋/雷克雅未克，欧洲/阿姆斯特丹， 欧洲/哥本哈根，欧洲/卢森堡，欧洲/摩纳哥，欧洲/奥斯陆，欧洲/斯德哥尔摩，印度/圣诞岛， 印度/科科斯群岛，印度/凯尔盖朗岛，印度/马埃岛，印度/留尼汪岛，太平洋/楚克岛，太平洋/富纳富提岛， 太平洋/马朱罗岛，太平洋/波恩佩岛，太平洋/威克岛和太平洋/瓦利斯岛。 （这间接影响了那些已经链接到其中一个时区的时区：北极/朗伊尔比恩，大西洋/扬马延岛，冰岛， 太平洋/波纳佩，太平洋/特鲁克和太平洋/雅浦。）美洲/尼皮贡，美洲/雷尼河，美洲/桑德湾， 欧洲/乌日哥罗德和欧洲/扎波罗热在发现他们声称的与这些时区的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的向后兼容选项安装本地构建的时区数据文件（请参阅它们的PACKRATDATA和PACKRATLIST选项）。