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

PostgreSQL 每周新闻 - 2021 年 10 月 24 日

发布于 2021-10-24，作者：PWN
PWN

PostgreSQL 每周新闻 - 2021 年 10 月 24 日

PostgreSQL 产品新闻

JDBC 42.3.0 已发布。

pgmetrics 1.12，一个用于 PostgreSQL 指标的命令行工具，已发布。

StackGres 1.0.0，一个在 Kubernetes 上运行 PostgreSQL 的平台，已发布。https://stackgres.io/

pgexporter 0.2.0，一个 PostgreSQL 的 Prometheus exporter，已发布

pgAdmin4 6.1，一个用于 PostgreSQL 的 Web 和原生 GUI 控制中心，已发布。

10 月份的 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Michaël Paquier 提交

  • 修复 psql 新 TAP 测试的可移植性问题。c0280bc 和 d9ddc50 在 001_basic.pl 中添加的测试引入了直接调用 psql 的命令，使其对环境敏感。一个问题是这些命令忘记了 -X 来不使用本地 .psqlrc，导致所有这些测试失败，如果 psql 无法正确解析该文件。TAP 测试应设计成独立运行，不依赖于运行它们的环境。由于 PostgresNode::psql 已经提供了这些新测试所需的所有设施，因此切换到它而不是直接调用 psql 命令（当需要与后端交互时）。稍微重构了测试，以便能够检查 stdout 和 stderr 的预期模式，保持与之前相同的覆盖范围。报告人：Peter Geoghegan 讨论：https://postgr.es/m/CAH2-Wzn8ftvcDPwomn+y04JJzbT=TG7TN=QsmSEATUOW-ZuvQQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/384f1abdb9b0f669279fcd57ba2173eb31724740

  • 在事务中止期间正确重置快照导出状态。在创建复制槽的过程中，同一事务中生成的 ERROR（与创建待导出快照的事务相同）会导致后端处于不一致状态，因为关联的静态导出快照状态在事务中止时未被重置，而仅在 WAL 发送器收到的后续命令中被重置（该命令是在复制槽创建时创建此快照的）。如果该会话尝试再次导出快照（例如在创建复制槽时），这将触发不一致失败。请注意，快照导出不能在事务块中发生，因此无需担心重置子事务中止的状态。此外，这种不一致状态非常不可能暴露给用户。例如，一种可能发生的情况是在构建初始待导出快照时出现内存不足的错误。Dilip 在研究另一个补丁时发现了这个问题，该补丁导致此代码路径因与 HEAD 无关的原因而发生错误。作者：Dilip Kumar 审阅者：Michael Paquier, Zhihong Yu 讨论：https://postgr.es/m/CAFiTN-s0zA1Kj0ozGHwkYkHwa5U0zUE94RSc_g81WrpcETB5=w@mail.gmail.com 向后移植到：9.6 https://git.postgresql.org/pg/commitdiff/409f9ca4471331be0f77b665ff3a1836a41de5b3

  • 阻止对 ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (options) 进行操作。在具有列名的索引上运行此命令的语法在解析器中一直被授权，并且从未被文档化。自 911e702 以来，可以在 CREATE INDEX 时定义操作类参数，这实际上破坏了旧的 ALTER INDEX/TABLE 情况，其中 n_distinct 和 n_distinct_inherited 等关系级参数可以为索引定义（参见 76a47c0 及其讨论，该点仍然未被使用）。在 v13~ 中尝试这样做会导致索引变得不可用，因为有一个新的专用代码路径来加载操作类参数，而不是之前可用的关系级参数。请注意，可以通过手动目录更新来修复问题，以使关系恢复联机。此提交暂时禁用此命令，因为使用列名进行索引操作无论如何都没有意义，尤其是在索引表达式中名称是自动计算的情况下。未来正确支持此情况的一种方法是使用列号，就像 ALTER INDEX .. ALTER COLUMN .. SET STATISTICS 一样。分区索引已被阻止，但普通索引未被阻止。为两种情况添加了一些测试。ANALYZE 中有一些代码用于强制使用 n_distinct 用于索引表达式（如果定义了该参数），但目前将其删除，直到/如果支持此功能（请注意，索引级参数之前在 pg_dump 中也从未得到支持），因此这只是死代码。报告人：Matthijs van der Vleuten 作者：Nathan Bossart, Michael Paquier 审阅者：Vik Fearing, Dilip Kumar 讨论：https://postgr.es/m/17220-15d684c6c2171a83@postgresql.org 向后移植到：13 https://git.postgresql.org/pg/commitdiff/fdd88571454e2b00dbe446e8609c6e4294ca89ae

  • 修复 MSVC 与 OpenSSL 3.0.0 的构建。Visual Studio 的构建脚本将因检查第二个数字失败而无法正确检测到 3.0.0 的构建。这已根据需要进行了调整，允许构建完成。请注意，文档中提到的 OpenSSL 的 MSI 对于 Win32 和 Win64 库名称没有改变，因此此更改很简单。报告人：htalaco (通过 github) 审阅者：Daniel Gustafsson 讨论：https://postgr.es/m/YW5XKYkq6k7OtrFq@paquier.xyz 向后移植到：9.6 https://git.postgresql.org/pg/commitdiff/41f30ecc29c89285d3eecd435906c4e9cb048be4

  • 修复从模板数据库复制依赖项时 pg_shdepend 损坏。为新数据库使用带有需要复制的共享依赖项的模板数据库会导致 pg_shdepend 损坏，因为用于插入具有槽的值的索引号的计算存在一个偏移错误。此问题由 e3931d0 引入。监控代码的其他部分，没有类似的错误。报告人：Sven Klemm 作者：Aleksander Alekseev 审阅者：Daniel Gustafsson, Michael Paquier 讨论：https://postgr.es/m/CAJ7c6TP0AowkUgNL6zcAK-s5HYsVHVBRWfu69FRubPpfwZGM9A@mail.gmail.com 向后移植到：14 https://git.postgresql.org/pg/commitdiff/98ec35b0bbf6003e89fc06aa140e12fd90bbad47

  • 文档：描述 pg_receivewal 的流式传输开始的计算方法。文档关于 WAL 流式传输的起始 LSN 的说明不够精确，如果本地归档目录（使用 pg_receivewal 命令定义）中找不到任何内容，则在此问题上更详细地说明。摘录自同一作者的一大块补丁。作者：Ronan Dunklau, Michael Paquier 讨论：https://postgr.es/m/18708360.4lzOvYHigE@aivenronan 向后移植到：10 https://git.postgresql.org/pg/commitdiff/1e9475694b0ae2cf1204d01d2ef6ad86f3c7cac8

