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

PostgreSQL 每周新闻 - 2021 年 5 月 16 日

发布于 2021-05-17，作者 PWN
PWN

PostgreSQL 每周新闻 - 2021 年 5 月 16 日

安全发布了 13.3、12.7、11.12、10.17 和 9.6.22。请尽快升级。9.6 系列将在 2021 年 11 月 11 日停止接收修复。请立即规划主版本升级。 https://postgresql.ac.cn/about/news/postgresql-133-127-1112-1017-and-9622-released-2210/

本周人物：https://postgresql.life/post/laurenz_albe/

五月 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Tom Lane 提交

  • 改进 pg_config_manual.h 中关于 USE_VALGRIND 的注释。这些注释给人一种 USE_VALGRIND 对 valgrind 测试并非真正重要的印象。但这却是错误的，正如我今天以艰难的方式学到的。讨论：https://postgr.es/m/512778.1620588546@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8dc3d68cbe676deb5e74d1b1b565f57fffaf107e

  • 防止数组下标计算中的整数溢出。虽然我们（大部分）小心地确保数组的维度足够大，不会导致整数溢出，但下界值通常没有被检查。这会导致下界 + 维度溢出整数的情况。看起来这对于数组读取来说是无害的，除了下标理论上超过 INT_MAX 的数组元素是无法访问的。但是，它会混淆各种数组赋值逻辑，可能导致内存损坏。通过添加检查来防止数组下界过大导致下界 + 维度溢出整数，从而修复此问题。（注意：这会导致不允许最后一个下标位置恰好是 INT_MAX 的情况。原则上我们可以允许这种情况，但有很多代码会计算下界 + 维度，并且需要进行调整。为了处理这个情况而花费的麻烦/风险似乎不值得。）在某种程度上独立于此，array_set_element() 在检查定长数组的下标时，对可能的溢出不谨慎，从而导致了内存损坏的另一种途径。这也进行了修复。安全：CVE-2021-32027 https://git.postgresql.org/pg/commitdiff/f02b9085ad2f6fefd9c5cdf85579cb9f0ff0f0ea

  • 修复 ON CONFLICT ... UPDATE tlists 中 resjunk 列的错误处理。在 ON CONFLICT ... UPDATE 列表中出现任何 resjunk 列是不寻常的，但在存在 MULTIEXPR_SUBLINK SubPlans 时可能会发生。如果发生这种情况，ON CONFLICT UPDATE 代码路径最终会存储包含额外 resjunk 列值的元组。短期内这相对无害，但如果向表中添加了新列，则这些值可能会变得可访问，如果它们与新列的数据类型不匹配，则可能导致故障。由于缺乏健全性检查，此事一直被忽略，包括：* 没有交叉检查传递给 heap_insert 或 heap_update 的元组是否与表行类型匹配。虽然以合理的成本完全检查这一点很困难，但我们可以轻松地添加断言，确保列数不多于预期。* execExprInterp.c 中的输出列赋值情况缺乏对输出列号的健全性检查，考虑到输入列号有很多断言检查，这似乎是一个疏忽。也在此处添加断言。* 我们未能将 nodeModifyTable 的 ExecCheckPlanOutput() 应用于 ON CONFLICT UPDATE tlist。这不会捕获此特定错误，因为该函数被设计为忽略 resjunk 列；但现在我们看到了这个错误，这似乎是一个严重的疏忽。在 HEAD 中，修复此问题的正确方法是使 ON CONFLICT UPDATE tlist 的处理与常规 UPDATE tlist 的处理方式相同，即不添加“SET x = x”条目，并使用 ExecBuildUpdateProjection 来评估 tlist 并将其与未设置列的旧值合并。这给 ExecBuildUpdateProjection 增加了一些复杂性，但允许从规划器中移除可比较数量的现已失效代码。在后端分支中，最快捷的解决方案似乎是（a）使用一个与目标表匹配的 ON CONFLICT UPDATE 投影输出槽，然后（b）发明一个 ExecBuildProjectionInfo 的变体，可以被告知不存储 resjunk 列计算出的值，这样它就不会尝试存储到输出槽的非存在列中。（我们不能完全忽略 resjunk 列；它们必须被评估才能使 MULTIEXPR_SUBLINK 工作。）这适用于 v10。在 9.6 中，投影的工作方式大不相同，我们无法轻易地给它们提供这样的选项。9.6 版本的此补丁通过插入 JunkFilter 来在必要时删除 resjunk 列。此外，v11 及更高版本在尝试对分区表执行 ON CONFLICT UPDATE 时存在反向问题。由于进一步的疏忽，adjust_partition_tlist() 在重新排序 ON CONFLICT UPDATE tlist 以匹配分区时丢弃了 resjunk 列。这意外地阻止了存储错误元组的问题，但代价是 MULTIEXPR_SUBLINK 情况不起作用，通常会导致更新多行时崩溃。通过在此例程中保留 resjunk 列来修复。（我未能抵制在此处添加更多断言的诱惑，并进行了一些小的代码美化。）据 Andres Freund 报告。向所有支持的分支进行回溯。安全：CVE-2021-32028 https://git.postgresql.org/pg/commitdiff/049e1e2edb06854d7cd9460c22516efaa165fbf8

  • 用 C 代码替换 opr_sanity 测试的 binary_coercible() 函数。opr_sanity 的 binary_coercible() 函数一直旨在匹配解析器的二进制可强制性概念，但它也一直是对解析器实际规则（如 IsBinaryCoercible() 所体现的）的一个相当糟糕的近似。到目前为止还没有出现问题，但可以预见它最终会出现。现在还发现，在 plpgsql 中实现此检查在 clobber-cache-always 测试中表现非常糟糕。（也许我们可以对此做些什么，但我怀疑这只是意味着 plpgsql 在充分利用目录缓存。）因此，让我们用一个 C 包装器替换 binary_coercible()，它直接调用 IsBinaryCoercible()，从而消除了语义风险和性能问题。regress.c 中的大多数 C 函数都声明在 create_function_1 中，但我们不能简单地将其移到 opr_sanity/type_sanity 之前，因为这些测试会抱怨由此产生的 shell 类型。我选择将其拆分为 create_function_0 和 create_function_1。由于 create_function_0 现在作为并行组的一部分运行，而 create_function_1 不运行，因此将后者缩减为仅创建 opr_sanity 和 type_sanity 会抱怨的那些函数。为了在第二个并行测试组中为 create_function_0 腾出空间，将 tstypes 移到第三个并行组。顺便，清理一下 parallel_schedule 和 serial_schedule 之间的一些顺序偏差。讨论：https://postgr.es/m/292305.1620503097@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6303a5730914dfe6ef2709b28b225553315c573c

  • 取消单独的 serial_schedule 测试列表。维护两个回归测试脚本列表已被证明容易出错。通过以 "--max_connections=1" 运行 parallel_schedule，我们可以实现 serial_schedule 的效果；因此，执行此操作并删除 serial_schedule。这会导致进度输出的一些细微差别，但似乎不值得重构 pg_regress 来避免这种情况。讨论：https://postgr.es/m/899209.1620759506@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/1df3555acc78dedc3ca25eb5e83649b3da1f298f

  • 修复 vcregress.pl 中 --max-connections 的旧拼写错误。我复制了现有的 "--max_connections" 拼写，但那是错误的 :-(\n显然，在此脚本中设置 $ENV{MAX_CONNECTIONS} 实际上从未起作用。鉴于没有收到抱怨，可能不值得回溯修复。据 buildfarm 报告。讨论：https://postgr.es/m/899209.1620759506@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0b85fa93e4575183aa5a71ebe3c6bae8d97704ed

  • 缩短 CLOBBER_CACHE_ALWAYS 下 privileges.sql 测试的运行时间。privileges 回归测试中的一些查询会导致规划器将 plpgsql 函数 "leak()" 应用于 atest12.b 的直方图的每个元素。自 commit 0c882e52a 将该直方图的大小增加到 10000 个条目以来，该测试会调用该函数超过 100000 次，这在 clobber-cache-always 模式下需要不合理的时间。然而，没有真正的原因表明这必须是一个 plpgsql 函数：就该测试而言，唯一重要的是它不被标记为 leakproof。因此，我们可以用对 int4lt 的直接调用替换 plpgsql 实现，它具有相同的行为并且速度快几个数量级。预计这将缩短 CCA 动物的 buildfarm 周期时间几个小时。它在正常构建中也有一些积极影响，尽管那可能已经消失在噪声中了。回溯到 v13，其中 0c882e52a 已提交。讨论：https://postgr.es/m/575884.1620626638@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e135743ef07ea59088d09c459f41ee2eaabe95c3

  • v14 的初始 pgindent 和 pgperltidy 运行。也运行 "make reformat-dat-files"。唯一值得注意的改变是 pgindent 弄乱了 launcher.c 的 struct LogicalRepWorkerId 的格式，这让我注意到该结构体不再被使用，所以我就把它删除了。 https://git.postgresql.org/pg/commitdiff/def5b065ff22a16a80084587613599fe15627213

  • 对目录数据执行发布前清理。运行 renumber_oids.pl 来移动高编号的 OID，按照 RELEASE_CHANGES 中指定的 beta 前任务。供参考，命令是 ./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6150 https://git.postgresql.org/pg/commitdiff/14472442861ca95cc9158518acdedf740c4bff55

  • 文档：更新 bki.sgml 中关于 OID 范围的陈述。Commit ab596105b 忽略了使文档与代码匹配。 https://git.postgresql.org/pg/commitdiff/1f9b0e6938054515b8c9df545437c3d347eed683

  • 在 system_constraints.sql/system_functions.sql 中将命令双倍空格化。以前，后端在读取 system_constraints.sql 时报告的任何错误都会报告整个文件，而不仅仅是它正在处理的特定命令。（问问我怎么知道的。）同样，system_functions.sql 的某些部分将被读取为一个命令，如果在那里出现任何失败，那将是令人恼火的。system_constraints.sql 的问题是 commit dfb75e478 中的疏忽。我没有试图追溯 system_functions.sql 中糟糕格式的来源，但它肯定与该文件开头的建议相悖。 https://git.postgresql.org/pg/commitdiff/7dde98728a2ef6d48ef397ee783dd130fdb34e6b

  • 重构 CHECK_FOR_INTERRUPTS() 以增加灵活性。拆分 CHECK_FOR_INTERRUPTS() 以提供一个额外的宏 INTERRUPTS_PENDING_CONDITION()，它仅测试中断是否挂起而不尝试服务它。这在调用者知道中断被阻塞，并希望了解是否值得解除阻塞的情况下很有用。还添加了 INTERRUPTS_CAN_BE_PROCESSED()，它指示是否可以依赖 CHECK_FOR_INTERRUPTS() 来清除挂起的中断。此提交实际上并未添加对新宏的任何使用，但后续的错误修复将这样做。回溯到所有支持的分支，以提供该修复的基础设施。Alvaro Herrera 和 Tom Lane 讨论：https://postgr.es/m/20210513155351.GA7848@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/e47f93f981ccb70b4c4c5a0966e5fa0400e11a7e

  • 修复 spgdoinsert() 中的查询取消处理。知道有缺陷的 opclass 可能导致无限插入循环，spgdoinsert() 旨在允许通过查询取消来中断其循环。然而，这实际上从未奏效，因为在第一次迭代之后，我们将持有缓冲区锁，这会导致 InterruptHoldoffCount 为正，从而阻止中断被服务。为了修复，检查是否挂起中断，如果是，则退出插入循环并在释放缓冲区后服务中断。如果确实是查询取消，那么问题就解决了。如果是非取消中断原因，则利用现有机制重试整个插入。（这不像听起来那么浪费，因为我们已经创建的任何上层索引元组都可以在下一次尝试中使用。）虽然在现有发布分支中没有已知的此类错误实例，但将其回溯到所有支持的分支仍然是一个好主意，因为如果发生循环，行为非常糟糕——不仅不可取消，而且会迅速消耗内存直到发生 OOM 故障。无论如何，这段代码肯定没有按预期工作。据 Dilip Kumar 报告。讨论：https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/eb7a6b9229432dcb791f4bf0c44fe97bab661134

  • 防止 spgdoinsert() 中的无限插入循环。以前我们只是依赖断言 longValuesOK 的操作符类最终会缩短叶值以适应索引页。这自 INCLUDE 列支持（commit 09c1c6ab4）引入以来就失败了，因为 INCLUDE 列本身就可能占用一个页面以上，这意味着无论如何压缩叶子数据都无法完成。至少在 spgtextproc.c 中，这会导致无限循环，因为 spgtextproc.c 不再抛出无法缩短叶子数据的错误。为了修复此问题而不破坏其他可以正常工作的场景，在 spgdoinsert() 中添加逻辑，以验证叶元组大小在每次“选择”步骤后都在减小。某些 opclass 可能不会在每个周期都减小大小，而且在这种情况下，元组大小的对齐舍入可能会掩盖微小的增益。因此，允许最多 10 个周期没有额外的节省，然后再抛出错误。（也许这个数字需要调整，但目前看起来相当慷慨。）既然我们已经开发了此逻辑，让我们将其回溯。回溯分支不需要担心 INCLUDE 列，但这似乎是对操作符类中可能存在的错误的良好防御。我们已经知道这里的无限循环相当令人不快，所以有防御措施似乎 outweighs 破坏东西的风险。（请注意，spgtextproc.c 实际上是唯一已知具有 longValuesOK 支持的 opclass，因此对于已知的非核心 opclass 来说，这一切都无关紧要。）据 Dilip Kumar 报告。讨论：https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c3c35a733c77b298d3cf7e7de2eeb4aea540a631

  • 释放 BackgroundWorkerSlots 时更小心地处理屏障。ForgetBackgroundWorker 完全没有内存屏障，而 BackgroundWorkerStateChange 有一个但不明不白地在屏障之后对槽进行了额外的操作。据我所知，规则必须是屏障紧接在设置或清除 slot->in_use 之前。看起来早在 9.6 中 ForgetBackgroundWorker 首次编写时，可能有一些理由不需要在那里设置屏障，但我对此并不十分确定——bgw_notify_pid 的加载在调用者中似乎不能保证没有内存排序问题。因此，也修补了 9.6。这可能不会修复 Intel 硬件上的任何可见错误，但内存排序规则较弱的机器可能会在这里出现问题。讨论：https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/30d8bad494ad1f604295033e4f4de4b8f258fe74

Michaël Paquier 提交

Thomas Munro 推送

Bruce Momjian 已推送

Peter Eisentraut 提交

David Rowley 提交

Andrew Dunstan 推送

Fujii Masao 提交

Etsuro Fujita 推送

  • 修复 async-能力节点的 EXPLAIN ANALYZE。与 postgres_fdw 关联的 async-能力 ForeignScan 节点的 EXPLAIN ANALYZE 仅通过使用从节点回调调用的 ExecProcNode() 的内省来实现，导致以下问题：1) 如果扫描的远程表为空，则即使命令执行了该节点，该节点仍被错误地视为 "从未执行"，因为在这种情况下根本不会从节点的回调中调用 ExecProcNode()。2) 该命令无法收集除节点中完成的 ExecProcNode() 之外的计时信息，例如为节点远程查询创建游标。为了解决这些问题，为 async-能力节点添加了内省，并相应地修改了 postgres_fdw。是我在 commit 27e1f1456 中的疏忽。同时，更新 execnodes.h 中 AsyncRequest 结构体的注释以及 fdwhandler.sgml 中 ForeignAsyncRequest API 的文档，以匹配 nodeAppend.c 中 ExecAsyncAppendResponse() 的代码，并修复 nodeAppend.c 中注释的拼写错误。据 Andrey Lepikhov 报告，尽管我没有使用他的补丁。评审者：Andrey Lepikhov 讨论：https://postgr.es/m/2eb662bb-105d-fc20-7412-2f027cc3ca72%40postgrespro.ru https://git.postgresql.org/pg/commitdiff/a363bc6da96b14d27e1cae1bae97242eb6ade5e6

  • 防止直接 foreign-table 修改的异步执行。Commit 27e1f1456 和 86dc90056（已独立讨论）在启用异步执行的情况下执行继承的 foreign UPDATE/DELETE 查询时会导致崩溃，其中 Append 节点的子节点是 ModifyTable 节点的直接/间接子节点，这些子节点通过 postgresPlanDirectModify() 被重写，以直接修改 foreign 表；因为在这种情况下，直接修改是异步执行的，而这目前不被异步执行支持。通过在该函数中禁用直接修改的异步执行来修复。作者：Etsuro Fujita 评审者：Amit Langote 讨论：https://postgr.es/m/CAPmGK158e9sJOfuWxfn%2B0ynrspXQU3JhNjSCbaoeSzMvnga%2Bbw%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/a784859f4480ceaa05a00ca35311071ca33483d1

