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

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

发布于 2021-10-24，PostgreSQL Global Development Group
PG 每周新闻

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 导出器， 已发布

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

PostgreSQL 十月招聘信息

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

PostgreSQL 新闻报道

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

本周 PostgreSQL 每周新闻由 David Fetter 为您呈现

请于太平洋时间每周日下午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 的流起始计算方法。文档对如果在 pg_receivewal 命令定义的本地归档目录中找不到任何内容时用于 WAL 流传输的起始 LSN 描述不够精确，因此在此问题上更加详尽。 从同一作者的更大补丁中提取。 作者：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 文件错误消息打印中的 bug。如果无法解析 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 目标以便于使用。用于 TLS 测试的证书和密钥对的 Makefile 处理变得相当难以使用。在不需要重新生成所有内容的情况下添加新证书太复杂了。此补丁重构了 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 中更改为使用当前时间戳。因此测试框架必须使用"openssl x509"查询证书的序列号，它以十六进制格式发出序列号。将序列号转换为整数格式以匹配 pg_stat_ssl 中的内容需要 64 位 Perl。这添加了在使用 32 位 Perl 进行测试时检查整数的回退。 根据构建农场成员 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