Heikki Linnakangas 提交

Álvaro Herrera 提交

Daniel Gustafsson 提交

  • 修复 pg_basebackup 和 pg_dump 中的 sscanf 限制。确保字符串解析受到目标缓冲区大小的限制。在 pg_basebackup 中，服务器发送的可用值限制为两个字符，因此没有溢出风险。在 pg_dump 中，缓冲区由 MAXPGPATH 限制，因此必须通过预处理器展开插入限制，并将缓冲区增加一个以容纳终止符。这里没有溢出风险，因为在这种情况下，扫描的缓冲区比目标缓冲区小。将 pg_basebackup 的修复回溯到引入它的 11 版本，并将 pg_dump 的修复回溯到 9.6。审阅者：Tom Lane 讨论：https://postgr.es/m/B14D3D7B-F98C-4E20-9459-C122C67647FB@yesql.se 向后移植到：11 和 9.6 https://git.postgresql.org/pg/commitdiff/1d7641d51a51aa00dff685022fab6c03be8f8af8

  • 修复 TOC 文件错误消息打印中的错误。如果 blob TOC 文件无法解析，错误消息将无法打印文件名，因为保存它的变量被解析的目标缓冲区所覆盖。当文件名解析失败时，错误将打印一个空字符串：“./pg_restore -d foo -F d dump pg_restore: error: invalid line in large object TOC file ""：..”，而不是预期的错误消息：“./pg_restore -d foo -F d dump pg_restore: error: invalid line in large object TOC file "dump/blobs.toc"：..”。通过重命名两个变量来修复，因为共享名称太通用，无法同时存储两者并传达变量的内容。回溯到 9.6。审阅者：Tom Lane 讨论：https://postgr.es/m/A2B151F5-B32B-4F2C-BA4A-6870856D9BDE@yesql.se 向后移植到：9.6 https://git.postgresql.org/pg/commitdiff/998d060f3db79c6918cb4a547695be150833f9a4

  • 重构 sslfiles Makefile 目标以方便使用。Makefile 处理 TLS 测试使用的证书和密钥对变得相当难以处理。添加新证书而无需重新生成所有内容过于复杂。此补丁重构了 sslfiles make 目标，使得添加新证书只需要添加一个 .config 文件，将其添加到 Makefile 的顶部，然后运行 make sslfiles。改进：- 文件依赖关系应已修复，CRL 目录除外。- 新证书的序列号基于当前时间，减少了冲突的可能性。- CA 索引状态按需创建，并在 Make 运行结束时自动清理。- `*.config` 文件现在是自包含的；一个证书需要一个配置文件而不是两个。- 重复代码减少，并随之减少了一些不必要的代码（和可能的复制粘贴错误）。- 所有配置文件都放在 conf/ 目录下。该目标已移动到其自己的 makefile 中，以避免与全局 make 设置冲突。作者：Jacob Champion pchampion@vmware.com 审阅者：Michael Paquier michael@paquier.xyz 讨论：https://postgr.es/m/d15a9838344ba090e09fd866abf913584ea19fb7.camel@vmware.com https://git.postgresql.org/pg/commitdiff/b4c4a00eada3c512e819e9163114a5ad1606bc7e

  • 修复 32 位 Perl 上的 SSL 测试。证书序列号生成在 b4c4a00ea 中更改为使用当前时间戳。因此，testharness 必须使用 "openssl x509" 来查询证书的序列号，该命令以十六进制格式发出序列号。将序列号转换为整数格式以匹配 pg_stat_ssl 中使用的格式需要一个 64 位兼容的 Perl。这在 32 位 Perl 测试时增加了回退到检查整数的选项。根据 buildfarm 成员 prairiedog 的故障。讨论：https://postgr.es/m/0D295F43-806D-4B3F-AB98-F941A19E0271@yesql.se https://git.postgresql.org/pg/commitdiff/0c04342b1d3dd5b24f795f94874163be8e21710e

