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

PostgreSQL 每周新闻 - 2021年11月14日

发布于 2021-11-15，PostgreSQL Global Development Group
PG 每周新闻

PostgreSQL 每周新闻 - 2021年11月14日

PostgreSQL 14.1、13.5、12.9、11.14、10.19 和 9.6.24 已发布。 这是 9.6 系列的最终版本，如果您还没有制定升级计划，请尽快行动。

PostgreSQL 产品新闻

Pgpool-II 4.3 beta1，一个用于 PostgreSQL 的连接池和语句复制系统， 已发布

Odyssey 1.2，一个用于 PostgreSQL 的多线程连接池，已发布。 https://github.com/yandex/odyssey/releases

pgbouncer 1.16.1，一个用于 PostgreSQL 的连接池及更多功能的工具， 已发布

11月 PostgreSQL 招聘信息

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

PostgreSQL 新闻报道

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

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

请在太平洋标准时间每周日下午3:00之前将新闻和公告提交至 david@fetter.org。

已应用的补丁

David Rowley 推送了：

Tom Lane 推送了：

  • 拒绝 SSL 或 GSS 加密握手后的多余数据。服务器在从客户端套接字读取数据时会收集最多一个缓冲区大小的数据。当在启动期间请求 SSL 或 GSS 加密时，与初始请求消息一起接收的任何额外数据会保留在缓冲区中，并在加密握手完成后被视为已解密的数据。因此，具有向 TCP 连接注入数据能力的中间人攻击者可以在本应受加密保护的数据库会话开始时插入一些明文数据。这可能被滥用来向服务器发送伪造的 SQL 命令，尽管这仅在服务器不要求任何身份验证数据时才有效。（然而，依赖 SSL 证书认证的服务器可能确实不会要求。）修复方法是：如果在加密握手后内部缓冲区不为空，则抛出协议违规错误。感谢 Jacob Champion 报告此问题。安全性：CVE-2021-23214 https://git.postgresql.org/pg/commitdiff/28e24125541545483093819efae9bca603441951

  • libpq：拒绝 SSL 或 GSS 加密握手后的多余数据。libpq 在从套接字读取数据时会收集最多一个缓冲区大小的数据。当在启动期间请求 SSL 或 GSS 加密时，与服务器的是/否回复一起接收的任何额外数据会保留在缓冲区中，并在加密握手完成后被视为已解密的数据。因此，具有向 TCP 连接注入数据能力的中间人攻击者可以在本应受加密保护的数据库会话开始时插入一些明文数据。这可能被滥用来向客户端的前几个查询注入伪造的响应，尽管 libpq 行为的其他细节使这比听起来更难实现。另一种攻击方式是窃取客户端的密码或会话早期可能发送的其他敏感数据。已证明这在受 CVE-2021-23214 影响的服务器上是可行的。修复方法是：如果在加密握手后内部缓冲区不为空，则抛出协议违规错误。感谢 Jacob Champion 报告此问题。安全性：CVE-2021-23222 https://git.postgresql.org/pg/commitdiff/160c0258802d10b0600d7671b1bbea55d8e17d45

  • 修复不正确的格式占位符。根据 buildfarm 警告。 https://git.postgresql.org/pg/commitdiff/b0cf5444f9a8d915b2e9b44790025f17a7dc107f

  • 修复 026_overwrite_contrecord.pl 测试中的不稳定性。我们在较慢的 buildfarm 机器上看到了此测试的间歇性失败，我认为这可以通过假设 autovacuum 产生了一些额外的 WAL 来解释。禁用 autovacuum 以使其稳定。顺便说一下，使用字符串比较而非数字比较来比较 WAL 文件名。目前并不重要，但它们是十六进制字符串而非十进制... 讨论： https://postgr.es/m/1372189.1636499287@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b66767b56b1cd082f3499a7e5a21b480dd004f51

  • 文档：改进逻辑复制 Type 消息的协议规范。protocol.sgml 记录了 Type 消息的布局，但在其他方面完全遗漏了，未能解释它们是什么、何时发送以及有什么用处。同时，对 Relation 消息的描述做了一些文字编辑。顺便调整了 apply_handle_type() 的注释，使其更清楚地表明我们选择在收到 Type 消息时不做任何事情，而不是我们认为它完全没有用处。源自 Stefen Hillman 的问题。讨论： https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c3b33698cf88550b017620f73b94b53029897f39

  • 对 socklen_t 回退使用 unsigned int 而非 int。选择哪个作为更好的默认假设确实难以决定。然而，在我们 buildfarm 中的机器中，唯一依赖回退 socklen_t 定义的是古老的 HPUX，而在该平台上 unsigned int 是正确的选择。对 ee3a1a5b6 的微调。讨论： https://postgr.es/m/1440792.1636558888@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/01ec41a5fe4aa590dde18a2c551432aa1925caea

  • postgres_fdw：在有限情况下抑制常量的类型转换。在反解析 "remote_var OP constant" 形式的表达式时，我们通常会对常量应用类型转换，以确保远程解析器认为其类型与我们一致。然而，这样做通常是不必要的，而且如果用户故意将本地列声明为与远程列不同的类型，就会导致问题。一个合理的用例是使用 text 来表示远程端的 enum 类型。对此类列的比较将被发送为 "var = 'foo'::text"，这在远程端会失败，因为没有 enum = text 运算符。但如果我们简单地省略显式类型转换，比较操作将完全按照用户的期望执行。可以在不产生重大语义问题风险的情况下做到这一点，方法是依赖长期以来的解析器启发式规则："如果运算符的一个操作数是 unknown 类型，而另一个具有已知类型，则假设 unknown 操作数也是该类型"。因此，此补丁仅在以下情况下省略类型转换：(a) 运算符输入在本地具有相同类型；(b) 常量将打印为字符串字面量或 NULL，两者初始都被视为 unknown 类型；(c) 非 Const 输入是普通的外部 Var。规则 (c) 保证远程解析器将知道非 Const 输入的类型；此外，它意味着如果此类型转换省略确实导致了语义意外，那只能发生在本地列与远程列类型不同的情况下。这种情况之前也不能保证正常工作，而此补丁应该为此类情况带来净可用性提升。一个让我（tgl）仍然略感不安的点是，在判断非 Const 输入是否为普通 Var 时，我们会忽略隐式 RelabelType。这使得论证远程端应将 Const 解析为与其 Var 相同类型变得有些牵强，因为此时我们的 Const 与 Var 类型并不相同。然而，如果我们不这样做，当用户选择使用 varchar 而非 text 来表示某些远程列时，此技巧将无法按预期工作。这看起来很有用，所以暂时先这样做。如果出现任何问题，我们可能需要放弃忽略 RelabelType 的部分。Dian Fay 编写，我进行了审查和讨论。讨论： https://postgr.es/m/C9LU294V7K4F.34LRRDU449O45@lamia https://git.postgresql.org/pg/commitdiff/f8abb0f5e114d8c309239f0faa277b97f696d829

  • 使 psql 的 \password 默认使用 CURRENT_USER 而非 PQuser(conn)。文档明确指出 \password 默认对"当前用户"操作。但它实际操作的（或尝试操作的）是用于登录当前会话的用户名。如果之后执行了 SET ROLE 或 SET SESSION AUTHENTICATION，这两者并不相同。除了可能的意外因素外，当前角色很可能没有权限设置原始角色的密码。修复方法是使用 "SELECT CURRENT_USER" 获取要操作的角色名。（此语法至少可以在 7.0 以上的服务器上使用。）此外，为了减少混淆，在密码提示中包含将被操作的角色名。与文档的差异使这成为一个 bug，因此回溯到所有支持的分支。补丁由我编写；感谢 Nathan Bossart 的审查。讨论： https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d6eb5a0c258d3da5471814bcc6ed6498129fee16

