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

PostgreSQL 每周新闻 - 2022 年 1 月 2 日

发布于 2022-01-05，作者：PWN
PWN

PostgreSQL 每周新闻 - 2022 年 1 月 2 日

PostgreSQL 产品新闻

Pgpool-II 4.2.7、4.1.10、4.0.17 和 3.7.22 版本发布，这是一个用于 PostgreSQL 的连接池和语句复制系统，已修订。

parquet_s3_fdw 0.2.1 版本发布，这是一个用于 S3 上 parquet 文件的外部数据包装器。已发布。

Database Lab 3.0 版本发布，这是一个用于快速克隆大型 PostgreSQL 数据库以构建非生产环境的工具。已发布。

sqlite_fdw 2.1.1 版本发布。已发布。

DynamoDB FDW 1.1.0 版本发布。已发布。

pg_query_rewrite 0.0.3 版本发布，这是一个用于特定类型 PostgreSQL 语句的重写器。已发布。

InfluxDB fdw 1.1.1 版本发布 https://github.com/pgspider/influxdb_fdw

pgspider v2.0 版本发布，这是一个基于 PostgreSQL 外部数据包装器的分布式数据集群引擎。已发布。

pg_builder 2.0.0 版本发布，这是一个用于 PostgreSQL 的 PHP 查询构建器。已发布。

JDBC FDW 0.1.0 版本发布。已发布

griddb_fdw 2.1.1 版本发布。https://github.com/pgspider/griddb_fdw

一月份的 PostgreSQL 工作岗位

https://archives.postgresql.org/pgsql-jobs/2022-01/

PostgreSQL 本地活动

Nordic PGDay 2022 将于 2022 年 3 月 22 日在芬兰赫尔辛基的希尔顿赫尔辛基斯特兰德酒店举行。此处

pgDay Paris 2022 将于 2022 年 3 月 24 日在法国巴黎举行。

FOSDEM PGDay 2022 将于 2022 年 2 月 5 日至 6 日在线上举行。https://fosdem.org/2022/

Citus Con，一个全球虚拟开发者大会，将于 2022 年 4 月 12 日至 13 日举行。征稿现已开放。

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

请在太平洋标准时间（PST8PDT）周日晚上3:00之前将新闻和公告发送至 david@fetter.org。

已应用补丁

Peter Eisentraut 提交

John Naylor 提交了

  • 为 UTF-8 文本验证添加快速路径。我们之前的验证器使用了一个传统的算法，该算法一次进行一个字节的比较和分支。它的优点是我们总是确切地知道验证了多少字节，但这种精度是有代价的。在 `COPY FROM` 的性能分析中，输入验证会显著出现，而 `COPY FROM` 未来在并行处理或更快的行解析方面的改进将对输入验证施加更大的压力。因此，为 ASCII 和多字节 UTF-8 添加了快速路径：使用位运算一次检查 16 个字节以进行 ASCII 验证。如果失败，则对这些字节使用“基于移位”的 DFA 来处理通用情况，包括多字节。这些路径相对没有分支，因此对所有类型的字节模式都具有鲁棒性。使用这些算法，UTF-8 验证速度提高了数倍，具体取决于平台和输入字节分布。对于短字符串以及快速路径返回错误时，保留了 `pg_utf8_verifystr()` 中的先前代码。由 Heikki Linakangas、Vladimir Sitnikov、Amit Khandekar、Thomas Munro 和 Greg Stark 进行审查、性能测试和附加修改。讨论：https://postgresql.ac.cn/message-id/CAFBsxsEV_SzH%2BOLyCiyon%3DiwggSyMh_eF6A3LU2tiWf3Cy2ZQg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/911588a3f816d875261d8f7d89e2517978831cd5

