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

PostgreSQL 每周新闻 - 2021 年 8 月 22 日

发布于 2021-08-23，作者：PWN
PWN

PostgreSQL 每周新闻 - 2021 年 8 月 22 日

本周人物

PostgreSQL 产品新闻

orafce_mail，一个类似于 Oracle 的 DBMS_MAIL 的实用程序，已发布。

2021 年 8 月 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Michaël Paquier 提交

  • 在 recovery.conf 重载 recovery_min_apply_delay 时刷新应用延迟。此提交确保在重放延迟循环中等待由 recovery_min_apply_delay 定义的时间的等待间隔在重载时被正确处理，如果此 GUC 值被更新，则会根据正在重放的提交记录的时间戳重新计算延迟。之前的行为会产生问题，例如，即使延迟已减小或刚刚被取消，重放仍会继续等待。如果应用延迟增加到更大的值，等待将仅遵守旧的设置值，过早完成。作者：Soumyadeep Chakraborty, Ashwin Agrawal 审阅者：Kyotaro Horiguchi, Michael Paquier 讨论：https://postgr.es/m/CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com 回溯补丁到：9.6 https://git.postgresql.org/pg/commitdiff/e4ba1005c0f7a95e3252f38aee02426117b8e12b

  • 撤销对 src/common/ 中十六进制代码的重构。这是对以下提交的合并撤销：- c3826f8，将十六进制解码代码移动到 src/common/ 的重构。此代码由 aef8948 清理，因为它最初与 src/common/ 中的 base64 例程一样缺少溢出检查，这使其不适用于其目的。- aef8948，对十六进制编码/解码代码到 src/common/ 的更高级的重构，增加了对十六进制解码和编码的缓冲区进行健全性检查。正如 Hans Buschmann 所报告的，这些溢出检查很昂贵，并且可能会导致 bytea 或 LO 的解码/编码性能下降，它们的长度越长，性能下降越明显。处理大型 bytea 值的简单 SQL 会显示出清晰的性能分析差异。- ccf4e27，由于 aef8948 而成为可能的清理。撤销所有这些提交将十六进制解码和编码的性能恢复到 13 版本左右的水平。目前以及 beta3 之后，这是最简单的选择。报告者：Hans Buschmann 讨论：https://postgr.es/m/1629039545467.80333@nidsa.net 回溯补丁到：14 https://git.postgresql.org/pg/commitdiff/2576dcfb76aa71e4222bac5a3a43f71875bfa9e8

  • 提高 btree_gist 中浮点数溢出检查的性能。当前代码可能会不必要地调用 isinf()（参数值始终调用两次，而在某些情况下一次就足够了）。zero_valid 从未被使用，但在检查的第一个位置仍会检查 0 的结果值。这与 607f8ce 类似。btree_gist 只是从后端 float4/8 代码中复制了执行这些检查的代码，作为宏 CHECKFLOATVAL()，来执行工作。作者：Haiying Tang 讨论：https://postgr.es/m/OS0PR01MB611358E3A7BC3C2F874AC36BFBF39@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/32cf7f7acce3891cbc3de53327704372bdd36d38

Daniel Gustafsson 提交

John Naylor 提交了