Álvaro Herrera 提交

Amit Kapila 提交

Alexander Korotkov 提交了

Peter Geoghegan 提交

待处理补丁

Amit Langote 发送了另一个版本的补丁，允许在跨分区更新期间批处理插入。

Nitin Jadhav 发送了一个补丁，以匹配 src/backend/utils/activity/backend_status.c 中注释中的文件路径与实际文件路径。

Bharath Rupireddy 发送了一个补丁，以使 PostgreSQL FDW 缓存连接函数测试有意义。

Thomas Munro 发送了一个补丁，用于清除 HASH_REMOVE 释放的内存，并避免在释放本地锁后访问它们。

Andres Freund 发送了一个补丁，用于在 walreceiver 中将部分页面清零。

Peter Smith 发送了一个补丁，以确保 GetSubscriptionRelations 只声明 1 个扫描键。

Vigneshwaran C 发送了三个额外版本的补丁，以在逻辑复制消息描述中包含实际使用的数据类型。

Tang 发送了三个额外版本的补丁，以使 psql 中 DELETE FORM 和 INSERT INTO 的制表符补全保持一致。

Vigneshwaran C 发送了三个额外版本的补丁，以使错误消息更清晰地说明实际错误。

Kyotaro HORIGUCHI 发送了两个额外版本的补丁，以根据 recoveryTargetTLI 正确设置 expectedTLEs。

