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

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

发布于 2021-09-06 by PWN
PWN

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

PostgreSQL 产品新闻

pg_dbms_job 1.1.0，一个用于创建、管理和使用 Oracle 风格的 DBMS_JOB 计划作业的扩展，已发布。

dbForge Data Compare for PostgreSQL v3.4 已发布

pgmoneta 0.5.0，一个用于 PostgreSQL 的备份和恢复系统，已发布

pgspider_ext，一个基于 PostgreSQL 外部数据包装器的集群引擎扩展，用于分布式数据，已发布。

psycopg2 3.0.0 beta 1，一个用于 PostgreSQL 的 Python 连接器，已发布。

postgresql-wheel，一个包含单个 pip 可安装文件中的整个编译版 PostgreSQL 服务器的 Python 包，已发布

九月 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 提交

Amit Kapila 提交

Fujii Masao 提交

Álvaro Herrera 提交

Daniel Gustafsson 提交

Tom Lane 提交

  • 修复在内联新式 SQL 函数时遗漏的锁获取。当开始使用从 catalog 加载的查询解析树时，我们必须首先调用 AcquireRewriteLocks()，以获取与交互式输入查询相同的关系锁，并执行其他清理工作，例如处理稍后删除的列。新式 SQL 函数与存储的解析树一样受此规则约束；然而，在处理这些函数的地方，只有 init_sql_fcache 得到了提示。特别是，如果我们成功内联了一个包含任何关系引用的新式返回集 SQL 函数，我们将遇到断言失败或尝试在没有锁的情况下使用这些关系。我还向 fmgr_sql_validator 和 print_function_sqlbody 添加了 AcquireRewriteLocks 调用。零散的实验并未表明这些方面有任何失败，但我怀疑我只是不够努力。当然，我们不希望附近的路径在没有锁的情况下运行。基于“应该具有与旧代码相同的效果”的逻辑，也调用 pg_rewrite_query() 在 fmgr_sql_validator 中。这两种路径可能都不需要重写，但要证明这一点所需的工作量超出了我今天的目标。根据 Alexander Lakhin 的 bug #17172。讨论：https://postgr.es/m/17172-048a1cdff8422800@postgresql.org https://git.postgresql.org/pg/commitdiff/589be6f6c732a20e2bcaa02560de464ebbd48af2

  • 缓存 pg_dump 中 format_type() 查询的结果。pg_dump 的 getFormattedTypeName 函数中长期存在一个“TODO：缓存结果可能有一些价值”的注释；但我们还没有检查过重复查找类型名称给我们带来了多大成本。事实证明，在转储当前回归数据库时，大约 10% 的查询是重复的 format_type() 查询。然而，Hubert Depesz Lubaczewski 报告了一个并不罕见的案例，其中这些查询占 pg_dump 发出的查询的一半以上。单独来看，这些查询并不昂贵，但当网络延迟成为因素时，它们累积成了一个问题。我们可以很容易地向 getFormattedTypeName 添加一些缓存来解决这个问题。由于这是一个简单的修复，并且可以带来可见的性能提升，因此将其向后移植到所有支持的分支。讨论：https://postgr.es/m/20210826084430.GA26282@depesz.com https://git.postgresql.org/pg/commitdiff/6c450a861f1a928f44c9ae80814ed9a91927c25a

  • 在 pg_dump 中，避免对 RLS 策略进行逐表查询。在没有任何特别好的理由的情况下，getPolicies() 为每个表单独查询 pg_policy。我们可以改为一次性收集所有策略，并通过 findTableByOid() 查找将它们附加到正确的 TableInfo 对象。在回归数据库上，这大大减少了查询次数，即使在本地服务器上运行也能提供可见的节省。根据 Hubert Depesz Lubaczewski 的抱怨。由于这是一个简单的修复，并且可以带来可见的性能提升，因此将其向后移植到所有支持的分支。讨论：https://postgr.es/m/20210826084430.GA26282@depesz.com https://git.postgresql.org/pg/commitdiff/bd3611db5a6f3726094872f59feab426374d2c46

  • 重构 postgresImportForeignSchema 以避免代码重复。与 pg_dump 近期的清理工作类似，避免重复我们正在构建的查询片段。我对这个问题感到厌烦，因为 aa769f80e 破坏了我关于更改 postgres_fdw 的 collation 处理的待处理补丁，因为我们各自都不完整地完成了这项重构。让我们完成这项工作，希望能有一个更稳定的基础。 https://git.postgresql.org/pg/commitdiff/2dc53fe2a77d8d5f22c656fdf6590198e358a996

  • 文档：阐明触发器与事务的关系。Laurenz Albe，根据 Nathan Long 的抱怨。讨论：https://postgr.es/m/161953360822.695.15805897835151971142@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/469150a240dd79acbe7d86cb5df869d95f4d6d2d

  • 修复 float4/float8 哈希函数以产生一致的 NaN 结果。IEEE 754 标准允许 NaN 有各种位模式，其中至少两种（“NaN”和“-NaN”）在大多数机器上的 SQL 中都相当容易产生。这有问题，因为我们的 btree 比较函数认为所有 NaN 都相等，但我们的 float 哈希函数不知道 NaN，并且会愉快地为它们产生不同的哈希码。这会导致对包含不同 NaN 值的列进行哈希处理的查询产生意外结果。在使用 float 列的哈希索引时，也可能导致意外的查找失败，即“WHERE x = 'NaN'”找不到应找到的所有行。为了解决这个问题，在 float 哈希函数中对 NaN 进行特殊处理，这与强制零和负零具有相同哈希值的现有特殊处理非常相似。我安排了最普通的 NaN（来自 C99 NAN 常量）仍然具有与以前相同的哈希码，以降低现有哈希索引的风险。我犹豫是否要将此向后移植到稳定分支，但最终决定这样做。对于内部进行哈希处理的查询，这是一个明显的改进。如果有人在哈希索引中有 -NaN，他们最好在应用此补丁后重新索引...但如果不这样做，其错误行为不会比他们以前的错误行为差多少。根据 Ma Liangzhu 的 bug #17172。讨论：https://postgr.es/m/17172-7505bea9e04e230f@postgresql.org https://git.postgresql.org/pg/commitdiff/ce773f230d9b5bb2e0dd23fec4e5462fd99487fe

  • 在 count_usable_fds() 中，复制 stderr 而不是 stdin。我们收到投诉说，如果调用程序关闭 stdin，postmaster 就无法启动。这是因为 count_usable_fds 期望能够 dup(0)，如果它不能，我们就得出没有空闲 FD 的结论并崩溃。但据我所知，服务器中没有其他地方会触及 stdin，并且可以合理地期望守护进程不会使用该文件。作为简单的改进，让我们复制 FD 2（stderr）而不是。与 stdin 不同，我们可以合理地期望 stderr 是打开的；即使我们配置为不触及它，像 libc 这样的常用库也可能尝试在那里写入错误消息。根据 Mario Emmenlauer 的抱怨。鉴于以前没有投诉，我不热衷于将其推送到稳定分支，但将其挤入 v14 似乎还可以。讨论：https://postgr.es/m/48bafc63-c30f-3962-2ded-f2e985d93e86@emmenlauer.de https://git.postgresql.org/pg/commitdiff/c95ede41b8d47b21d58702fbc519e720f41fdaf1

  • 修复 commit ce773f230 中测试的可移植性问题。现代 POSIX 似乎要求 strtod() 接受 “-NaN”，但 SUSv2 中没有关于 NaN 的内容，而且我们一些最老的 buildfarm 成员也不喜欢它。让我们尝试将其写为 -'NaN'；这似乎会产生相同的结果，至少在 Intel 硬件上是这样。根据 buildfarm。 https://git.postgresql.org/pg/commitdiff/fd549145d5d9fba3367cbf7e3d4fc7cb3562feb0

  • 如果数据库编码不支持，则禁止创建 ICU collation。以前这是允许的，但 collation 由于 lookup_collation() 的工作方式而有效地消失了：你无法使用 collation，甚至无法删除它。最好立即报错，而不是让用户怀疑它为什么不起作用。（因为这个测试在 DefineCollation 而不是 CreateCollation 中，它不会阻止 pg_import_system_collations 创建 ICU collation，无论初始选择的编码如何。）根据 Andrew Bille 的 bug #17170。向后移植到 v10，其中添加了 ICU 支持。讨论：https://postgr.es/m/17170-95845cf3f0a9c36d@postgresql.org https://git.postgresql.org/pg/commitdiff/db2760a84191c329c0cdfaa1dae048c32b0c1752

  • 移除 pg_ctl 中命令长度的任意 MAXPGPATH 限制。将固定长度的命令缓冲区替换为 psprintf() 调用。在编写此代码时，我们没有像 psprintf() 这样方便的工具，但现在有了，几乎没有理由让这个限制继续存在。删除它消除了某些边缘情况（例如，使用大量选项启动 postmaster 会失败）。pg_ctl 处理的大多数单个文件名仍然限制在 MAXPGPATH，但只要它只适用于一个文件名，我们就很少收到关于该限制的抱怨。向后移植到所有支持的分支。Phil Krylov 讨论：https://postgr.es/m/567e199c6b97ee19deee600311515b86@krylov.eu https://git.postgresql.org/pg/commitdiff/87ad491472d6f8620d83ec9db4f515ce303052ac

  • psql 帮助输出的微小改进。修复 "\?" 输出的字母顺序，并改进了一个描述。在需要的地方更新 PageOutput 计数，修复了之前补丁造成的破坏。Haiying Tang（PageOutput 修复由我完成）讨论：https://postgr.es/m/OS0PR01MB61136018064660F095CB57A8FB129@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/ac5ea660996ecbbfbe78b881a581132a95d93d26

  • float4/float8 哈希函数的进一步可移植性调整。试图让 hashfloat4() 尽可能像 hashfloat8()，我曾以为我可以在扩展到 float8 之前将 NaN 替换为 get_float4_nan()。然而，来自 protosciurus 和 topminnow 的结果表明，在某些平台上，这会产生与 get_float8_nan() 不同的位模式，打破了 ce773f230 的意图。重新安排，以便为所有 NaN 情况使用 get_float8_nan() 的结果。和以前一样，向后移植。 https://git.postgresql.org/pg/commitdiff/b30cc0fd6d5d96c63037824c286cec561e092b6f