Tom Lane 提交

Andres Freund 提交

Amit Kapila 提交

Andrew Dunstan 推送

Noah Misch 推送

  • 避免 RelationBuildDesc() 中影响 CREATE INDEX CONCURRENTLY 的竞态条件。CIC 和 REINDEX CONCURRENTLY 假定后端看到的目录更改不晚于每个后端下一次事务开始。当后端在运行 CIC 索引的 RelationBuildDesc() 过程中吸收了相关的无效化时，这种情况会失败。使用由此产生的索引的查询可能会悄悄地找不到行。通过使 RelationBuildDesc() 循环直到它完成而无需接受相关无效化来修复未来的索引构建。可能需要重新索引才能从过去的事件中恢复；REINDEX CONCURRENTLY 即可。回溯到 9.6（所有支持的版本）。Noah Misch 和 Andrey Borodin，由 Andres Freund 审阅（在早期版本中）。讨论：https://postgr.es/m/20210730022548.GA1940096@gust.leadboat.com https://git.postgresql.org/pg/commitdiff/fdd965d074d46765c295223b119ca437dbcac973

  • 修复针对最新准备事务的 CREATE INDEX CONCURRENTLY。提交 8a54e12a38d1545d249f1402f66c8cde2837d97c 的目的是修复此问题，并且在 PREPARE TRANSACTION 在 CIC 查找锁冲突之前完成时就足够了。否则，事情仍然会出错。与以前一样，在已启用准备事务的情况下使用 CIC 的集群中，使用由此产生的索引的查询可能会悄悄地找不到行。可能需要重新索引才能从过去的事件中恢复；REINDEX CONCURRENTLY 即可。通过使 CIC 等待任意近期的准备事务以及可能尚未 PREPARE TRANSACTION 的普通事务来修复未来的索引构建。作为其中的一部分，让 PREPARE TRANSACTION 在调用 ProcArrayClearTransaction() 之前将锁转移到其虚拟 PGPROC。回溯到 9.6（所有支持的版本）。Andrey Borodin，由 Andres Freund 审阅（在早期版本中）。讨论：https://postgr.es/m/01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru https://git.postgresql.org/pg/commitdiff/3cd9c3b921977272e6650a5efbeade4203c4bca2