2026年2月26日： PostgreSQL 18.3、17.9、16.13、15.17 和 14.22 发布！

PostgreSQL 每周新闻 - 2021年11月28日

发布于 2021-11-29，PostgreSQL Global Development Group
PG 每周新闻

PostgreSQL 每周新闻 - 2021年11月28日

本周人物

十一月份 PostgreSQL 招聘信息

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

PostgreSQL 本地活动

Nordic PGDay 2022 将于2022年3月22日在芬兰赫尔辛基的 Hilton Helsinki Strand Hotel 举行。征稿截止日期为2021年12月31日 详情

PostgreSQL 新闻报道

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

本周 PostgreSQL 每周新闻由 David Fetter 为您呈现

请于太平洋时间周日下午3:00前将新闻和公告提交至 david@fetter.org。

已提交的补丁

Peter Geoghegan 推送了：

  • 移除 lazy_scan_heap 的并行 VACUUM 注释块。这不应放在关于 lazy_scan_heap 执行的任务的非常高层次讨论旁边。在 vacuumlazy.c 顶部已经有一个类似的、更长的注释块直接提到了 lazy_scan_heap。 https://git.postgresql.org/pg/commitdiff/97f5aef609ce51422934b7dbdba599a7de4dbafd

  • 恢复对标记为 full 的页面考虑 HOT。提交 2fd8685e7f 简化了 heap_update() 中对修改属性的检查。这包括一个影响标记为 PD_PAGE_FULL 的页面的微优化：甚至不尝试使用 HOT，以节省确定 HOT 安全性的几个周期。假设是这次不会成功，因为上次也没有成功。移除此微优化。它只能节省绝大多数 heap_update() 调用消耗的周期，这似乎不值得增加的复杂性。而且完全有可能某些工作负载随着微优化的反复应用会随时间变差，尽管短期内平均节省了一些周期。Author: Peter Geoghegan pg@bowt.ie Reviewed-By: Álvaro Herrera alvherre@alvh.no-ip.org Discussion: https://postgr.es/m/CAH2-WznU1L3+DMPr1F7o2eJBT7=3bAJoY6ZkWABAxNt+-afyTA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1a6f5a0e876306293fda697e7820b404d5b93693

  • 更新 vacuumlazy.c 的高层次注释。更新 vacuumlazy.c 文件头注释（以及 lazy_scan_heap 函数上方的注释），这些注释主要是在引入 HOT 优化之前编写的，当时 lazy_scan_heap 做的事情少得多，而且在初始堆遍历期间并不实际执行裁剪。由于 lazy_scan_heap 现在将更多工作委托给低层次函数，通过讨论规定每个阶段顺序的高层次不变量来介绍该函数是有意义的。同时降低内存耗尽 TID 情况的重要性，因为推迟该讨论使得更容易谈论核心重要性的问题。最后，从头注释中移除关于并行 VACUUM 的讨论。这些注释价值不大，而且放在了错误的位置。 https://git.postgresql.org/pg/commitdiff/12b5ade9023f3ecaddcbc423a22dc284c91c79f6

  • vacuumlazy.c: 优先使用术语"清理锁"。术语"超级排他锁"是"清理锁"的一个可接受的同义词。即便如此，在同一文件中从一个术语切换到另一个术语是令人困惑的。在 vacuumlazy.c 中统一使用"清理锁"。根据 Andres Freund 的意见。 https://git.postgresql.org/pg/commitdiff/276db875d4f9be2911582f367596d444d6986c77

Fujii Masao 推送了：

Peter Eisentraut 推送了：

Álvaro Herrera 推送了：

