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

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

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

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

PostgreSQL 产品新闻

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

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

10 月份的 PostgreSQL 工作岗位

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) 之间拍摄的任何快照都将是空的，这可能导致依赖于此时快照的任何事务损坏数据，因为在同一次事务中连续调用 GetSnapshotData() 时，RecentXmin 可能会向后移动。由于 SharedRecoveryState 是判断是否可以安全丢弃 KnownAssignedXids 的关键点，因此此提交将步骤 2) 移到了步骤 3) 之后，这样我们就不会出现空快照的情况。这个问题自热备引入以来就存在，因此需要回溯所有版本。出现错误快照的窗口期非常短，但我通过运行 023_pitr_prepared_xact.pl 发现了它，buildfarm 成员 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 的最后一个文件名以及正在使用的文件描述符）。除了这些点之外，在错误处理以及是否应创建文件或继续使用现有文件方面，代码是相同的。此更改总体上使代码更简单，并将有助于引入更多基于文件的日志目标。此重构与 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() 在某些情况下会强制将 csvlog 的日志条目重定向到 stderr，例如 syslogger 尚未准备好。如果发生这种情况，csvlog 将回退到 stderr 来记录一些信息，而不是什么都不记录。代码的组织方式是先处理 stderr，然后处理 csvlog，csvlog 通过反向条件检查 stderr 是否尚未发生。使用这种代码组织方式，在 WIN32 上将 Postgres 作为服务运行时，可能会丢失一些消息，因为没有可用的 stderr，并且由于这个原因，StringInfoData（保存 stderr 消息）的处理相当令人困惑。此提交将 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 时，其对数非常小。以前，在估计结果权重的初始低精度计算过程中，对数会以本地 rscale 计算，该 rscale 被限制在 NUMERIC_MAX_DISPLAY_SCALE (1000) 以下。然而，基数可能接近 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 推送