Robert Haas 推送了：

  • tar 归档未终止问题的最小修复。提交 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 改进了 pg_basebackup 解析 tar 归档的能力，但也安排为仅在需要修改归档内容时才解析它们。这是一个问题，因为服务器实际上并未终止 tar 归档。当新的解析逻辑被启用时，pg_basebackup 会正确终止 tar 文件，但当跳过解析时，pg_basebackup 只会写入从服务器收到的内容，这意味着终止符缺失。大多数版本的 tar 愿意忽略缺失的终止符，但 AIX buildfarm 机器不会。通过发明一种新的 bbstreamer 来修复，它只是盲目地添加终止符，并在我们不解析 tar 归档时使用它。讨论： http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/57b5a9646d97a3e8a5b6b6d86b375cc8da6ac85c

  • 让服务器正确终止 tar 归档。早期版本的 PostgreSQL 中的 pg_basebackup 想要编辑 tar 归档，但不够智能以正确解析它们。服务器通过不添加应该结束 tar 文件的两个零字节块来为客户端简化了事情，将此任务留给客户端完成。但自从提交 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 以来，我们不再需要这个 hack，因为 pg_basebackup 现在更智能了，即使 tar 文件被正确终止也能解析！所以将服务器改为始终正确终止 tar 文件。旧版本的 pg_basebackup 无法与新服务器通信，所以不存在兼容性问题。在 pg_basebackup 端，如果与旧服务器通信，我们仍然需要添加终止的零字节，但与 v15+ 服务器通信时则不需要。希望在某个时候我们能够移除一些这样的兼容性代码，但现在最好保留它。顺便为 bbstreamer_tar.c 添加了文件头注释，使这里的逻辑更清晰。讨论： http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5a1007a5088cd6ddf892f7422ea8dbaef362372f

  • 进一步清理 'ThisTimeLineID'。在 XLogCtlData 中，将结构成员 ThisTimeLineID 重命名为 InsertTimeLineID，并更新注释以明确说明它只应在恢复完成后设置。在 StartupXLOG 中，用新的局部变量 replayTLI 和 newTLI 替换局部变量 ThisTimeLineID 和 PrevTimeLineID。在旧方案中，ThisTimeLineID 是重放 TLI，直到我们创建新时间线，之后重放 TLI 在 PrevTimeLineID 中。现在，replayTLI 在整个函数中始终是我们最后重放 WAL 的 TLI，而 newTLI 要么是该值，要么是提升时创建的新时间线。删除了 recoveryTargetTimeLineGoal 及相关声明上方的一些误导性注释。这些注释已经变得不正确，不仅因为 ThisTimeLineID 作为变量已经不存在了，还因为 rmgr 代码不关心 ThisTimeLineID，自从页面头中的 TLI 字段被重新用于存储页面校验和以来就是如此。在 GetFlushRecPtr 中添加注释说明它只应在正常运行时使用，以及一个断言来验证这一点。基于 Michael Paquier 的一些想法和我自己的想法。Michael Paquier 也进行了审查。讨论： http://postgr.es/m/CA+TgmoY1a2d1AnVR3tJcKmGGkhj7GGrwiNwjtKr21dxOuLBzCQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a27048cbcb582056bfbf15aa2f898b4a3ec74304

  • 修复 basebackup.c 中断言的思维错误。提交 5a1007a5088cd6ddf892f7422ea8dbaef362372f 试图引入一个断言，要求块大小至少是 tar 块大小的两倍，但我搞错了数学。我的错误在线下被报告给我。 https://git.postgresql.org/pg/commitdiff/10eae82b27cebbb9586cda8baf8e3226496891d0

  • 改进存在大量状态文件时 pgarch_readyXlog() 的性能。目前，每次要归档文件时都会扫描 archive_status 目录。当存在大量状态文件时（例如因为 archive_command 长时间失败），这些目录扫描会变得非常缓慢。经过此更改，归档器在每次目录扫描期间会记住多个待归档文件，从而加快速度。为确保时间线历史文件尽快被归档，XLogArchiveNotify() 会在创建 .ready 文件后立即强制归档器执行新的目录扫描。Nathan Bossart 编写，经过涉及许多人的长时间讨论。我不清楚这些人中究竟谁审查了这个特定补丁。讨论： http://postgr.es/m/CA+TgmobhAbs2yabTuTRkJTq_kkC80-+jw=pfpypdOJ7+gAbQbw@mail.gmail.com 讨论： http://postgr.es/m/620F3CE1-0255-4D66-9D87-0EADE866985A@amazon.com https://git.postgresql.org/pg/commitdiff/beb4e9ba1652a04f66ff20261444d06f678c0b2d

