2024年11月21日: PostgreSQL 17.2、16.6、15.10、14.15、13.18 和 12.22 发布！

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

由 PWN 于 2021-09-27 发布
PWN

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

PostgreSQL 14 发布候选版 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

  • 构建每个统计信息对象后释放内存。到目前为止，给定关系的所有扩展统计信息都在相同的内存上下文中构建，而没有重置。一些内存被显式释放，但并非所有内存都被释放 - 例如，在去活化值时分配的内存很难释放。自 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 分配的内存。计算函数依赖的程度可能会分配大量内存 - 我们已经释放了大部分显式分配的内存，但例如，未去活化的 varlena 值被遗留下来。这可能是一个问题，因为我们考虑了很多依赖项（所有组合），并且可能会再次为每个依赖项发生去活化。通过在专用上下文中调用 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() 中的派生代码也不应该这样做。提交 4228817449 中的疏忽。断言可能只会失败在 Postgres 14 和主版本上。早期版本没有提交 3c3b8a4b，该提交教导 VACUUM 截断堆页的行指针数组。为了保持一致性，仍然回溯所有版本。作者：Peter Geoghegan pg@bowt.ie 报告者：Alexander Lakhin exclusion@gmail.com 讨论：https://postgr.es/m/17197-9438f31f46705182@postgresql.org 回溯：12-，就像提交 4228817449 一样。https://git.postgresql.org/pg/commitdiff/5e6716cde5749aea506dd3f30b099b6e9b4c5af8

  • 修复“单值策略”索引删除问题。当由自底向上的索引删除过程触发时，对去重应用单值策略是不合适的。这会浪费循环，因为稍后的自底向上删除过程会过度解释去重实际上“按设计”跳过的较旧的重复元组。它还会使自底向上删除对于恰好跨越无意义的“每个叶子页面的索引具有单个键值”阈值的低基数索引效果大大降低。为了修复此问题，稍微缩小了考虑去重单值策略的条件。我们已经避免了唯一索引的策略，因为我们的高层目标必须只是为 VACUUM 运行争取时间（而不是节省空间）。现在，当我们的自底向上过程报告失败时，我们也会避免它。这两种情况具有相同的高层目标，并且已经显著重叠，因此这种方法非常自然。提交 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 行指针截断的问题。在提交 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 的注释。指出索引元组删除通常需要删除操作的 WAL 记录的 latestRemovedXid 值。现在，由于它在原始执行期间提前发生，这肯定是整个删除操作中最昂贵的部分。这可以说是在提交 558a9165e08 中的一个疏忽，该提交将生成这些值所需的工作从索引删除 REDO 例程移动到索引删除操作的原始执行。https://git.postgresql.org/pg/commitdiff/48064a8d330db259076fb7b2300544fbf65f4109

  • vacuumlazy.c：删除过时的 'onecall' 注释。删除对 lazy_vacuum() 的 onecall 参数的过时引用。该函数参数已由提交 3499df0dee 删除。另外删除介绍环绕保护概念的相邻注释块。在这里讨论保护机制不再有意义，因为 lazy_vacuum()（和相关函数）不再是唯一可能触发保护机制的地方。自提交 c242baa4a8 教导 VACUUM 在其初始堆扫描期间考虑触发保护机制以来，情况一直是如此。https://git.postgresql.org/pg/commitdiff/c1a47dfe2e9f814e61377f47aa79a113a4c73a63

  • 更新过时的 nbtree 删除注释。_bt_delitems_delete() 不再是由设置了 LP_DEAD 位的索引元组驱动的索引元组删除所使用的高级入口点（现在称为“简单索引元组删除”）。它在提交 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 推送了