Tom Lane 提交

  • 减少挂起失效消息的内存占用。inval.c 中现有的数据结构对于注册少量缓存失效事件的命令或子事务的常见情况来说效率不高。虽然这在立即提交时无关紧要，但在包含许多 DDL 操作的事务中，这可能会导致大量膨胀。通过对预期用例做一些额外的假设，我们可以切换到使用密集打包数组的表示。虽然这消除了部分数据复制，但似乎在时间上没有太大区别。但空间占用显著减少。补丁作者：我；感谢 Nathan Bossart 的评审。讨论：https://postgr.es/m/2380555.1622395376@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3aafc030a53621e91be2e7c1c72b5f3e8b103486

  • 改进正则表达式编译器的弧线移动/复制逻辑。需要 moveins()、copyins()、moveouts()、copyouts() 函数来保持正则表达式 NFA 中没有重复弧线的定律。Spencer 最初的实现是 O(N^2)，因为它单独检查每个源弧的匹配。在提交 579840ca0 中，我通过添加排序/合并逻辑来改进这一点，如果移动/复制的弧线数量超过几个，则使用该逻辑。然而，我现在意识到这错失了一个机会。在许多调用点，目标状态是新创建的，不能有任何现有的入弧（或出弧）可能重复。因此，花费任何周期来检查重复项都是浪费精力；在这些情况下，我们可以直接盲目地移动/复制所有源弧。添加代码路径来实现这一点。事实证明，对于 copyins()/copyouts()，所有 调用点都具有此属性，使得它们中所有“改进”的逻辑完全无法触及。也许有一天我们会再次需要完整的容量，所以我只是将那些路径用 #ifdef 起来，而不是完全删除它们。顺便，添加一些测试用例以提高该区域以及 regc_locale.c/regc_pg_locale.c 的代码覆盖率。讨论：https://postgr.es/m/810272.1629064063@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/78a843f119ca7d4a6eb173a7ee3bed45889d48d8

  • 减少新正则表达式测试中对区域行为的假设。我过于乐观地假设基于 UTF8 的区域都会将 U+1500 视为 [[:alpha:]] 字符类的一部分。调整提交 78a843f11 添加的测试用例以避免该假设。我们可能需要进一步简化它们，但这应该足以修复早期 buildfarm 的报告。 https://git.postgresql.org/pg/commitdiff/b66336c4e1af0e8eae520623e4b018251807b0bb

  • 防止 ALTER TYPE/DOMAIN/OPERATOR 更改扩展成员资格。如果在扩展更新脚本中对预先存在的、独立的（free-standing）对象调用 recordDependencyOnCurrentExtension，该对象将归扩展所有。在我们当前的 code 中，这可能发生在三种情况下：* 替换“shell”类型或运算符。* CREATE OR REPLACE 覆盖现有对象。* ALTER TYPE SET、ALTER DOMAIN SET 和 ALTER OPERATOR SET。第一个情况是故意的行为，正如 GenerateTypeDependencies 的现有注释所述。对于 CREATE OR REPLACE，这似乎也是适当的行为；至少，明显的替代方案并不更好。但是，它发生在 ALTER 期间是一个共享代码（GenerateTypeDependencies 和 makeOperatorDependencies）在 CREATE 和 ALTER 情况之间使用的结果。由于扩展脚本不太可能 ALTER 已经属于该扩展的对象，因此该行为对于直接目标对象来说并不太令人担忧……但 ALTER TYPE SET 会递归到依赖域，并且如果这些域最初不属于扩展，那么它们最终归扩展所有是非常糟糕的。让我们通过重新定义 ALTER 情况以永远不更改扩展成员资格来解决此问题。我们可以通过仅在 ALTER TYPE SET 递归到域时更改行为来最小化行为更改，但这会使代码复杂化，并且似乎不是更好的定义。根据 Alex Kozhemyakin 的 bug #17144。回溯补丁到添加 ALTER TYPE SET 的 v13。 (其他情况更早，但由于它们仅影响直接命名的对象，因此没有足够的问题来证明将行为更改回溯到更早的版本。) 讨论：https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org https://git.postgresql.org/pg/commitdiff/6b71c925cb817f79cb0d389edacdd033efaa301d

  • 修复 check_agg_arguments 对 aggregate FILTER 子句的检查。 FILTER 子句中的递归实现错误，导致 FILTER 子句最顶层的相关 Var 或 Aggref 被忽略。（当然，这必须是一个普通的布尔 Var 或返回布尔值的聚合。）后果是聚合的正确语义级别被错误识别，这可能导致查询行为不符合规范。如果 FILTER 表达式是一个聚合，这也可能导致未能发出预期的“聚合函数调用不能嵌套”错误，因为规划器和执行器不期望出现这种情况，这可能会导致稍后出现核心转储。根本原因是在提交 b560ec1b0 中盲目复制了一些假设它正在递归到 List 的代码，因此没有检查顶层节点。为了防止关于为什么此调用与其他调用不同的问题，以及可能的未来复制粘贴错误，让我们更改 check_agg_arguments 中的所有三个 check_agg_arguments_walker 调用，即使只有 filter 子句的调用实际上是错误的。根据 Zhiyong Wu 的 bug #17152。自从我们实现 FILTER 以来一直如此，因此回溯补丁到所有支持的版本。（测试表明，v11 之前的分支由于 ExecInitAgg 中的“冗余”检查而设法避免在 bad_Aggref 情况下的崩溃。但我并不确定该保护有多彻底，而且错误行为问题仍然存在，因此也修复 9.6 和 10。）讨论：https://postgr.es/m/17152-c7f906cc1a88e61b@postgresql.org https://git.postgresql.org/pg/commitdiff/2313dda9d493d3685ac7328b49dc6f5a87c1c295

  • 在规则中使用 FOR UPDATE 时避免尝试锁定 OLD/NEW。transformLockingClause 在处理规则的查询时，未能排除 OLD/NEW 的伪 RTE。这导致了奇怪的错误，甚至后来崩溃。这个 bug 非常古老，但并不令人意外，因为没有人注意到，因为在非视图规则中使用 SELECT FOR UPDATE 的用例介于稀薄和不存在之间。不过，崩溃是不行的。根据 Zhiyong Wu 的 bug #17151。感谢 Masahiko Sawada 对问题的分析。讨论：https://postgr.es/m/17151-c03a3e6e4ec9aadb@postgresql.org https://git.postgresql.org/pg/commitdiff/8d2d6ec7708b475787fd92a9f828e554805e3df6

  • 修复 regexp 的 citerdissect/creviterdissect 中的性能 bug。在迭代节点 i'th 子匹配中检测到子匹配“dissect”失败（即反向引用匹配失败）后，我们应该通过调整 i'th 子匹配的尝试长度来继续。但是，如代码所示，这些函数更改了最后一个子匹配的尝试长度，并且只有在用尽该子匹配的所有可能性后，它们才会回溯以调整倒数第二个子匹配，然后是倒数第三个，等等；所有这些都是浪费精力，因为只有更改第 i 个子匹配的开始或长度才可能使其成功。这个疏忽造成了指数级糟糕性能的可能性。幸运的是，由于优化或其他地方应用的约束，在大多数情况下问题都被掩盖了；这解释了为什么我们以前没有注意到它。但即使是很简单，尽管是人为设计的正则表达式，也可能达到这个问题。这是我提交 173e29aa5 中的疏忽。这已经很古老了，所以回溯补丁到所有支持的分支。讨论：https://postgr.es/m/1808998.1629412269@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/facce1da918a8bf55a8f54606512f944529cba85

  • 改进关于 SELECT INTO 误用的错误消息。改进 plpgsql 中的两个地方，以及 spi.c 中的一个地方，其中错误消息会令人困惑地告诉你不能使用 SELECT 查询，而你写的就是一个 SELECT 查询。实际问题是在这些上下文中不能使用 SELECT ... INTO，但消息未能清楚地说明这一点。特殊处理 SELECT INTO 以使这些错误更有帮助。此外，修复 plpgsql 中的相同位置，以及 exec_eval_expr() 中的几个消息，以避免在主要错误消息中引用整个抱怨的查询或表达式。该行为很容易违反我们的消息样式指南，即保持主要错误消息简短且单行。另外，由于消息中的重要部分在插入文本之后，因此可能会使真正的问题很难看到。我们可以在 errcontext 的第一行报告查询或表达式。根据 Roger Mason 的抱怨。回溯补丁到 v14，因为（a）其中一些消息是 v14 中新增的，并且（b）v14 的可翻译字符串仍在变动中。当然，问题比这更老，但我犹豫是否要将行为更改回溯到更早的版本。讨论：https://postgr.es/m/1914708.1629474624@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/26ae66090398082c54ce046936fc41633dbfc41e

