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

PostgreSQL 每周新闻 - 2021 年 9 月 12 日

发布于 2021-09-13，作者：PWN
PWN

PostgreSQL 每周新闻 - 2021 年 9 月 12 日

PostgreSQL 产品新闻

pg_dumpbinary 2.5，一个用于以二进制格式转储 PostgreSQL 数据库的程序，已发布。

pgBadger v11.6，一个用 Perl 编写的 PostgreSQL 日志分析器和图表工具，已发布。

[pgagroal 1.3.0，一个高性能的协议原生连接池，用于 PostgreSQL，已发布

九月 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Michaël Paquier 提交

Peter Eisentraut 提交

Fujii Masao 提交

  • 修复注释中的拼写错误。作者：Hou Zhijie 讨论：https://postgr.es/m/OS0PR01MB5716E6A6535FDFDC5A1B004194CE9@OS0PR01MB5716.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/78aa616be74a13156f4fc8db3a131f1fdc2cce47

  • postgres_fdw：允许通过 GUC 设置远程连接的 application_name。此提交添加了 postgres_fdw.application_name GUC，用于指定 postgres_fdw 建立到远程服务器的连接时使用的 application_name 配置参数的值。此 GUC 设置始终覆盖远程服务器对象的 application_name 选项。当我们需要为每个远程连接指定自己的 application_name 时，此 GUC 非常有用。以前，远程连接的 application_name 基本只能通过服务器对象的选项进行设置。但这意味着连接到同一远程服务器的每个会话基本上都必须使用相同的 application_name。而且，如果我们想更改设置，我们必须执行“ALTER SERVER ... OPTIONS ...”命令。这很不方便。作者：Hayato Kuroda 审查者：Masahiro Ikeda, Fujii Masao 讨论：https://postgr.es/m/TYCPR01MB5870D1E8B949DAF6D3B84E02F5F29@TYCPR01MB5870.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/449ab6350526e99d33363706b759951ebad7928e

  • postgres_fdw：回滚 postgres_fdw.application_name 的不稳定测试。提交 449ab63505 添加了检查 postgres_fdw.application_name GUC 是否按预期工作的测试。但它们不稳定，导致一些 buildfarm 成员报告失败。此提交回滚了这些不稳定的测试。报告人：Tom Lane（根据 buildfarm）讨论：https://postgr.es/m/3220909.1631054766@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/98dbef90eb29b13079ba3bd260b3c5818904ee86

  • 修复备用服务器 WAL 归档问题。以前，walreceiver 在完成当前 WAL 段的写入并接收任何应写入下一段的 WAL 数据后，总是会关闭当前打开的 WAL 段并创建其归档通知文件。如果 walreceiver 在下一段中的任何 WAL 数据到达备用服务器之前退出，它将不会为当前段创建归档通知文件，即使该段已知已完成。此行为可能导致该段的 WAL 归档延迟到后续的 restartpoints 或 checkpoints 创建其通知文件。为解决此问题，此提交更改了 walreceiver，使其在当前 WAL 段已知完成后立即创建归档通知文件，并在接收下一段 WAL 数据之前。向所有支持的分支回填。报告人：Kyotaro Horiguchi 作者：Fujii Masao 审查者：Kyotaro Horiguchi 讨论：https://postgr.es/m/20200630.165503.1465894182551545886.horikyota.ntt@gmail.com https://git.postgresql.org/pg/commitdiff/596ba75cb11173a528c6b6ec0142a282e42b69ec

  • pgbench：一旦计时器超时就停止计算已跳过的事务。使用节流（throttling）时，落后调度超过延迟限制的事务将被计算并报告为已跳过。以前，pgbench 会计算所有已跳过的事务，即使 -T 选项指定的计时器已经超时。特别是当 -R 选项中的不切实际的高速率设置导致大量事务落后于调度时，这可能需要很长时间。这可能会阻止 pgbench 立即结束，因此 pgbench 看起来可能会卡住。为解决此问题，此提交更改了 pgbench，使其在计时器超时后立即停止计算已跳过的事务。即使仍有许多尚未计算的已跳过事务，计时器也能很快让 pgbench 结束。请注意，即使在 -T 下，也不能保证所有已跳过的事务都会被计算，但在 -t 下可以。在实际设置下，这种情况不太可能发生，因此在实践中是没问题的。而且，这也不是此提交新引入的问题。以前，pgbench 在没有计算所有已跳过的事务的情况下就结束了。回填至 v14。根据讨论，我们决定不回填到稳定分支，因为很难想象在实际设置下会发生这种情况。作者：Yugo Nagata, Fabien COELHO 审查者：Greg Sabino Mullane, Fujii Masao 讨论：https://postgr.es/m/20210613040151.265ff59d832f835bbcf8b3ba@sraoss.co.jp https://git.postgresql.org/pg/commitdiff/9bcbd7c581a5de3b915ef8fe0262e4abd9cb6e59

Tom Lane 提交

  • 使 timetz_zone() 变为 STABLE，并纠正 DYNTZ 缩写的错误。历史上，timetz_zone() 使用 time(NULL) 作为决定夏令时是否激活的参考点。这意味着其结果可能在语句内部发生变化，需要将其标记为 VOLATILE (参见 35979e6c3)。但这一定义与我们处理时间戳的其他方式非常不一致。让我们改用事务开始时间（“now()”）作为参考点。这使其可以被标记为 STABLE，并且每次调用还可以节省一次内核调用。同时，移除函数对 pg_time_t 和 pg_localtime 的使用。这些与此区域的其他代码不一致，这确实产生了一个错误：如果时区由动态 TZ 缩写指定，timetz_zone() 会给出完全错误的答案。（我们需要在后端分支中对此进行处理，但修复方式将与此不同。）Aleksander Alekseev 和 Tom Lane 讨论：https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/388e71af880d579212c2489686903c2cfdea9032

  • 修正关于 struct pg_tm 内容的误导性注释。pgtime.h 在 POSIX tm_year 的解释旁边记录了 PG 对 tm_mon 的解释，没有任何提示表明这两个注释在我们的代码中都不正确。也许有一天我们应该切换使用两个单独的结构定义来更清晰地指示在何处使用哪种语义。但我担心冗长与安全收益的权衡不会很好。讨论：https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/89dba59590fdd03799a47daf8019890d4324fbcf

  • 进一步修复 psql 查询取消测试。等待 pg_sleep 运行的查询没有这样做，因为其使用的正则表达式可以匹配自身。报告：https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2021-09-06%2018%3A00%3A20 https://git.postgresql.org/pg/commitdiff/bd5846e4a9c1338ded5efcef53511f0d71f53f0e

  • 修复 rewriter 在重写查询时正确设置 hasModifyingCTE。如果我们从原始查询复制数据修改 CTE 到替换查询（来自 DO INSTEAD 规则），我们必须在替换查询中正确设置 hasModifyingCTE。未能这样做可能导致各种不愉快的后果，例如并行计划的不安全使用。代码还未能传播 hasRecursive，尽管这目前只是表面上的。如果规则操作是 INSERT...SELECT，则会出现一个难题。我们将原始查询的 RTE 和 CTE 附加到子 SELECT 查询，但数据修改 CTE 仅允许出现在最顶层的查询中。目前，在这种情况下会抛出错误。如果将 CTE 附加到顶层 INSERT 查询，则可能可以避免此错误；但这需要大量新代码来调整 ctelevelsup 引用。鉴于用例的狭窄性以及回填此修复的需要，目前似乎不值得麻烦。如果我们收到现场投诉，我们可以重新审视。根据 Greg Nancarrow 的报告。回填到所有支持的分支。（此处添加的测试用例在 v10 之前不会失败，但在 9.6 中有许多地方检查顶层 hasModifyingCTE，因此我毫不怀疑此代码更改在那里也是必要的。）Greg Nancarrow 和 Tom Lane 讨论：https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com 讨论：https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/362e2dcc46195faadd3fa0ba011dd9a8e3829e7a

  • 在 psql 标签补全中，提供拼写的命令而不是缩写。各种 psql 反斜杠命令都有单字母和长形式，例如 \e 和 \edit。以前，标签补全通常提供单字母形式，但不提供长形式。提供长形式似乎更合理，因为 (a) 当你已经输入了单字母时，没有有用的补全可以发生，并且 (b) 如果你对命令集不够熟悉以至于不知道这一点，长形式可能不那么令人困惑。Haiying Tang，审查者：Dagfinn Ilmari Mannsåker 和我 讨论：https://postgr.es/m/OS0PR01MB61136018064660F095CB57A8FB129@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/7cffa2ed0c9f7f4d96bac7af5284c47e82af5ffa

  • 修复关于 TOAST 访问宏的误导性注释。似乎是我的提交 aeb1631ed 中的错误。由 Christoph Berg 指出。讨论：https://postgr.es/m/YTeLipdnSOg4NNcI@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/490798451a3adc32b71b30e285bd99875d67fa2b

  • 避免 getFormattedTypeName() 周围无用的 malloc/free 流量。Coverity 抱怨一个 getFormattedTypeName() 的调用者未能释放返回的字符串。这是真的，但与其修复那个，不如让我们摆脱这个繁琐且容易出错的要求。既然 getFormattedTypeName() 现在缓存了它的结果，复制该结果并期望调用者释放它几乎没有作用，只会浪费周期。在我们 getTypes 没有为该类型制作 TypeInfo 的情况下，我们会造成泄漏，但这基本上永远不会发生。回填，就像提交 6c450a861 一样。这不是一个特别有趣的 bug 修复，但 API 更改似乎是未来回填活动的危险，如果我们不回填它。 https://git.postgresql.org/pg/commitdiff/072e2f8a62002cb01ed6c4e161442e133509349e

  • 尽早检查关系长度是否溢出。我们不允许关系超过 2^32-1 个块，因为块号是 32 位，并且最后一个可能的块号被保留用于表示 InvalidBlockNumber。mdextend 中有一个检查，但这真的太晚了，因为 smgr API 要求我们为要添加的块创建一个缓冲区，而且我们不想有任何块号为 InvalidBlockNumber 的缓冲区。（这种情况可能会触发 bufmgr.c 中的断言，而且我认为它可能还会混淆 ReadBuffer 的数据超出 EOF 的逻辑。）所以将检查放入 ReadBuffer。根据 Christoph Berg 的报告。这种情况已经存在很长时间了，所以回填到所有支持的分支。讨论：https://postgr.es/m/YTn1iTkUYBZfcODk@msg.credativ.de https://git.postgresql.org/pg/commitdiff/8481f99896a192e9fd57f5e1a99e255e27680a10

  • 避免从已终止的计划中获取。一些计划节点类型在返回 NULL 后再次调用时反应不佳。PortalRunSelect() 一直通过在发现门户已完全运行时调用执行器并将扫描方向设置为 NoMovementScanDirection 来处理此问题。然而，提交 ba2c6d6ce 忽略了这一点，因此持久化一个已完全获取的游标如果其具有此类计划则会失败。根据 Tomas Barton 的报告。回填到 v11，因为有问题的提交是。（我省略了一个测试用例，因为导致问题的计划类型并不那么稳定。）讨论：https://postgr.es/m/CAPV2KRjd=ErgVGbvO2Ty20tKTEZZr6cYsYLxgN_W3eAo9pf5sw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cba79a163267a44205e391137deb543f4f89bc8b

  • 修复 NO SCROLL 游标的一些异常情况。我们长期以来禁止从 NO SCROLL 游标反向获取，但该禁令并未延伸到我们完全倒回查询然后再次向前获取的情况。我认为原因是这个逻辑主要旨在保护不能反向运行的计划节点。然而，重新读取查询的输出如果查询是易变的（这包括 SELECT FOR UPDATE，而不仅仅是包含易变函数的查询）会很成问题：重新读取可能会产生不同的结果，这会完全混淆游标导航逻辑。这种方法还有一个原因就是一些代码路径会根据到目标行的距离来反向获取或倒回然后向前获取；因此，看似相同的用例可能或可能不会触发“游标只能向前扫描”错误。因此，让我们通过禁止在 NO SCROLL 游标中倒回以及反向获取来清理这些问题。通常，我们只会在 HEAD 中进行这种定义性更改，但现在有一个第三个原因来考虑此更改。提交 ba2c6d6ce 为带有 WITH HOLD 的非滚动游标创建了一些新的用户可见异常，因为在提交前游标已被部分读取，导致游标结果中的导航混乱。解决这些异常的唯一好方法是禁止倒回这样的游标，这允许移除 ba2c6d6ce 添加到 PersistHoldablePortal 的不正确的游标状态操作。为了最大限度地减少后端分支（包括 v14）中的行为更改，仅当 NO SCROLL 游标具有 holdStore 时（即由于 WITH HOLD 从先前的事务中保留），才禁止倒回。这应该可以避免破坏大多数对是否声明游标为可滚动不谨慎的应用程序。我们将从 v15 开始全面执行此禁令。回填到 v11，因为 ba2c6d6ce 是。讨论：https://postgr.es/m/3712911.1631207435@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/c1b7a6c2731241cf5af4c08de54a64fc8999d727

  • 使 pg_regexec() 对越界 search_start 具有鲁棒性。如果 search_start 大于字符串长度，我们应该立即返回 REG_NOMATCH。（请注意，相等情况不应被拒绝，因为模式可能匹配零个字符。）这可以保护各种内部假设，即字符串位置范围的最小值不大于最大值。违反这些假设可能会导致尝试获取 string[search_start-1]，可能导致崩溃。Jaime Casanova 指出，新的 regexp_xxx 函数接受用户指定的起始位置，可以通过这种情况触及。我不认为在 v14 及更低版本中可以通过任何核心调用点触及这种情况。但是，扩展可能会调用 pg_regexec 并提供一个越界的 search_start，所以我们仍然回填此修复。讨论：https://postgr.es/m/20210911180357.GA6870@ahch-to https://git.postgresql.org/pg/commitdiff/e757080e041214cf6983e3e77ef01e83f1371d72

Álvaro Herrera 提交

Noah Misch 推送

Amit Kapila 提交

Heikki Linnakangas 提交

Andres Freund 提交

  • Windows：仅当 stderr 无效时才认为 us 正在作为服务运行。以前，pgwin32_is_service() 在 postgres 从服务内启动但并非作为服务运行时会错误地返回 true。例如，Windows docker 容器总是如此，一些 CI 服务会用它来运行 Windows 测试。当 postgres 错误地认为它正在作为服务运行时，消息不会写入 stdout/stderr。这可能非常令人困惑，并导致一些测试失败。为了修复，请在 pgwin32_is_service() 中另外检查 stderr 是否无效。为此，在后端进程中，pg_ctl 被更改为传递句柄，以便 postgres 可以执行相同的检查（否则会创建“默认”句柄）。虽然此问题存在于所有分支中，但没有用户报告，当前的 CI 用途仅限于 master，而且我不是 Windows 专家。因此，目前仅在 master 中进行更改似乎是最明智的方法。作者：Andres Freund andres@anarazel.de 审查者：Magnus Hagander magnus@hagander.net 讨论：https://postgr.es/m/20210305185752.3up5eq2eanb7ofmb@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/76e38b37a5f179d4c9d2865ff31b79130407530b

Magnus Hagander 已推送

Daniel Gustafsson 提交