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

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

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

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

本周人物

PostgreSQL 产品新闻

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

八月份的 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_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 清理，因为它最初没有像 SCRAM 使用的 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_is_valid 从未使用过，但在检查的第一个位置仍然检查结果值是否为 0。这类似于 607f8ce。btree_gist 只是复制粘贴了 backend 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'd 而不是完全删除它们。顺便说一句，添加一些测试用例以改进这方面的代码覆盖率，以及 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 更改扩展成员关系。如果在扩展更新脚本期间对预先存在的、独立的自由对象调用 recordDependencyOnCurrentExtension，则该对象将归扩展所有。在我们当前的代码中，这在三种情况下是可能的：* 替换“shell”类型或运算符。* CREATE OR REPLACE 覆盖现有对象。* ALTER TYPE SET、ALTER DOMAIN SET 和 ALTER OPERATOR SET。第一种情况是预期的行为，如 GenerateTypeDependencies 的现有注释所述。对于 CREATE OR REPLACE 来说，这似乎也是合适的行为；至少，显而易见的其他替代方案并不更好。然而，它在 ALTER 期间发生的事实是尝试在 CREATE 和 ALTER 情况之间共享代码（GenerateTypeDependencies 和 makeOperatorDependencies）的结果。由于扩展脚本不太可能 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 对聚合 FILTER 子句的检查。递归到 FILTER 子句的实现不正确，导致忽略了 FILTER 子句顶部的相关 Var 或 Aggref。（当然，那必须是一个普通的布尔 Var 或返回布尔值的聚合。）其结果是错误地识别聚合的正确语义级别，这可能导致不符合规范的查询行为。如果 FILTER 表达式是聚合，这还可能导致无法发出预期的“聚合函数调用不能嵌套”错误，这很可能会在稍后导致核心转储，因为规划器和执行器不希望出现这种情况。根本原因是提交 b560ec1b0 盲目地复制了一些代码，这些代码假设它正在递归到一个 List，因此没有检查顶层节点。为了避免出现关于为什么此调用看起来与其他调用不同的问题，以及未来可能出现的复制粘贴错误，让我们更改 check_agg_arguments 中所有三个 check_agg_arguments_walker 调用，即使只有 filter 子句的调用真正被破坏了。根据 Zhiyong Wu 的 bug #17152。自从我们实现 FILTER 以来，这个问题就一直是错误的，因此回溯到所有支持的版本。（测试表明，由于 ExecInitAgg 中“冗余”检查，v11 之前的分支设法避免了在错误的 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。这会导致稍后出现奇怪的错误甚至崩溃。这个错误非常古老，但是没有人注意到并不奇怪，因为在非视图规则中使用 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 中的性能错误。在检测到迭代节点的第 i 个子匹配项中的子匹配项“解剖”失败（即，反向引用匹配失败）后，我们应该通过调整第 i 个子匹配项的尝试长度来继续。但是，按照编码的方式，这些函数更改了最后一个子匹配项的尝试长度，只有在耗尽该长度的所有可能性后，它们才会后退以调整倒数第二个子匹配项，然后是倒数第二个，等等；所有这些都是浪费精力，因为只有更改第 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 推送

  • 恢复对分区表的支持分析。这将恢复以下提交： 1b5617eb844cd2470a334c1d2eec66cf9b39c41a 描述分区表的（自动）分析行为 0e69f705cc1a3df273b38c9883fb5765991e04fe 设置分区表的 pg_class.reltuples 41badeaba8beee7648ebe7923a41c04f1f3cb302 文档分区表的 ANALYZE 存储参数 0827e8af70f4653ba17ed773f123a60eadd9f9c9 自动清理：处理分区表的分析 此代码在处理具有大量分区的数据库时存在效率问题，并且看起来没有简单的处理方法。还有其他一些问题。现在对于重要的修复来说，周期太晚了，因此我们必须让 Postgres 14 用户继续手动处理他们分区表的 ANALYZE，并希望我们可以修复 Postgres 15 的问题。我保留了 [大多数] be280cdad298（“不要在 ANALYZE 上重置分区表的 relhasindex”），因为虽然我们由于 0827e8af70f4 添加了它，但它本身就是一个很好的错误修复，因为它会影响手动分析以及自动清理引起的分析，并且没有理由恢复它。我保留了向 pg_stat_user_tables 包含的表中添加 relkind 'p'，因为恢复它需要 catversion 升级。此外，在 pg14 中，我保留了添加到 PgStat_TabStatEntry 的结构成员，以避免破坏与现有 stat 文件的兼容性。回溯到 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（多用户）或段错误（单用户），因为 pgstat_get_my_query_id() 对 !MyBEEntry 的检查没有过滤掉 pgstat_beshutdown_hook() 后的使用。这在 4f0b0966c86 中成为一个错误，但之前有点可疑。但是，考虑到在 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 推送了