Etsuro Fujita 发送了另一个版本的补丁，以修复 async 能力节点的 EXPLAIN ANALYZE。

Hou Zhijie 发送了另一个版本的补丁，用于在 fmgr_info 中检查 UDF 并行安全性，修复测试用例中的 UDF 并行安全性标签，在 fmgr_info 中检查内置函数的并行安全性，并修复测试用例中的内置函数并行安全性标签。

Honza Horak 发送了一个补丁，用于修复 Python 3.10 的子事务测试。

Masahiko Sawada 发送了另一个版本的补丁，用于为外部事务引入事务管理器，并使用它来处理涉及它们的两阶段提交。

Masahiro Ikeda 发送了两个额外版本的补丁，以提高报告 wal 统计信息的性能。

Hou Zhijie 发送了两个额外版本的补丁，用于使用户能够声明表允许并行数据修改，启用并行插入选择，实现一个实用函数 pg_get_parallel_safety(regclass)，该函数返回表示对象并行安全性的 (objid, classid, parallel_safety) 记录，这些对象决定了指定表的并行安全性，并更新回归测试以包含相同的内容。

Pavel Stěhule 发送了两个额外版本的补丁，用于实现模式变量。

Pavel Stěhule 发送了另一个版本的补丁，以便 pg_dump 可以从文件中读取表名。

