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

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

发布于 2021-11-15，作者：PWN
PWN

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 为您带来

请在太平洋标准时间（PST8PDT）星期日下午 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”的表达式时，我们通常会对常量应用类型转换，以确保远程解析器认为它的类型与我们的一样。但是，这样做通常不是必需的，并且如果用户有意将本地列声明为与远程列不同的类型，则会导致问题。一个合理的用例是使用文本来表示远程端的枚举类型。对此类列的比较将作为 "var = 'foo'::text" 发送，这会在远程端崩溃，因为没有 enum = text 运算符。但是，如果我们只是省略显式类型转换，则比较将完全按照用户期望的方式执行。在没有重大语义问题风险的情况下，这是有可能的，这依赖于长期存在的解析器启发式方法，“如果运算符的一个操作数的类型未知，而另一个操作数的类型已知，则假设未知操作数的类型也相同”。因此，只有在以下情况下，此补丁才会省略类型转换：（a）运算符输入在本地具有相同的类型；（b）常量将作为字符串文字或 NULL 打印，这两者最初都视为未知类型；并且（c）非 Const 输入是普通的外部 Var。规则（c）保证远程解析器将知道非 Const 输入的类型；此外，它意味着如果此类型转换省略确实导致任何语义上的意外，那只能发生在本地列的类型与远程列的类型不同的情况下。无论如何，这都不能保证工作，并且此补丁应该代表这些情况的净可用性提升。我 (tgl) 仍然对忽略隐式 RelabelType 感到有些不舒服，当决定非 Const 输入是否是普通 Var 时。这使得很难争论远程应将 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 版本之后的服务器上有效。）此外，为了减少混淆，请在密码提示中包含将要操作的角色名称。与文档的差异使这是一个错误，因此回溯修复到所有受支持的分支。由我修复；感谢 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 之后，我们不再需要这个技巧了，因为 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 中，将局部变量 ThisTimeLineID 和 PrevTimeLineID 替换为新的局部变量 replayTLI 和 newTLI。在旧方案中，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 推送了

藤井雅雄推送了

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 发送器、槽推进等）相关的几个代码路径使用 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，当构建 PL/Perl 时，由于它与上游 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 中引入以来，对于所有允许的操作（NFC、NFD、NFKC 和 NFKD），空字符串一直被认为是归一化的（语法“IS NF[K]{C,D} NORMALIZED”，通过 SQL 函数 is_normalized()）。此行为保持不变，但在 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 推送