Tomáš Vondra 提交了

John Naylor 提交了

Peter Geoghegan 提交

Peter Eisentraut 提交

  • 修复不正确的格式占位符。 https://git.postgresql.org/pg/commitdiff/590ecd982304dec8599d6ca339903982d39a9a1a

  • 修复静态链接的 pkg-config 文件。自 ea53100d5 (PostgreSQL 12) 以来，已分发的 pkg-config 文件对于静态链接 libpq 而言已损坏，因为缺少 libpgcommon 和 libpgport。此补丁添加了这两个缺失的私有依赖项（以非硬编码方式）。报告者：Filip Gospodinov f@gospodinov.ch 讨论：https://postgres.ac.cn/message-id/flat/c7108bde-e051-11d5-a234-99beec01ce2a@gospodinov.ch https://git.postgresql.org/pg/commitdiff/4c2eab3a0dec2eae40892fb525830a5947a398c7

  • 使 pkg-config 文件对交叉编译友好。当前 pc 文件使用硬编码的“includedir”和“libdir”路径。示例：Cflags: -I/usr/include Libs: -L/usr/lib -lpq 当在 buildroot 中交叉编译时，这很不理想，因为 includes 和 libs 位于 staging 目录中，这会在构建中引入主机路径：checking for pkg-config... /builder/shared-workdir/build/sdk/staging_dir/host/bin/pkg-config checking for PostgreSQL libraries via pkg_config... -L/usr/lib <---- 此提交通过执行以下两件事来解决此问题：1. 不硬编码“Cflags”和“Libs”中的路径，而是使用 “${includedir}” 和 “${libdir}”。注意：这些变量可以在 pkg-config 命令行中被覆盖（“--define-variable=libdir=/some/path”）。2. 添加“prefix”和“exec_prefix”变量。如果“includedir”和/或“libdir”使用这些变量，则相应地构造它们。这是因为 buildroots（例如 OpenWrt）倾向于重命名实际的 pkg-config 并从设置了“prefix”、“exec_prefix”和“bindir”的脚本间接调用它，如下所示：pkg-config.real --define-variable=prefix=${STAGING_PREFIX} --define-variable=exec_prefix=${STAGING_PREFIX} --define-variable=bindir=${STAGING_PREFIX}/bin $@ 示例 #1：用户使用“--libdir=/some/lib”和“--includedir=/some/include”调用 ./configure：prefix=/usr/local/pgsql exec_prefix=${prefix} libdir=/some/lib includedir=/some/include Name: libpq Description: PostgreSQL libpq library Url: https://postgres.ac.cn/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm 示例 #2：用户不带参数调用 ./configure：prefix=/usr/local/pgsql exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libpq Description: PostgreSQL libpq library Url: https://postgres.ac.cn/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm 这样，在使用 buildroot 设置时，可以将路径强制放入 staging 目录：checking for pkg-config... /home/sk/tmp/openwrt/staging_dir/host/bin/pkg-config checking for PostgreSQL libraries via pkg_config... -L/home/sk/tmp/openwrt/staging_dir/target-mips_24kc_musl/usr/lib 作者：Sebastian Kemper sebastian_ml@gmx.net 合著者：Peter Eisentraut peter.eisentraut@enterprisedb.com 讨论：https://postgres.ac.cn/message-id/flat/20200305213827.GA25135%40darth.lan https://git.postgresql.org/pg/commitdiff/6588d8416e4ef84fd99fb271b63116f207c6c479

Tatsuo Ishii 推送

  • 在 pgbench 中使用 COPY FREEZE 以加快基准测试表填充速度。在填充 pgbench_accounts 表时，始终无条件地使用普通 COPY。通过将其更改为 COPY FREEZE，VACUUM 的时间会大大减少，因此“pgbench -i”的总时间也会减少。这仅发生在 pgbench 运行在 PostgreSQL 14 或更高版本上时，因为以前版本的 PostgreSQL 中的 COPY FREEZE 不会带来好处。另外，如果使用分区，则无法使用 COPY FREEZE。在这种情况下，也将使用普通 COPY。作者：Tatsuo Ishii 讨论：https://postgr.es/m/20210308.143907.2014279678657453983.t-ishii@gmail.com 审阅者：Fabien COELHO、Laurenz Albe、Peter Geoghegan、Dean Rasheed https://git.postgresql.org/pg/commitdiff/06ba4a63b85e5aa47b325c3235c16c05a0b58b96