Tom Lane 提交

  • 向 psql 添加 `\getenv` 命令。`\getenv` 将环境变量的值获取到 psql 变量中。这与十多年前添加的 `\setenv` 命令作用相反。当时我们没有看到 `\getenv` 的有力用例，但即将进行的回归测试重构提供了添加它的充分理由。讨论：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/33d3eeadb21d2268104840cfef6bc2226ddfc680

  • 删除回归测试脚本的动态翻译，第一步。`pg_regress` 长期以来一直提供动态替换回归测试脚本和结果文件中的路径名的机制，但使用该功能一直很麻烦，主要是因为更新结果文件需要繁琐的手动编辑。让我们用通过环境变量传递路径来摆脱它。除了更易于维护外，这种方式还可以处理需要在运行时转义的路径名，例如包含单引号的路径。（在实际构建具有此类路径名的路径方面还有其他障碍，但删除此路径似乎是件好事。）实现此目的的关键编码规则是使用 psql 的 `\set` 命令串联动态可变字符串的各个部分，然后使用 `:'variable'` 表示法来引用和转义字符串以进行下一级解释。为了使此更改对“git blame”更加透明，我将其分为两个步骤。此提交添加了必要的 `pg_regress.c` 支持，并就地更改了所有 `*.source` 文件，以便它们不再需要任何动态翻译。下一条提交将仅将它们“git mv”到常规的 `sql/` 和 `expected/` 目录中。讨论：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d1029bb5a26cb84b116b0dee4dde312291359f2a

  • 删除回归测试脚本的动态翻译，第二步。“git mv”所有 `input/*.source` 和 `output/*.source` 文件到相应的 `sql/` 和 `expected/` 目录。然后删除与动态翻译相关的 `pg_regress` 和 `Makefile` 基础设施。讨论：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/dc9c3b0ff21465fa89d71eecf5e6cc956d647eca

  • 将 `dblink` 的路径测试脚本合并到其主测试中。现在没有理由启动单独的 psql 运行来创建这些函数。（主回归测试也需要一些重构，但这还需要进一步思考。）讨论：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0e6e7f0806b2080cb31f33ff992ec2e4e35fa6f1

  • 为自定义 GUC 添加 `EmitWarningsOnPlaceholders()` 调用。定义任何自定义 GUC 的扩展在这样做之后应该调用 `EmitWarningsOnPlaceholders()`，以帮助捕获拼写错误。然而，我们的许多 contrib 模块都没有遵循这一点。还将此类调用添加到 `src/test/modules` 扩展中，这些扩展有 GUC。虽然这些并非真正面向用户，但它们应该说明良好实践而不是错误的实践。作者：Shinya Kato 讨论：https://postgr.es/m/524fa2c0a34f34b68fbfa90d0760d515@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/1fada5d81e6769ded832a4ca62ee9371bac3fb9f

  • 为 psql 的 `\getenv` 添加帮助和制表符补全支持。我在 33d3eeadb 中忘记了这些细节 :-（。由 Christoph Berg 提出。讨论：https://postgr.es/m/YcI8i/mduMi91uXY@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/0f2abd05441f524a67bc58ef5f0cc32054f7fb66

  • 重新考虑处理带有扩展保留前缀的设置。提交 `75d22069e` 在尝试设置一个未识别的参数（位于之前由扩展保留的命名空间内）时，会打印一个警告。然而，出于同样的原因，我们不允许你设置未识别的未限定参数名称，因此让它成为一个明确的错误似乎更好。无论如何，之前的实现效率低下且有错误。在一个更合适的位置执行检查，并更仔细地处理前缀匹配的情况。讨论：https://postgr.es/m/116024.1640111629@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2ed8a8cc5b634d33ea07d681c6b02213da07f792

  • 将 `EmitWarningsOnPlaceholders()` 重命名为 `MarkGUCPrefixReserved()`。这似乎是更清晰地描述其当前功能。提供一个兼容宏，以便扩展不必立即转换为新名称。讨论：https://postgr.es/m/116024.1640111629@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5609cc01c69b80f8788771dc6f5696a459469119

  • 撤销关于占位符警告/错误的更改。撤销提交 `5609cc01c`、`2ed8a8cc5` 和 `75d22069e`，直到我们有一个不那么有问题的关于如何在并行工作进程中处理此问题的想法。根据 buildfarm 的反馈。讨论：https://postgr.es/m/1640909.1640638123@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/cab5b9ab2c066ba904f13de2681872dcda31e207

  • 修复 `pgarch` 新目录扫描逻辑中的问题。`arch_filenames[]` 数组元素比所需长度少一个字节，因此一个最大长度的文件名在之后添加另一个条目时会被损坏。（由 Thomas Munro 发现，由 Nathan Bossart 修复。）将这些数组移到一个 `palloc` 分配的结构中，这样我们就不会在每个非归档进程中浪费几 KB 的静态数据。添加一个 `binaryheap_reset()` 调用，以明确表示我们使用空的堆开始目录扫描。我不认为那里有活动的 bug，但它看起来很脆弱，而这是一种廉价的保险。提交 `beb4e9ba1` 的清理工作，无需回溯补丁。讨论：https://postgr.es/m/CA+hUKGLHAjHuKuwtzsW7uMJF4BVPcQRL-UMZG_HM-g0y7yLkUg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1fb17b1903414676bd371068739549cd2966fe87

  • 在 `pg_dump` 中进行小的清理/优化。在提交 `05649b88c` 和 `5209c0ba0` 之后，`findComments()` 和 `findSecLabels()` 不再使用它们的“Archive `*fout`”参数，因此将其移除。在进行此操作时，我注意到 `dumpCompositeTypeColComments()` 不必自行查询以获取复合类型的列名，而调用函数刚刚获取了相同的数据，这没有太大意义。对其进行调整，以使用该查询结果。这可能对大多数人来说节省不了多少，因为自 `5209c0ba0` 以来，除非复合类型至少有一个注释，否则我们不会进入此代码。尽管如此，它仍然是一个浪费的查询。https://git.postgresql.org/pg/commitdiff/c7cf73eb7b9e7911748ebe117a7219f21e504121

  • pg_dump：使 `dumpPublication` 等与同级函数更相似。`dumpPublication`、`dumpPublicationNamespace`、`dumpPublicationTable` 和 `dumpSubscription` 未检查 `dataOnly`。这只是一个潜在的 bug，因为 `pg_backup_archiver.c` 稍后会过滤掉 `ArchiveEntry`；但它们在仅数据转储中浪费了计算周期，并且这种遗漏有一天可能会成为一个活动的 bug。无论如何，让一些 `dumpFoo` 函数执行此操作而另一些不执行是不好的。基于相同的理由，使 `dumpPublicationNamespace` 遵循所有其他 `dumpFoo` 函数检查 `DUMP_COMPONENT_DEFINITION` 标志的模式。（自 `5209c0ba0` 以来，如果未设置该标志，我们甚至不会进入此处，因此目前检查它只是形式上的。但将来可能并非如此。）由于这只是美化或未来兼容性，因此无需回溯补丁。https://git.postgresql.org/pg/commitdiff/5e65df64d631257ce60016bec0aca43f042b1d33

  • pg_dump：通过消除子查询来小的性能改进。移除“username_subquery”机制，转而进行本地查找角色名 OID。PG 后端对于 SELECT 输出列表中的标量 SubLinks 并不十分智能，因此这提供了一个小的性能改进，至少在拥有两个以上用户的安装中是如此。无论如何，旧方法并没有使 SQL 代码更易读。同时，我移除了关于查找对象所有者失败的各种自定义警告消息，转而直接在本地查找函数中将其视为致命错误。据我所知，现在没有任何理由将其视为除了目录损坏之外的任何情况，当然也没有理由让翻译人员处理十几种不同的消息，而一种就足够了。（如果事实证明 `fatal()` 确实是个坏主意，我们可以退回到发出 `pg_log_warning()` 并返回一个空字符串，从而产生与之前相同的行为，只是更一致。）还删除了一个完全不必要的子查询来检查序列关系的 `pg_depend` 状态：我们已经在 FROM 子句中有一个 LEFT JOIN 来获取感兴趣的行。讨论：https://postgr.es/m/2460369.1640903318@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d5e8930f50e31d836d84b353b9dadedd5007bb70

  • pg_dump：在 `getPolicies()` 中避免不安全的函数调用。`getPolicies()` 患有与提交 `e3fcbbd62` 中我修复的其他地方相同的“疾病”，即它为我们不一定拥有锁的表上的表达式调用 `pg_get_expr()`。为了修复，将查询限制为仅收集感兴趣的行，而不是在客户端进行过滤。与之前的补丁一样，目前只适用于 HEAD。讨论：https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us 讨论：https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc https://git.postgresql.org/pg/commitdiff/3e6e86abca0138abd7265306beb6346dc2d9e221

  • 当无法返回所有索引列时，修复仅索引扫描计划。如果索引同时包含可返回和不可返回的列，并且其中一个不可返回的列是使用在可返回列中的 Var 的表达式，那么返回该表达式的查询可能会导致仅索引扫描计划，该计划会尝试读取不可返回的列，而不是按预期从可返回的列重新计算表达式。为了修复，将 `IndexOnlyScan` 计划节点的“indextlist”列表重新定义为用 `Const` 的 `null` 值代替任何不可返回的列。通过阻止 `setrefs.c` 错误地匹配这些条目来解决此问题。执行程序乐于接受，因为它只关心条目的公开类型，并且 `ruleutils.c` 也不关心，因为正确的计划不会引用这些条目。我还考虑了其他几种方法来阻止 `setrefs.c` 产生错误行为，但这种方法似乎很好，因为（a）它允许非常局部化的修复，（b）它在许多情况下使 `indextlist` 结构更紧凑，并且（c） `indextlist` 现在更忠实地表示索引 AM 实际会产生什么，即对任何不可返回的列返回 `null`。自从我们引入了包含列以来，这一点更容易受到影响，但也可以在不使用包含列的情况下构造失败的示例，如添加的回归测试所示。因此，回溯补丁到所有支持的分支。根据 bug #17350，来自 Louis Jachiet。讨论：https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org https://git.postgresql.org/pg/commitdiff/4ace456776524839ef3279ab0bad8a2c9f6cc2a7

Amit Kapila 提交

Michaël Paquier 提交

Bruce Momjian 已推送

Fujii Masao 提交

Thomas Munro 推送

Daniel Gustafsson 提交

Álvaro Herrera 提交

Andres Freund 提交

Magnus Hagander 已推送