Tom Lane 推送了：

  • 在检查 TAP 测试所需的模块时，探测 $PROVE 而非 $PERL。通常 "prove" 和 "perl" 来自同一个 Perl 安装，但我们支持它们不同的情况（主要因为 MSys 构建农场机器需要这个）。在这种情况下，AX_PROG_PERL_MODULES 完全是错误的工具，因为它检查的是 "perl" 有什么。取而代之的是，制作一个包含所需模块的小 TAP 测试脚本，并在 "prove" 下运行它。此更改后我们根本不需要 ax_prog_perl_modules.m4，所以移除它。为了构建农场的利益，回溯移植到所有支持的分支。Andrew Dunstan and Tom Lane, per an observation by Noah Misch Discussion: https://postgr.es/m/E1moZHS-0002Cu-Ei@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/c4fe3199a6d65212537a59eb0d7e6fad22b9e903

  • 修复带有已删除列的生成列的 pg_dump --inserts 模式。如果表包含一个生成列且其前面有一个已删除的列，dumpTableData_insert 未能考虑到已删除的列，会在错误的列中发出 DEFAULT 占位符。这导致恢复时失败。默认的 COPY 代码路径没有此 bug，这可能解释了为什么它没有更早被发现。在修复的同时，我们可以更智能地处理这种情况：(1) 避免不必要地获取生成列的值，(2) 如果使用 --column-inserts，也从输出中省略生成列。虽然这些模式的性能预计不如 COPY 路径，但我们不妨尽可能高效；它不会增加太多复杂性。根据 Дмитрий Иванов 的报告。回溯移植到引入生成列的 v12。Discussion: https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0b126c6a4b00972f2f3533e1718bbe297e2851c2

  • 消除 perlcritic 警告。根据构建农场。 https://git.postgresql.org/pg/commitdiff/db3a660c6327a6df81a55c4aa86e6c0837ecd505

  • 调整 pg_dump 中类型转换的优先级排序。当存储的表达式依赖于用户定义的类型转换时，后端将依赖记录为在类型转换的实现函数上——或者实际上，如果没有涉及转换函数而只是 RelabelType 或 CoerceViaIO，则根本不记录依赖。这对 pg_dump 来说是有问题的，因为它有可能以错误的顺序转储导致恢复失败。鉴于之前没有报告，风险并不高，但如果类型转换用于某些视图（其行类型随后用作其他函数的输入或结果类型），则可以证明这一点。（这导致视图被提升到转储的函数部分，在类型转换之前。）逻辑上完全可靠的修复需要在表达式的解析形式中包含类型转换的 OID，然后 dependency.c 可以提取它，存储的依赖将强制 pg_dump 做正确的事情。这样的更改将相当具有侵入性，当然不可回溯移植。此外，由于我们更希望使用类型转换语法的表达式与通过显式函数调用做同样事情的表达式 equal()，类型转换 OID 字段必须具有特殊的"比较时忽略"语义，使事情变得复杂。所以，让我们改为通过 pg_dump 中一个非常简单的修改来修复：更改对象类型优先级顺序，使类型转换初始排序在函数之前、紧跟类型之后。这以相当直接的方式修复了没有实现函数的类型转换的问题。对于有实现函数的类型转换，实现函数将通过依赖排序步骤被提升到类型转换之前，因此我们仍然有一个有效的转储顺序。根据 Дмитрий Иванов 的报告。回溯移植到所有支持的分支。Discussion: https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b55f2b6926556115155930c4b2d006c173f45e65

  • Doc: 改进关于 nextval()/setval() 的文档。澄清 nextval 和 setval 的结果在调用事务提交之前不保证持久。一些人似乎从"这些函数永远不会被回滚"的声明中得出了相反的结论，因此重新措辞以避免完全那样说。Discussion: https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4ac452e2285da347c75f5960ae211e183a87b57b

Michaël Paquier 推送了：

David Rowley 推送了：

Amit Kapila 推送了：

Robert Haas 推送了：

  • 修复检测不正确时间线切换的边界情况失败。rescanLatestTimeLine() 包含一个防止切换到在当前恢复点之前从当前时间线分叉的时间线的保护，但如果时间线切换发生在第一条 WAL 记录（必须是检查点记录）被读取之前，该保护不起作用。没有此补丁，在这种情况下可能发生不正确的时间线切换。这是因为 rescanLatestTimeLine() 依赖全局变量 EndRecPtr 来理解 WAL 重放的当前位置。然而，代码中此处的 EndRecPtr 包含的是最后重放记录的终点，而不是当前正在重放的记录的起点或终点。因此，在任何记录被重放之前，它是零，导致健全性检查始终通过。修复方法是显式传递正确的时间线。补丁由我编写，reviewed by Amul Sul。Discussion: http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e7ea2fa342b008ae97e794b0fa2ee538ddcee3b7

  • xlog.c: 移除全局变量 ReadRecPtr 和 EndRecPtr。在大多数地方，这些变量必然存储与 WAL 重放期间使用的 XLogReaderState 的同名成员相同的值，因为 ReadRecord() 在 XLogReadRecord() 返回后立即将结构成员的值赋给全局变量。然而，XLogBeginRead() 调整结构成员但不调整全局变量，因此在 XLogBeginRead() 之后和 XLogReadRecord() 完成之前，值可能不同。否则，它们必须相同。根据我的分析，唯一在可能与结构成员值不同时引用任一变量的地方是 XLogPageRead 中对 EndRecPtr 的引用。因此，在我们使用全局变量的每个其他地方，我们可以切换到使用结构成员，并移除全局变量。Discussion: http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d2ddfa681db27a138acb63c8defa8cc6fa588922

Heikki Linnakangas 推送了：

Andres Freund 推送了：

Daniel Gustafsson 推送了：