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

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

由 PWN 于 2021-09-13 发布
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，该 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 段并创建其归档通知文件。如果 walreceiver 在下一个段中的任何 WAL 数据到达备用服务器之前退出，它不会创建当前段的归档通知文件，即使该段已知已完成。此行为可能会导致段的 WAL 归档延迟到后续的重启点或检查点创建其通知文件。为了解决此问题，此提交更改了 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: 一旦超出计时器，立即停止计数跳过的事务。当使用节流时，延迟超出限制的事务将被计数并报告为跳过。 之前，存在这样一种情况，即使超过了 -T 选项中指定的计时器，pgbench 也会计算所有跳过的事务。 这可能需要很长时间才能完成，特别是当 -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() 稳定，并更正 DYNTZ 缩写的错误。 历史上，timetz_zone() 一直使用 time(NULL) 作为决定 DST 是否激活的参考点。 这意味着它的结果可以在语句内更改，因此需要将其标记为 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 文档记录了 tm_mon 的 PG 解释以及 tm_year 的 POSIX 解释，但没有提示这两个注释在我们的代码中都不正确。 也许有一天我们应该切换到使用两个单独的结构定义，以便更清楚地表明在何处使用哪种语义。 但我担心乏味与安全性的权衡不会很好。 讨论：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

  • 修复重写器以在重写查询时正确设置 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() 缓存其结果，strdup 该结果并期望调用者释放它几乎没有什么作用，除了浪费周期。 在 getTypes 没有为类型创建 TypeInfo 的情况下，我们确实会创建一个泄漏，但这基本上永远不会发生。 回溯，如提交 6c450a861 那样。 这不是一个特别有趣的错误修复，但 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 及以下版本中的任何内核调用站点访问。 但是，扩展程序可能会使用超出范围的 search_start 调用 pg_regexec，因此我们仍然回溯修复。 讨论：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 无效时才认为我们作为服务运行。之前，当 postgres 从服务中的某个位置启动但不是作为服务启动时，pgwin32_is_service() 会错误地返回 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 推送了此项。