Pavel Stěhule 发送了另一个版本的补丁，以便为 psql 中的 \watch 指定一个单独的分页器。

Zeng Wenjing 发送了另一个版本的补丁，用于实现全局临时表。

Tom Lane 发送了另一个版本的补丁，用于将 pg_depend PIN 条目替换为固定范围检查。

Atsushi Torikoshi 发送了一个补丁，用于添加一个 pg_log_current_plan(pid) 函数，该函数允许人们获取当前正在执行的查询的计划。

Mark Dilger 发送了另一个版本的补丁，用于将 GUC 变量的设置委托给一些新创建的角色。

Michail Nikolaev 发送了两个额外版本的补丁，用于为主备机添加对索引 LP_DEAD 提示位的完整支持。

Amul Sul 发送了两个额外版本的补丁，用于实现 ALTER DATABASE READ {ONLY | WRITE}。

Vigneshwaran C 和 Bharath Rupireddy 交换了补丁，以澄清 ALTER SUBSCRIPTION ... DROP PUBLICATION 的消息和文档。

Ranier Vilela 发送了一个补丁，用于修复 src/backend/commands/tablecmds.c 中显式的 NULL 指针解引用。

Michaël Paquier 发送了一个补丁，用于添加一个 vacuum_cleanup_index_scale_factor GUC。

