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

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

由 PWN 发布于 2021-09-06
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，一个 Python 包，其中包含一个可在单个 pip 安装文件中编译的整个 PostgreSQL 服务器，已发布

9 月份的 PostgreSQL 工作机会

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

PostgreSQL 新闻

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

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

请在太平洋标准时间下午 3:00 前（美国/加拿大太平洋地区时间）将新闻和公告提交至 david@fetter.org。

应用的补丁

Michaël Paquier 推送了

Amit Kapila 推送了

Fujii Masao 推送了

Álvaro Herrera 推送了

Daniel Gustafsson 推送

Tom Lane 推送

  • 修复内联新式 SQL 函数时遗漏的锁获取。当开始使用从目录加载的查询解析树时，我们必须首先应用 AcquireRewriteLocks()，以获得解析器在交互式输入查询时会获得的相同关系锁，并执行一些其他清理，例如处理稍后删除的列。新式 SQL 函数也像其他存储的解析树一样受此规则约束；但是，在处理此类函数的地方，只有 init_sql_fcache 记住了这一点。特别是，如果我们成功内联了一个包含任何关系引用的新式集合返回 SQL 函数，那么我们要么会得到断言失败，要么会尝试在没有锁的情况下使用这些关系。我还添加了对 fmgr_sql_validator 和 print_function_sqlbody 的 AcquireRewriteLocks 调用。Desultory 实验没有展示任何这些方面的失败，但我怀疑我只是尝试得不够努力。当然，我们不希望附近的代码路径在没有锁的情况下运行。按照旧代码应该具有相同效果的逻辑，也在 fmgr_sql_validator 中调用 pg_rewrite_query()。那里可能没有任何代码路径需要担心重写，但证明这一点的分析超出了我今天的目标。根据 Alexander Lakhin 的错误 #17161。讨论：https://postgr.es/m/17161-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 的排序规则处理，原因是我们每个人都未完全完成相同的重构。让我们完成这项工作，以期拥有更稳定的基础。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 的错误 #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，并且期望守护程序不使用该文件是合理的。作为一个简单的改进，让我们改为 dup 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 排序规则。以前允许这样做，但排序规则实际上消失了，因为 lookup_collation() 的工作方式：您既不能使用该排序规则，甚至不能删除它。与其让用户想知道为什么它不起作用，不如提前给出错误似乎更好。（因为此测试位于 DefineCollation 而不是 CreateCollation 中，因此它不会阻止 pg_import_system_collations 创建 ICU 排序规则，而不管最初选择的编码如何。）根据 Andrew Bille 的错误 #17170。向后移植到添加 ICU 支持的 v10。讨论：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()，我认为我可以先用 get_float4_nan() 替换 NaN，然后再扩展到 float8。然而，来自 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://postgresql.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 中进行交叉编译时，这不是很幸运，其中 include 和 libs 位于暂存目录中，因为这会将主机路径引入构建中：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. 使用“${includedir}”和“${libdir}”而不是在“Cflags”和“Libs”中硬编码路径。注意：这些变量可以在 pkg-config 命令行中被覆盖（“--define-variable=libdir=/some/path”）。2. 添加变量“prefix”和“exec_prefix”。如果“includedir”和/或“libdir”正在使用它们，则相应地构建它们。这样做是因为 buildroot（例如 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://postgresql.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://postgresql.ac.cn/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm 这样，在使用 buildroot 设置时，可以将路径强制放入暂存目录中：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://postgresql.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