Álvaro Herrera 提交

  • 撤销对分区表的 ANALYZE 支持。这撤销了以下提交：1b5617eb844cd2470a334c1d2eec66cf9b39c41a 描述（自动）分区表的 ANALYZE 行为 0e69f705cc1a3df273b38c9883fb5765991e04fe 为分区表设置 pg_class.reltuples 41badeaba8beee7648ebe7923a41c04f1f3cb302 文档化分区表的 ANALYZE 存储参数 0827e8af70f4653ba17ed773f123a60eadd9f9c9 autovacuum：处理分区表的 ANALYZE。处理具有大量分区的数据库时，此代码存在效率问题，并且似乎没有简单的方法来处理这些问题。还有其他一些问题。现在距离周期结束太晚了，无法进行非简单的修复，因此我们将不得不让 Postgres 14 用户继续手动处理分区的 ANALYZE，并希望我们能在 Postgres 15 中修复这些问题。我保留了 [大部分] be280cdad298（“不对分区表上的 relhasindex 进行重置 ANALYZE”），因为虽然我们添加它是由于 0827e8af70f4，但它本身就是一个很好的 bug 修复，因为它既影响手动 ANALYZE，也影响 autovacuum 引起的 ANALYZE，而且没有理由撤销它。我保留了将 relkind 'p' 添加到 pg_stat_user_tables 中包含的表，因为撤销它需要 catversion 升级。此外，仅在 pg14 中，我保留了一个添加到 PgStat_TabStatEntry 的结构成员，以避免与现有统计文件不兼容。回溯补丁到 14。讨论：https://postgr.es/m/20210722205458.f2bug3z6qzxzpx2s@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/6f8127b7390119c21479f5ce495b7d2168930e82

Heikki Linnakangas 提交

Michael Meskes 已推送

Amit Kapila 提交

Andres Freund 提交

  • 取消设置 MyBEEntry，使 elog.c 对 pgstat_get_my_query_id() 的调用安全。以前，在关闭后期发生的日志消息可能会使用另一个后端的 PgBackendStatus（多用户）或 segfault（单用户），因为 pgstat_get_my_query_id() 对 !MyBEEntry 的检查没有过滤掉 pgstat_beshutdown_hook() 之后的用法。这在 4f0b0966c86 中变成了一个 bug，但在之前有点可疑。但鉴于 14 版本之前没有已知的问题情况，因此似乎不值得回溯到更早的版本。还修复了 e1025044 中引入的注释中的错误文件名。报告者：Andres Freund andres@anarazel.de 审阅者：Julien Rouhaud rjuju123@gmail.com 讨论：https://postgr.es/m/Julien Rouhaud rjuju123@gmail.com 回溯补丁：14- https://git.postgresql.org/pg/commitdiff/bed5eac2d50eb86a254861dcdea7b064d10c72cf

Peter Eisentraut 提交

David Rowley 提交