2025年9月25日: PostgreSQL 18 发布！

PostgreSQL 每周新闻 - 2021 年 9 月 26 日

发布于 2021-09-27，作者：PWN
PWN

PostgreSQL 每周新闻 - 2021 年 9 月 26 日

PostgreSQL 14 Release Candidate 1 已发布。 快来测试！

PostgreSQL 产品新闻

JDBC 42.2.24 已发布 https://jdbc.postgresql.ac.cn/documentation/changelog.html#version_42.2.24

check_pgbackrest 2.1 (一个兼容 Nagios 的 pgBackRest 监控工具) 已发布。 https://github.com/dalibo/check_pgbackrest/releases

sqlite_fdw 2.1.0 已发布。

九月 PostgreSQL 工作岗位

https://archives.postgresql.org/pgsql-jobs/2021-09/

PostgreSQL 相关新闻

Planet PostgreSQL：https://planet.postgresql.org/

本周 PostgreSQL 周报由 David Fetter 提供。

请在太平洋标准时间（PST8PDT）周日晚上3:00之前将新闻和公告发送至 david@fetter.org。

已应用补丁

Tomáš Vondra 提交了

  • 不允许在系统列上使用扩展统计信息。自引入扩展统计信息以来，我们一直禁止引用系统列。因此，例如 CREATE STATISTICS s ON ctid FROM t; 会失败。但对于表达式上的扩展统计信息，可以很容易地绕过此限制 CREATE STATISTICS s ON (ctid::text) FROM t; 这是 a4d75c86bf 中的一个疏忽，通过添加一个简单的检查来修复。向 PostgreSQL 14 回溯，其中引入了对表达式上扩展统计信息的支持。回溯至：14 讨论：https://postgr.es/m/20210816013255.GS10479%40telsasoft.com https://git.postgresql.org/pg/commitdiff/c9eeef2a15c02ff7dd2bf3251dbee925b050fc0f

  • 在构建每个统计信息对象后释放内存。到目前为止，给定关系上的所有扩展统计信息都在同一个内存上下文中构建，而没有重置。一些内存被显式释放，但并非全部——例如，在 detoasting 值时分配的内存很难释放。自 PostgreSQL 10 引入扩展统计信息以来，它一直是这样工作的，但增加了对表达式上扩展统计信息的支持使得问题稍微恶化，因为它增加了要构建的统计信息的数量。通过添加一个在构建每个统计信息对象（其中包含的所有统计信息种类）后重置的内存上下文来解决。在构建每种统计信息后重置它会更好，但这需要更具侵入性的更改和结果的复制，使其更难回溯。向 PostgreSQL 10 回溯，其中引入了扩展统计信息。作者：Justin Pryzby 报告者：Justin Pryzby 审阅者：Tomas Vondra 回溯至：10 讨论：https://postgresql.ac.cn/message-id/20210915200928.GP831%40telsasoft.com https://git.postgresql.org/pg/commitdiff/83772cc78e0392a247231ba510c61b6612b93b3f

  • 释放 dependency_degree 分配的内存。计算函数依赖的度可能会分配大量内存——我们已经释放了大部分显式分配的内存，但例如 detoasted varlena 值却被遗留下来。这可能是一个问题，因为我们考虑了很多依赖关系（所有组合），并且 detoasting 可能需要为每个依赖关系重新进行。通过在专用上下文中调用 dependency_degree() 并在每次调用后重置它来解决。我们只需要计算出的依赖度，所以不需要复制任何东西。向 PostgreSQL 10 回溯，其中引入了扩展统计信息。回溯至：10 讨论：https://postgresql.ac.cn/message-id/20210915200928.GP831%40telsasoft.com https://git.postgresql.org/pg/commitdiff/ad8a166ca86846ab691bd6dafc695e0f7dd96012

Tom Lane 提交

Álvaro Herrera 提交

Andres Freund 提交

