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

PostgreSQL 每周新闻 - 2021 年 10 月 10 日

发布于 2021-10-11，作者：PWN
PWN

PostgreSQL 每周新闻 - 2021 年 10 月 10 日

PostgreSQL 产品新闻

pgCluu 3.2，一个用于审核 PostgreSQL 性能的 Perl 程序，已发布。

PGroonga 2.3.2，一个适用于所有语言的全文搜索平台，已发布。

PostgreSQL 10 月份的职位

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

PostgreSQL 新闻报道

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

本周 PostgreSQL 每周新闻由 David Fetter 为您带来

请在太平洋标准时间 (PST8PDT) 周日下午 3:00 前将新闻和公告提交至 david@fetter.org。

已应用的补丁

Michaël Paquier 推送了

  • 修复在热备节点使用 2PC 提升期间的快照构建问题。当涉及 2PC 事务时，在恢复结束时会执行一些特定的逻辑：1) 调用 RecoverPreparedTransactions()，将 2PC 事务的状态恢复到内存中（重新获取锁等）。2) ShutdownRecoveryTransactionEnvironment()，恢复到正常操作，主要清理恢复锁和 KnownAssignedXids（包括之前跟踪的任何 2PC 事务）。3) 将 XLogCtl->SharedRecoveryState 切换到 RECOVERY_STATE_DONE，这是任何调用 RecoveryInProgress() 的进程检查集群是否仍在恢复中的临界点。在步骤 2) 和 3) 之间获取的任何快照都将为空，导致任何依赖此时快照的事务可能会损坏数据，因为可能仍有一些 2PC 事务需要跟踪，并且 RecentXmin 在同一事务中连续调用 GetSnapshotData() 时会向后移动。由于 SharedRecoveryState 是确定是否可以安全地放弃 KnownAssignedXids 的依据，因此此提交将步骤 2) 移到步骤 3) 之后，以便我们永远不会以空快照结束。这种情况自引入热备以来就存在，因此需要全部向后移植。出现不正确快照的窗口非常小，但我在运行 023_pitr_prepared_xact.pl 时看到过，构建农场成员 fairywren 也看到了。Thomas Munro 也独立发现了这个问题。特别感谢 Andres Freund 花时间分析这个问题。报告者：Thomas Munro，Michael Paquier 分析者：Andres Freund 讨论：https://postgr.es/m/20210422203603.fdnh3fu2mmfp2iov@alap3.anarazel.de 向后移植到：9.6 https://git.postgresql.org/pg/commitdiff/8a4237908c0fe73dd41d4d7c7a6314f17dfd7a6f

  • 修复 pg_verifybackup 的 TAP 测试中的警告。a3fcbcd 中的疏忽。报告者：Thomas Munro 讨论：https://postgr.es/m/CA+hUKGKnajZEwe91OTjro9kQLCMGGFHh2vvFn8tgHgbyn4bF9w@mail.gmail.com 向后移植到：13 https://git.postgresql.org/pg/commitdiff/ec2133a447318ac6d78887e91940d69e6d92a435

  • 重构日志收集器中每个目标文件的轮换。stderr 和 csvlog 在按大小、年龄轮换其文件或在用户请求强制轮换（pg_ctl logrotate 或 SQL 函数 pg_rotate_logfile）时使用了重复的代码。两者之间的主要区别在于 stderr 要求其文件始终处于打开状态，以便在启用备用目标时，如果日志收集器尚未准备好执行其工作，则可以进行重定向。此外，如果禁用 csvlog，我们需要正确关闭存储在日志收集器中的元数据（current_logfiles 的最后一个文件名和当前打开用于业务的 fd）。除了这些点之外，该代码在错误处理以及是否应创建文件或仅继续方面是相同的。此更改使代码总体上更简单，并且有助于引入更多基于文件的日志目标。此重构类似于 5b0b699 中完成的工作。大部分重复源于 fd801f4。pg_ctl 的一些 TAP 测试检查了强制日志轮换的情况，但这在某种程度上是有限的，因为没有对 log_rotation_age 或 log_rotation_size 的覆盖（这些可能不值得运行额外的资源），并且没有对 log_destination 与 stderr 和 csvlog 的不同组合的重新加载的覆盖。我已针对此重构分别测试了所有这些情况。作者：Michael Paquier 讨论：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5c6e33f071537d9831db57471a06d39a175b535a

  • 修复 syslogger.c 中的编译警告。5c6e33f 中的疏忽。作者：Nathan Bossart 讨论：https://postgr.es/m/DD8AD4CE-63B7-44BE-A3D2-14A4E4B19C26@amazon.com https://git.postgresql.org/pg/commitdiff/05c4248ad1bf0c2721ce9445f6908da9ece36ff8

  • 重构 csvlog 回退到 stderr 的方式，以更好地处理 WIN32 服务案例。在某些情况下，send_message_to_server_log() 会强制将日志条目重定向到 csvlog 的 stderr，例如 syslogger 尚未可用。如果发生这种情况，csvlog 将回退到 stderr 以记录一些信息，而不是什么都不记录。代码的组织方式是先执行 stderr，然后 csvlog 检查 stderr 是否尚未发生，条件是相反的。通过这种代码组织，如果在 WIN32 上将 Postgres 作为服务运行，则可能会丢失一些消息，因为没有可用的 stderr，并且用于 stderr 的保存消息的 StringInfoData 的处理非常混乱。此提交将 csvlog 处理移到 stderr 之前，因为我们可以跟踪是否需要将某些内容记录到 stderr。这减少了 stderr 的处理，使其处于单个代码路径中，为 WIN32 服务添加了回退到事件日志的功能。这也简化了我们处理 stderr 的 StringInfoData 的方式，从而更容易集成新的基于文件的日志目标。我在检查此更改时尝试了 Windows 上的服务和事件日志。审核者：Chris Bandy 讨论：https://postgr.es/m/YV0vwBovEKf1WXkl@paquier.xyz https://git.postgresql.org/pg/commitdiff/8b76f89c37973082b3d64f5a27937efcca9d65f6

Daniel Gustafsson 推送了

Peter Eisentraut 推送了

Tom Lane 推送了

Andres Freund 推送了

Bruce Momjian 推送了

藤井雅雄推送了

Amit Kapila 推送了

Robert Haas 推送了

Dean Rasheed 推送了

  • 修复 numeric_power() 中极端情况下的精度损失。此修复解决了当第一个输入非常接近 1 时发生的精度损失，此时其对数非常小。以前，在用于估计结果权重的初始低精度计算期间，对数计算使用的局部 rscale 被限制为 NUMERIC_MAX_DISPLAY_SCALE (1000)。然而，底数可能非常接近 1，如 1e-16383，因此其对数可能小至 1e-16383，所以局部 rscale 需要允许超过 16383，否则所有精度都会丢失，导致为全精度计算选择的 rscale 不佳。通过在初始低精度计算期间移除对局部 rscale 的限制来修复此问题，就像我们在全精度计算中已经做的那样。这并不会改变初始计算是低精度近似的事实，它将对数计算到大约 8 位有效数字，这非常快，尤其是在底数非常接近 1 时。此补丁由我提供，由 Alvaro Herrera 审核。讨论：https://postgr.es/m/CAEZATCV-Ceu%2BHpRMf416yUe4KKFv%3DtdgXQAe5-7S9tD%3D5E-T1g%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/e54a758d24dab056bb7f50d26c57a3c8761cc44a

Etsuro Fujita 推送了此更改