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

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

发布于 2022-01-05，PostgreSQL Global Development Group
PG 每周新闻

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日在芬兰赫尔辛基的 Hilton Helsinki Strand Hotel 举行。详情

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 为您呈现

请于太平洋时间周日下午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() 中的先前代码被保留用于短字符串以及快速路径返回错误时的情况。Review, performance testing, and additional hacking by: Heikki Linakangas, Vladimir Sitnikov, Amit Khandekar, Thomas Munro, and Greg Stark Discussion: https://www.postgresql.org/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 的有力使用场景，但即将到来的回归测试重构提供了足够的理由来添加它。Discussion: https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/33d3eeadb21d2268104840cfef6bc2226ddfc680

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

  • 移除回归测试脚本的动态转换，第2步。将所有 input/.source 和 output/.source 文件 "git mv" 到对应的 sql/ 和 expected/ 目录中。然后移除与动态转换相关的 pg_regress 和 Makefile 基础设施。Discussion: https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/dc9c3b0ff21465fa89d71eecf5e6cc956d647eca

  • 将 dblink 的 paths 测试脚本合并到其主测试中。不再需要启动单独的 psql 来创建这些函数。（主回归测试中也需要一些重构，但那需要更多思考。）Discussion: https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0e6e7f0806b2080cb31f33ff992ec2e4e35fa6f1

  • 添加缺失的 EmitWarningsOnPlaceholders() 调用。定义了任何自定义 GUC 的扩展在完成后应调用 EmitWarningsOnPlaceholders，以帮助捕获拼写错误。然而我们的许多 contrib 模块并未收到这个通知。同时也为具有 GUC 的 src/test/modules 扩展添加了此类调用。虽然这些并非真正面向用户，但它们应该展示良好的实践而非错误的实践。Shinya Kato Discussion: https://postgr.es/m/524fa2c0a34f34b68fbfa90d0760d515@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/1fada5d81e6769ded832a4ca62ee9371bac3fb9f

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

  • 重新考虑对扩展保留前缀设置的处理。提交 75d22069e 使 SET 在尝试设置之前由扩展保留的命名空间内的未识别参数时打印警告。但将其作为彻底的错误似乎更好，原因与我们不允许设置未识别的非限定参数名相同。无论如何，之前的实现是低效且有错误的。在更合适的位置执行检查，并更加小心地处理前缀匹配情况。Discussion: https://postgr.es/m/116024.1640111629@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2ed8a8cc5b634d33ea07d681c6b02213da07f792

  • 将 EmitWarningsOnPlaceholders() 重命名为 MarkGUCPrefixReserved()。这个名字更清楚地表达了它现在的功能。提供一个兼容性宏，使扩展不必立即转换到新名称。Discussion: https://postgr.es/m/116024.1640111629@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5609cc01c69b80f8788771dc6f5696a459469119

  • 撤回关于占位符警告/错误的更改。撤回提交 5609cc01c、2ed8a8cc5 和 75d22069e，直到我们有一个关于此功能在并行工作进程中如何工作的更完善方案。根据构建农场反馈。Discussion: 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 分配的结构中，这样我们就不会在每个非归档器进程中浪费几千字节的静态数据。添加 binaryheap_reset() 调用，以明确表示我们以空堆开始目录扫描。我认为不存在这样的活跃 bug，但这看起来很脆弱，而且这是非常廉价的保险措施。这是对提交 beb4e9ba1 的清理，因此不需要回溯移植。Discussion: 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: 通过消除子查询来实现小幅性能改进。用角色 OID 的本地查找替代 "username_subquery" 机制来获取角色名。PG 后端对 SELECT 输出列表中的标量 SubLinks 处理不够智能，因此这提供了小幅性能改进，至少在有多个用户的安装中是如此。无论如何，旧方法生成的 SQL 代码可读性也不好。同时，我移除了各种关于未能找到对象所有者的自定义警告消息，取而代之的是在本地查找函数中直接 fatal。据我所知，不再有任何理由将其视为目录损坏以外的任何情况，也确实没有理由让翻译人员处理十几条不同的消息，而一条就够了。（如果事实证明 fatal() 确实是个坏主意，我们可以退回到发出 pg_log_warning() 并返回空字符串，产生与之前相同的行为，只是更一致。）还删除了一个完全不必要的子查询来检查序列关系的 pg_depend 状态：我们在 FROM 子句中已经有一个 LEFT JOIN 来获取感兴趣的行。Discussion: 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。Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc https://git.postgresql.org/pg/commitdiff/3e6e86abca0138abd7265306beb6346dc2d9e221

  • 修复非所有索引列都可返回时的仅索引扫描计划。如果索引同时具有可返回和不可返回的列，且其中一个不可返回的列是使用可返回列中的 Var 的表达式，那么返回该表达式的查询可能会生成一个试图读取不可返回列的仅索引扫描计划，而不是按预期从可返回列重新计算表达式。修复方法是重新定义 IndexOnlyScan 计划节点的 "indextlist" 列表，使其包含 null Consts 来替代任何不可返回的列。这通过防止 setrefs.c 错误匹配到此类条目来解决问题。执行器对此很满意，因为它只关心条目的暴露类型，而 ruleutils.c 也不关心，因为正确的计划不会引用这些条目。我考虑了一些其他方法来防止 setrefs.c 做错误的事情，但这种方式似乎最好，因为 (a) 它允许非常局部化的修复，(b) 它使 indextlist 结构在许多情况下更紧凑，(c) indextlist 现在更忠实地表示索引 AM 实际产生的内容，即对任何不可返回的列产生 null。自从我们引入了包含列之后，这个问题更容易触发，但没有包含列也可以构造失败的示例，如添加的回归测试所示。因此，回溯移植到所有支持的分支。根据 Louis Jachiet 的 bug #17350。Discussion: 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 推送了：