Amit Kapila 推送了：

Fujii Masao 推送了：

Michaël Paquier 推送了：

  • 为一致性起见，使一些注释使用术语 "ProcSignal"。procsignal.c 中的周围代码倾向于使用 "ProcSignal" 而非 "procsignal"。作者：Bharath Rupireddy 讨论： https://postgr.es/m/CALj2ACX99ghPmm1M_O4r4g+YsXFjCn=qF7PeDXntLwMpht_Gdg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4cd046c203bbca2955182f78eabc06e831ffdbb1

  • 改进 XLogReadRecord() 某些调用者的错误消息。与逻辑解码相关的几个代码路径（WAL sender、slot advancing 等）使用 XLogReadRecord()，依赖 walreader.c 在失败时生成的错误消息。所有这些消息都没有上下文，使得即使这些情况不应该发生也更难发现错误来源。XLogReadRecord() 的所有其他调用者已经这样做了。审查者：Kyotaro Horiguchi 讨论： https://postgr.es/m/YYnTH6OyOwQcAdkw@paquier.xyz https://git.postgresql.org/pg/commitdiff/c9c401a5e13accc4a3a775e3feeabdc5940c9178

  • 清理使用 clang-12 及更高版本编译 PL/Perl 时产生的警告。clang-12 引入了 -Wcompound-token-split-by-macro，由于其与上游 Perl 的交互，在构建 PL/Perl 时会产生大量警告。此提交在 ./configure 时向 CFLAGS 添加了一个 -Wno 选项（如果编译器支持该标志）以消除所有这些警告。上游 perl 已修复此问题，但需要一些时间才能扩散到整个 buildfarm，而且我们注意到一些机器通过额外的 -Werror 来帮助检测不正确的占位符（参见 b0cf544）会很有用，dangomushi 就是其中之一。审查者：Tom Lane 讨论： https://postgr.es/m/YYr3qYa/R3Gw+Sbg@paquier.xyz 回溯至：10 https://git.postgresql.org/pg/commitdiff/9ff47ea414c4e6ace347fc4e59866e38b9bbceaf

  • 修复使用空输入时 unicode 字符串规范化中的缓冲区溢出。PostgreSQL 13 及更新版本直接受到影响，通过 SQL 函数 normalize()，如果在使用 NFC 和 NFKC 重新组合字符串后输入空字符串，该函数的调用将在其分配区域之后写入一个字节。较旧版本（v10~v12）不直接受此问题影响，因为使用规范化的唯一代码路径是 SCRAM 认证中的 SASLprep，它禁止空字符串的情况，但让我们使代码更健壮，以便覆盖此函数的任何外部调用者。选择修复此问题的解决方案很简单，即在发现分解后的字符串为空时添加快速退出路径。这只会在空字符串的情况下发生，因为在最底层，如果代码点在分解表中没有条目或其分解大小为 0，则代码点将被分解为其自身。在 v13~ 中添加了一些测试来覆盖此问题。注意，自从此功能在 2991ac5 引入以来，空字符串始终被认为是已规范化的（语法 "IS NF[K]{C,D} NORMALIZED"，通过 SQL 函数 is_normalized()），适用于所有允许的操作（NFC、NFD、NFKC 和 NFKD）。此行为未更改，但在 v13~ 中添加了一些测试来验证。我还顺便检查了 src/common/unicode/ 中的 "make normalization-check"（在 13~ 中有效，在较旧的稳定分支中独立于此提交而中断）。发布说明应仅提及此提交适用于 v13~。报告者：Matthijs van der Vleuten 讨论： https://postgr.es/m/17277-0c527a373794e802@postgresql.org 回溯至：10 https://git.postgresql.org/pg/commitdiff/098c134556664d37b78ae87853a82f4a9d23a2c8

  • 修复查询 pg_stat_slru 时的内存溢出。pgstatfuncs.c 中的 pg_stat_get_slru() 在完成扫描条目时会指向数组 PgStat_SLRUStats 末尾之后的一个元素。这没有直接后果，因为没有从额外的内存区域读取数据，但静态分析器在这里会正确地发出警告。所以让我们保持代码整洁。同时，在系统视图保留区域中添加了一个回归测试。报告者：Alexander Kozhemyakin，通过 AddressSanitizer 作者：Kyotaro Horiguchi 讨论： https://postgr.es/m/17280-37da556e86032070@postgresql.org 回溯至：13 https://git.postgresql.org/pg/commitdiff/a45ed975c58fde7303eeae488b313bf0314383f7

Peter Eisentraut 推送了：

Jeff Davis 推送了：

Álvaro Herrera 推送了：

Peter Geoghegan 推送了：

Noah Misch 推送了：

Andrew Dunstan 推送了：

Daniel Gustafsson 推送了：