Vigneshwaran C 发送了两个版本的补丁，旨在修复一个表现为文本消息失败的错误，通过检查 pg_replication_slot 中的 active 列而不是 pg_stat_replication，pg_replication_slot 测试更可靠。

Bharath Rupireddy 发送了一个补丁，用于重写并行 VACUUM 的错误消息和文档。

Nathan Bossart 发送了一个补丁，允许在 pg_hba.conf 中指定直接角色成员资格。

Peter Smith 和 Ajin Cherian 交换了补丁，以支持对两阶段事务进行逻辑解码。

Peter Geoghegan 发送了一个补丁，用于在 vacuumlazy.c 的第一次扫描期间考虑触发故障安全机制。

Amit Langote 发送了一个补丁，用于修复 pgoutput tupeconv 映射泄漏。

Kyotaro HORIGUCHI 发送了一个补丁，用于匹配关于大括号的错误及其名称。

Vigneshwaran C 发送了三个版本的补丁，以在 psql 中为 ALTER SUBSCRIPTION SET 选项 streaming 和 binary 添加制表符补全。

Ranier Vilela 发送了两个版本的补丁，用于修复 src/timezone/zic 中可能的内存损坏。

Michaël Paquier 发送了另一个版本的补丁，用于将 pg_upgrade 的测试重写为 TAP 测试。

Nitin Jadhav 和 Justin Pryzby 交换了补丁，用于从 create_list_bounds 中移除额外的内存分配，将 PartitionListValue 和 create_hash_bounds PartitionHashBound 分配为单个块，批量分配 datum 数组以避免 palloc 开销，并在 create_range_bounds 中 pfree() 中间结果。

Tom Lane 发送了两个版本的补丁，旨在修复一个表现为 prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619 的错误。

Tatsuo Ishii 发送了两个版本的补丁，用于修复 README.barrier 中的拼写错误。

Nitin Jadhav 发送了一个补丁，用于支持 to_char() 中的 tzh_tzm 模式。