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

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

由 PWN 于 2022-01-05 发布
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

1 月份的 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 日举行。 CFP 现已开放。

PostgreSQL 新闻

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() 中的先前编码会保留用于短字符串以及快速路径返回错误时。审核、性能测试和附加黑客攻击：Heikki Linakangas、Vladimir Sitnikov、Amit Khandekar、Thomas Munro 和 Greg Stark 讨论：https://postgres.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

  • 删除回归测试脚本的动态转换，步骤 1。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

  • 删除回归测试脚本的动态转换，步骤 2。“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

  • 添加缺少的 EmitWarningsOnPlaceholders() 调用。任何定义自定义 GUC 的扩展都应在执行此操作后调用 EmitWarningsOnPlaceholders，以帮助捕获拼写错误。但是，我们的许多 contrib 模块都没有收到这方面的消息。此外，向具有 GUC 的 src/test/modules 扩展添加此类调用。虽然这些实际上不是面向用户的，但它们应该说明好的做法而不是错误的做法。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 如果您尝试在先前由扩展保留的命名空间中设置无法识别的参数，则会使 SET 打印警告。但出于与我们不允许您设置无法识别的非限定参数名称的原因相同，最好将其作为直接错误。无论如何，前面的实现效率低下且存在错误。在更合适的位置执行检查，并更加注意前缀匹配的情况。讨论：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'd 结构中，以便我们不会在每个非归档进程中浪费几千字节的静态数据。添加一个 binaryheap_reset() 调用以明确我们从一个空堆开始目录扫描。我不认为存在任何类似的实时错误，但这似乎很脆弱，而且这是非常便宜的保险。清理提交 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。这只是一个潜在的错误，因为 pg_backup_archiver.c 会在稍后过滤掉 ArchiveEntry；但是它们在仅数据转储中浪费了周期，并且这种遗漏可能会在将来成为一个实际的错误。无论如何，让一些 dumpFoo 函数这样做而另一些函数不这样做是不好的。基于同样的理由，使 dumpPublicationNamespace 遵循与其他所有 dumpFoo 函数相同的模式来检查 DUMP_COMPONENT_DEFINITION 标志。（自 5209c0ba0 以来，如果未设置该标志，我们甚至不会到达这里，因此检查它现在只是例行公事。但这种情况可能不会永远如此。）由于这只是外观上的和/或面向未来的更改，因此无需进行向后移植。https://git.postgresql.org/pg/commitdiff/5e65df64d631257ce60016bec0aca43f042b1d33

  • pg_dump：通过消除子查询来提高小的性能。放弃“username_subquery”机制，转而从角色 OID 本地查找角色名称。PG 后端在 SELECT 输出列表中的标量子链接方面不是很聪明，因此这提供了小的性能提升，至少在有多个用户的安装中是这样。无论如何，旧方法并没有生成特别可读的 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 的表达式，该 Var 位于可返回的列中，那么返回该表达式的查询可能会导致仅索引扫描计划，该计划尝试读取不可返回的列，而不是像预期那样从可返回的列重新计算表达式。为了修复，将 IndexOnlyScan 计划节点的“indextlist”列表重新定义为包含空 Consts，以代替任何不可返回的列。这通过阻止 setrefs.c 错误地匹配到此类条目来解决问题。执行器很高兴，因为它只关心条目的公开类型，并且 ruleutils.c 不关心，因为正确的计划不会引用这些条目。我考虑了一些其他方法来防止 setrefs.c 做错事，但这种方法似乎很好，因为 (a) 它允许非常局部的修复，(b) 它在许多情况下使 indextlist 结构更紧凑，并且 (c) indextlist 现在更忠实地表示索引 AM 实际将产生的内容，即对于任何不可返回的列都为空。自从我们引入包含列以来，这更容易发生，但可以构造失败的示例而无需它，如添加的回归测试所示。因此，向后移植到所有受支持的分支。根据 Louis Jachiet 的错误 #17350。讨论：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 推送