Peter Geoghegan 提交

  • 移除过度索引删除断言。一个损坏的 HOT 链并非异常情况，即使偏移量指向了页面行指针数组的末尾之外。heap_prune_chain() 并不（也从未）将此情况视为异常，因此 heap_index_delete_tuples() 中的派生代码也不应该这样做。commit 4228817449 中的疏忽。此断言可能只在 Postgres 14 和 master 上失败。早期版本没有 commit 3c3b8a4b，该 commit 指导 VACUUM 截断堆页的行指针数组。但仍将回溯，以保持一致。作者：Peter Geoghegan pg@bowt.ie 报告者：Alexander Lakhin exclusion@gmail.com 讨论：https://postgr.es/m/17197-9438f31f46705182@postgresql.org 回溯：12-，与 commit 4228817449 相同。https://git.postgresql.org/pg/commitdiff/5e6716cde5749aea506dd3f30b099b6e9b4c5af8

  • 修复“单一值策略”索引删除问题。当由自底向上的索引删除通道触发时，重复数据删除不应应用单一值策略。这会浪费周期，因为后来的自底向上删除通道将过度解释重复数据删除实际上“按设计”跳过的旧重复元组。它还使得自底向上删除对于那些恰好越过无意义的“索引每叶页面具有单个键值”阈值的低基数索引效果大大降低。为了解决这个问题，稍微缩小了考虑重复数据删除单一值策略的条件。我们已经避免了对唯一索引使用该策略，因为我们的首要目标必须是为 VACUUM 运行争取时间（而不是节省空间）。现在，当我们在自底向上通道报告失败时，我们也将避免使用它。这两种情况共享相同的首要目标，并且已经重叠很多，所以这种方法非常自然。commit d168b666（添加了自底向上索引删除）中的疏忽。作者：Peter Geoghegan pg@bowt.ie 讨论：https://postgr.es/m/CAH2-WznaOvM+Gyj-JQ0X=JxoMDxctDTYjiEuETdAGbF5EUc3MA@mail.gmail.com 回溯：14-，其中引入了自底向上删除。https://git.postgresql.org/pg/commitdiff/dd94c2852e6e3a246b9fd64bf2d9c7fc01020905

  • 记录 heapam 行指针截断问题。在 commit 3c3b8a4b 之前，检查偏移量是否超过堆页面行指针数组的末尾只是 HOT 链遍历代码的一个防御性健全性检查。但现在它是严格必需的。向 heapam 中需要正确处理此问题的代码添加引用该问题的注释。根据 Alexander Lakhin 的建议。讨论：https://postgr.es/m/f76a292c-9170-1aef-91a0-59d9443b99a3@gmail.com https://git.postgresql.org/pg/commitdiff/c7aeb775df895db240dcd6f47242f7e08899adfb

  • nbtree README：添加关于 latestRemovedXid 的注释。指出索引元组删除通常需要 latestRemovedXid 值用于删除操作的 WAL 记录。这无疑是整个删除操作中最昂贵的部分，因为它现在发生在索引删除的初始执行期间。这可以说是 commit 558a9165e08 中的一个疏忽，该 commit 将生成这些值所需的工作从索引删除 REDO 例程移到了索引删除操作的初始执行。 https://git.postgresql.org/pg/commitdiff/48064a8d330db259076fb7b2300544fbf65f4109

  • vacuumlazy.c：移除过时的 'onecall' 注释。移除对 lazy_vacuum() 的 onecall 参数的过时引用。该函数参数已由 commit 3499df0dee 移除。还移除相邻的介绍 wraparound failsafe 概念的注释块。现在在此处讨论 failsafe 没有意义，因为 lazy_vacuum()（及其相关函数）不再是 failsafe 可能被触发的唯一地方。自 commit c242baa4a8 教会 VACUUM 在其初始堆扫描期间考虑触发 failsafe 机制以来，情况一直是这样。https://git.postgresql.org/pg/commitdiff/c1a47dfe2e9f814e61377f47aa79a113a4c73a63

  • 更新过时的 nbtree 删除注释。_bt_delitems_delete() 不再是索引元组删除（由设置了 LP_DEAD 位的索引元组驱动，现在称为“简单索引元组删除”）使用的高层入口点。它现在是一个低层例程，仅在 commit d168b66682 之后由 _bt_delitems_delete_check() 调用。https://git.postgresql.org/pg/commitdiff/ce2a86053380f7e82dc8318ac48a22a7ab266398

Michaël Paquier 提交

Amit Kapila 提交

Peter Eisentraut 提交

Fujii Masao 提交

Alexander Korotkov 提交了

John Naylor 提交了