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

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

发布于 2021-11-23，作者 PWN
PWN

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

2022 Nordic PGDay 将于2022年3月22日在芬兰赫尔辛基的希尔顿赫尔辛基斯特兰德酒店举行。论文征集（CfP）将于2021年12月31日截止，请 在此 提交。

PostgreSQL 产品新闻

PGroonga 2.3.4，一个支持所有语言的全文本搜索平台，已发布。

Pgpool-II 4.2.6、4.1.9、4.0.16、3.7.21 和 3.6.28，一个用于 PostgreSQL 的连接池和语句复制系统，已 发 布 了。

Ora2Pg 23.0，一个用于将 Oracle 数据库迁移到 PostgreSQL 的工具，已发布。https://github.com/darold/ora2pg/blob/master/changelog

BigAnimal，Azure 上的托管 PostgreSQL 数据库，已发布。

pgAdmin4 6.2，一个用于 PostgreSQL 的 Web 和本地 GUI 控制中心，已发布。

11月 PostgreSQL 工作机会

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Robert Haas 提交

Amit Kapila 提交

Álvaro Herrera 提交

Michaël Paquier 提交

Peter Eisentraut 提交

Daniel Gustafsson 提交

Tom Lane 提交

  • 修复 INSERT/SELECT 中 SQL 标准函数的参数显示。如果 SQL 标准函数体包含 INSERT ... SELECT 语句，则 SELECT 中引用的任何函数参数始终以 $N 样式打印，而不是使用参数名称（如果存在）。虽然不是严格错误，但这并非预期，并且与在任何其他类型的语句中打印此类参数的方式不一致。原因是 get_query_def 从 get_insert_query_def 递归调用时，未能向下传递 context->namespaces 列表，而是传递了常量 NIL。这是一个非常古老的疏忽，但据我所知，在提交 e717a9a18 添加具有函数参数的最外层命名空间之前，它没有可见的影响。我们不允许 INSERT ... SELECT 作为子查询，除非在顶层 WITH 子句中，在这种情况下，它不能包含任何可能需要访问上层命名空间的外部引用。因此，虽然这可能是一个错误，但在此之前更改它似乎没有意义。顺便，加固 e717a9a18 添加的代码，使其不会在 PARAM_EXTERN Param 出现在意外位置时崩溃。来自 Erki Eessaar 的报告。代码修复：我，回归测试用例：Masahiko Sawada。讨论：https://postgr.es/m/AM9PR01MB8268347BED344848555167FAFE949@AM9PR01MB8268.eurprd01.prod.exchangelabs.com https://git.postgresql.org/pg/commitdiff/a8d8445a7b2f80f6d0bfe97b19f90bd2cbef8759

  • 在 pg_dump 和 pg_basebackup 中更健壮地处理 close() 失败。Coverity 抱怨说，在 pg_basebackup 的一个地方，在失败的 gzclose 后应用 get_gz_error 是不安全的。我认为它是正确的：该调用非常可能在触摸已释放的内存。将其更改为检查 errno，就像我们对其他 gzclose 调用所做的那样。此外，请务必在任何我们关心的错误状态的 gzclose() 调用之前立即将 errno 初始化为零。（有些调用我们不关心，因为我们在之前的步骤中已经失败了。）这可以确保在 gzclose() 失败但未设置 errno 时，我们不会得到误导性的无关错误代码。我们可以更努力地做到这一点，但对我来说，如果我们不滥用 zlib，所有这些情况基本上都是不可能发生的，所以不值得额外的注释。此外，修复了几个根本没有检查关闭时错误的地点，大多数都在关闭或 gzclose 本身之外；还有一个地方检查了但没有报告 errno。向后移植到 v12。这些错误比这更老，但由于 v12 中发生的客户端日志 API 更改以及客户端代码在此之前不能依赖 %m 的事实，补丁需要大量修改才能在旧分支上工作。考虑到缺乏相关的现场投诉，这样做似乎不值得。补丁作者：我；感谢 Michael Paquier 的审阅。讨论：https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3cac2c8caaefc642332e6994ce80032cc7d4cfdf

  • 清理 pg_basebackup 的 walmethods.c 中的错误处理。这里的错误处理很混乱，原因是一个根本性的糟糕设计（依赖 errno 保持其值比假设的安全时间长得多），以及很多纯粹的疏忽，包括根本注意不到错误以及报告不正确的 errno。此外，最近添加的 LZ4 压缩完全破坏了事情，因为 liblz4 不使用 errno 来报告错误。为了改善这一点，将错误状态保存在 DirectoryMethodData 或 TarMethodData 结构中，并添加一个字符串字段，以便我们能够处理不设置 errno 的情况。（tar 方法已经有了这个的版本，但可以更有效地完成，因为所有这些情况都使用恒定的错误字符串。）使 dir 和 tar 方法以基本相同的方式处理错误，而以前不是。这需要在许多地方将 errno 复制到状态结构中，这有点乏味，但优点是我们可以在许多地方摆脱保存和恢复 errno 的临时代码……更不用说它修复了其他本应保存/恢复 errno 但忽略了的地方。顺便，修复了一些无用地 static 的缓冲区为普通的局部变量。fsync() 的错误处理仍然存在一个问题，但这似乎是另一个补丁的材料。虽然 LZ4 问题是新的，但其余的都是针对旧错误的修复，所以向后移植到引入 walmethods.c 的 v10。补丁作者：我；感谢 Michael Paquier 的审阅。讨论：https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/248c3a937dd018a72095f407cff727c9f08db0c1

  • 为 starts_with() 添加一个规划器支持函数。这填补了规划器对 starts_with() 和等效的 ^@ 运算符的一些支持空白：* 诸如 "textcol ^@ constant" 这样的条件现在可以使用常规的 btree 索引，而不仅仅是 SP-GiST 索引，只要索引的排序规则是 C。（这就像 "textcol LIKE 'foo%'" 一样。）* "starts_with(textcol, constant)" 可以像 "textcol ^@ constant" 一样进行优化。* 固定前缀 LIKE 和正则表达式模式在其他方面也更像 starts_with()：如果你将其应用于 SPGiST 索引的列，你将获得一个使用 ^@ 的索引条件，而不是两个带有 >= 和 < 的索引条件。按 Shay Rojansky 的投诉。补丁作者：我；感谢 Nathan Bossart 的审阅。讨论：https://postgr.es/m/232599.1633800229@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/a148f8bc04b9980f019ea0d4b89311cf0bdc22b7

  • 提供一个 simple_prompt() 的变体，可以被 ^C 中断。到目前为止，你无法通过键入 control-C（或 SIGINT 的其他本地拼写）来逃脱 psql 的 \password 命令。这很不用户友好，所以改进它。要做到这一点，我们必须修改 pg_get_line.c 提供的函数；但我们不想干扰 psql 的 SIGINT 处理程序设置，所以提供一个 API，让该处理程序可以触发取消。这依赖于我们不会通过 longjmp() 退出 fgets() 来造成重大损害的假设。虽然这显然有点不可靠，但我们在主输入循环中早已有了同样的假设，并且报告的错误很少。psql 还有一些其他 simple_prompt() 调用也可能需要改进，但目前只处理 \password。作者：Nathan Bossart，我进行了一些小的调整。讨论：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5f1148224bd78bcf3bf7d916b8fe85dd820c52c6

  • 编译 bitcode 时使用适当的 -Wno-warning 开关。我们使用 "clang" 来编译 LLVM 位码文件以进行内联。这可能与构建的主 C 编译器不同，因此它需要自己的一组编译器标志。为了简化配置，我们不费心将任何 -W 开关添加到该标志集中；因为主构建会向我们显示任何警告，所以几乎不需要。但是，如果我们不想看到不必要的警告，我们仍然必须添加我们通常与 clang 一起使用的任何 -Wno-warning 开关。在提交 9ff47ea41 之前，这被忽略了，该提交试图添加 -Wno-compound-token-split-by-macro；使用不匹配的 CC 和 CLANG 的构建农场动物仍然显示这些警告。我不确定为什么我们从未注意到缺少 -Wno-unused-command-line-argument 的影响（也许它只在 -Wall? 激活）。clang 目前不支持 -Wno-format-truncation 或 -Wno-stringop-truncation，尽管为了未来的兼容性和一致性，我包含了这些测试。向后移植到 v11，在那里我们开始构建位码文件。讨论：https://postgr.es/m/2921539.1637254619@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/276517a96484f9e39a7a1095ab39fa76ef1ee8cc

  • 允许 psql 的其他 uses of simple_prompt() 被 ^C 中断。这完成了 5f1148224 未完成的工作。\prompt 现在可以被取消，并且 \connect 在启动时发出的密码提示也可以被取消。（我们不需要为启动时发出的密码提示做任何事情，因为那时我们还没有捕获 SIGINT。）作者：Nathan Bossart 讨论：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/46d665bc26ce57b5afecbc218c8fc3c6848211d8

  • 修复 SP-GiST 扫描初始化逻辑以适应二进制兼容情况。Commit ac9099fc1 重新排列了 spgGetCache() 中的逻辑，该逻辑确定索引的 attType（名义输入数据类型）和 leafType（存储在叶索引元组中的实际类型）。事实证明，这破坏了以下情况：(a) 实际输入数据类型与名义类型不同，(b) opclass 的配置函数将 leafType 留空，并且 (c) opclass 没有 "compress" 函数。（b）导致我们将实际输入数据类型分配为 leafType，然后因为这不等于 attType，所以我们抱怨需要 "compress" 函数。对于非多态 opclasses，情况 (a) 出现在二进制兼容的情况下，例如对 varchar 列使用 SP-GiST text_ops，或对域使用任何 opclass（基于其名义输入类型）。为了修复，当索引声明的列类型与 attType 不同但二进制兼容时，使用 attType 作为 leafType。仅在 leafType 留空的情况下这样做，以避免覆盖 opclass 做的任何显式选择。按 Ilya Anfimov 的 bug #17294。向后移植到 v14。讨论：https://postgr.es/m/17294-8f6c7962ce877edc@postgresql.org https://git.postgresql.org/pg/commitdiff/f4e7ae2b8a67ad6801726553a024a3306716ef80

  • 文档：更新与最小 Test::More 版本相关的某些内容。Commit 405f32fc4 中的疏忽。此外，添加一个（艰难发现的）技巧，关于如何在最新的 Linux 平台上让 Test::More 0.98 通过其回归测试。https://git.postgresql.org/pg/commitdiff/92e70796e91e2f9086fad0156e0e91513e54a66b

  • pg_receivewal, pg_recvlogical：允许取消初始密码提示。以前，不可能通过 control-C 在这些程序提示输入密码时终止它们。我们可以通过将 SIGINT 处理程序的设置从初始 GetConnection() 调用之前移到之后来轻松修复它们的初始密码提示。此修复程序不允许逃脱后续的重新提示，但这些提示应该极其罕见，因为在此期间用户的密码或服务器的身份验证设置可能会发生变化。我们曾考虑应用一个类似于 commit 46d665bc2 的修复程序，但这似乎比其价值更复杂。此外，这种方式可以向后移植，而那种不行。此行为存在于所有支持的版本中，因此向后移植到所有版本。作者：Tom Lane 和 Nathan Bossart 讨论：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/282b6d00abf5cebece6f94c796a4ed807a0176db

Andres Freund 提交

Andrew Dunstan 推送