2026年2月26日： PostgreSQL 18.3、17.9、16.13、15.17 和 14.22 发布！

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

发布于 2021-10-11，PostgreSQL Global Development Group
PG 每周新闻

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

PostgreSQL 产品新闻

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

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

PostgreSQL 十月招聘信息

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

PostgreSQL 新闻报道

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

本周 PostgreSQL 每周新闻由 David Fetter 为您呈现

请在太平洋标准时间周日下午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（这些可能也不值得额外的资源来运行），也没有覆盖使用不同的 stderr 和 csvlog 组合重新加载 log_destination。我已经为此重构单独测试了所有这些情况。作者：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() 在某些情况下会强制将日志条目重定向到 stderr 以用于 csvlog，例如 syslogger 尚未可用。如果发生这种情况，csvlog 会回退到 stderr 来记录一些信息而不是什么都不记录。代码的组织方式是 stderr 在 csvlog 之前完成，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 提交了：

Fujii Masao 提交了：

Amit Kapila 提交了：

Robert Haas 提交了：

Dean Rasheed 提交了：

  • 修复 numeric_power() 中的边界情况精度损失。这修复了当第一个输入非常接近 1 时发生的精度损失，此时其对数非常小。以前，在初始低精度计算中估算结果权重时，对数的计算精度被限制在 NUMERIC_MAX_DISPLAY_SCALE（1000）的本地 rscale。然而，底数可能接近 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 提交了：