安全版本 13.4、12.8、11.13、10.18、9.6.23 和 14 Beta 3 已发布，请尽快升级。9.6 系列将于 2021 年 11 月 11 日停止接收修复。请现在计划主要版本升级。
行为准则委员会正在寻找新成员，任期为 1-3 年。
pgbouncer 1.16.0，PostgreSQL 的连接池和更多功能已发布
https://archives.postgresql.org/pgsql-jobs/2021-08/
PostgreSQL 星球：https://planet.postgresql.org/
本周 PostgreSQL 每周新闻由 David Fetter 为您带来
请在太平洋标准时间下午 3:00 之前（PST8PDT）将新闻和公告提交至 david@fetter.org。
Bruce Momjian 推送
David Rowley 推送
为 MSVC x86_64 版本添加 POPCNT 支持。02a6a54ec 添加了代码，以便在我们的许多常见平台上可以使用 POPCNT 指令。在这里，我们对 x86_64 机器的 MSVC 执行相同的操作。MSVC 用于 popcnt 的内部函数似乎与 GCC 的内部函数不同，因为它们总是会发出 popcnt 指令。在 GCC 中，行为将取决于源文件是否使用 -mpopcnt 编译。因此，MSVC 内部函数已归入 pg_popcount*_asm 函数，但这使得该函数的名称无效，因此我们将其重命名为 pg_popcount*_fast()。作者：David Rowley 审核人：John Naylor 讨论：https://postgr.es/m/CAApHDvqL3cbbK%3DGzNcwzsNR9Gi%2BaUvTudKkC4XgnQfXirJ_oRQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/2e281249af6c702fd057f34150fd9ac6cb8c7a8b
在 EXPLAIN 中对 queryid 使用 ExplainPropertyInteger。这样可以节省几行代码。此外，添加注释以提及为什么我们使用 ExplainPropertyInteger 而不是 ExplainPropertyUInteger（考虑到 queryid 是 uint64 类型）。作者：David Rowley 审核人：Julien Rouhaud 讨论：https://postgr.es/m/CAApHDvqhSLYpSU_EqUdN39w9Uvb8ogmHV7_3YhJ0S3aScGBjsg@mail.gmail.com 回溯：14，最初添加此代码的位置 https://git.postgresql.org/pg/commitdiff/4a3d806f38f99fecf8f2a2bf7990a7ebea9b6c63
文档：修复有关 VACUUM 内存限制的误导性声明。在 ec34040af 中，我添加了一个说明，即对于 vacuum 而言，将 maintenance_work_limit 设置为高于 1GB 的值毫无意义，但这并不正确，因为 ginInsertCleanup() 还会查看 VACUUM 期间 maintenance_work_mem 的设置值，并且该值不限于 1GB。在这里，我尝试更清楚地表明，限制仅与我们在 VACUUM 期间可以收集的死元组标识符的数量有关。我还向 autovacuum_work_mem 添加了一个注释，以提及此限制。我没有在 ec34040af 中这样做，因为我对仅将该 GUC 的最大值限制为 1GB 有一些错误的看法。作者：David Rowley 讨论：https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com 回溯：9.6，与 ec34040af 相同 https://git.postgresql.org/pg/commitdiff/deb6ffd4fdeb589de7a13ac1791380a7138cf59f
从 MSVC 构建脚本中删除一些特殊情况。在这里，我们添加了对 Makefiles 的额外解析，以确定何时添加对 libpgport 和 libpgcommon 的引用。我们还通过添加非常基本的逻辑来实现 Makefile 规则来删除添加当前 contrib_extrasource 的需求，这些规则会在 Makefile 中为给定的 .o 文件存在时添加 .l 和 .y 文件。这只是对 Makefiles 的一些非常基本的额外解析，目的是尝试使使用 make 和 MSVC 构建之间的构建更加一致。这恰好适用于我们当前的 Makefiles 的布局方式，但如果将来有人选择在 Makefile 中执行我们没有解析支持的操作，则很容易被破坏。我们到时候再解决这个问题。作者：David Rowley 讨论：https://postgr.es/m/CAApHDvoPULi5JW3933NxgwxOmu9Ncvpcyt87UhEHAUX16QqmpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/76ad24400d73fa10d527844d50bedf7dacb1e87b
修复 simplehash.h 中不正确的哈希表大小调整代码。这修复了 simplehash.h 中的一个 bug，该 bug 导致当哈希表增长到 SH_MAX_SIZE (2^32) 时使用了不正确的大小掩码。当哈希表达到最大可能的桶数时，代码错误地将大小掩码设置为 0。这将导致始终尝试使用第 0 个桶，从而导致因冲突过多而尝试增长哈希表的无限循环。似乎 simplehash 表增长到这么大并不常见，因为此 bug 可以追溯到 v10，并且以前似乎没有人注意到它。但是，人们最有可能注意到它的地方可能是使用接近至少 2^31 组的内容执行大型内存哈希聚合。修复此 bug 后，代码现在可以正确地处理最多 98% 的 2^32 个组，并且在尝试向哈希表中插入更多项时，将失败并显示以下错误：错误：哈希表大小超出。但是，work_mem（或较新版本中的 hash_mem_multiplier）设置通常会导致哈希聚合在达到那么多组之前溢出到磁盘。我做的最小测试用例使用了超过 192GB 的 work_mem 设置来触发此 bug。simplehash 哈希表在其他一些地方使用，例如位图索引扫描，但是，哈希表的大小也限制为 work_mem，并且需要大约 16TB (2^31) 页的关系和非常大的 work_mem 设置才能触发此问题。使用较小的 work_mem 值，表将变得有损，并且永远不会增长到足以触发此问题。作者：Yura Sokolov 审核人：David Rowley、Ranier Vilela 讨论：https://postgr.es/m/b1f7f32737c3438136f64b26f4852b96@postgrespro.ru 回溯：10，添加 simplehash.h 的位置 https://git.postgresql.org/pg/commitdiff/37450f2ca9ad430d78673cc26816fc2085e65904
Amit Kapila 推送
Tom Lane 推送
尽可能避免确定正则表达式子表达式匹配项。鉴于我们的正则表达式引擎的工作方式，确定带括号的子表达式的精确匹配位置是一项相当耗时的任务，无论是在正则表达式编译时（我们必须为每个带括号的子表达式创建一个优化的 NFA）还是在运行时（确定精确的匹配位置需要费力的搜索）。到目前为止，我们很少尝试优化这种情况。此补丁标识了我们可以在编译时知道我们不需要知道子表达式匹配位置的情况，并教会正则表达式编译器不要为正则表达式中其他地方的后向引用未引用的括号对创建每个子表达式的正则表达式。（为了保留语义，我们显然仍然必须确定后向引用引用的匹配位置。）用户之前可以通过小心地尽可能编写“非捕获”括号来获得相同的结果，但是很少有人会这样做。讨论：https://postgr.es/m/2219936.1628115334@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0e6aa8747d439bb7f08f95e358f0509c50396785
让 regexp_replace() 在可行的情况下使用 REG_NOSUB。如果替换字符串不包含 \1...\9，则我们不需要子匹配位置，因此我们也可以在此处使用 REG_NOSUB 优化。已经对替换字符串进行了预扫描以查找反斜杠，因此将其扩展为检查数字，并重构以使其在编译正则表达式之前发生。同时，尝试通过使用 memchr() 而不是手写循环来加快预扫描速度。与正则表达式处理本身相比，这很可能会丢失在噪声中，但也许不是。在任何情况下，此编码都更短。此外，添加一些测试用例以改善 appendStringInfoRegexpSubstr() 的较差覆盖率。讨论：https://postgr.es/m/3534632.1628536485@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/18bac60ede44359a1e577df80aef196e371c902e
修复使用“char”类型和 <!--<= 运算符的 btree_gin 索引扫描失败的问题。由于对“char”类型是有符号还是无符号的混淆，“col < 'x'”或“col <= 'x'”等索引搜索的扫描将从索引的中间而不是左端开始，因此会错过许多或全部应查找的条目。幸运的是，这不是索引损坏的症状。只有搜索逻辑被破坏了，我们可以在没有不良副作用的情况下修复它。根据 Jason Kim 的报告。自 btree_gin 开始以来，这一直是错误的，因此回溯到所有受支持的分支。讨论：https://postgr.es/m/20210810001649.htnltbh7c63re42p@jasonk.me https://git.postgresql.org/pg/commitdiff/a6bd28beb0639d4cf424e961862a65c466ca65bf
在 s_lock.h 中添加 RISC-V 自旋锁支持。与 ARM 的情况类似，只需使用 gcc 的 __sync_lock_test_and_set();，它将编译为 AMOSWAP.W.AQ，它会执行我们需要的操作。在某些时候，可能值得为 RISC-V 的原子操作做一些工作，但这对于可靠的端口来说应该足够了。回溯到所有受支持的分支，以防有人想在 RISC-V 上尝试它们。Marek Szuba 讨论：https://postgr.es/m/dea97b6d-f55f-1f6d-9109-504aa7dfa421@gentoo.org https://git.postgresql.org/pg/commitdiff/c32fcac56a212b4e6bb5ba63596f60a25a18109a
取消损坏 s_lock_test。提交 80abbeba2 显然没有费心检查此代码。此外，在 .gitignore 中列出生成的 executable（因此，自从有人尝试使用此代码以来已经过了很长一段时间）。在尝试 RISC-V 自旋锁补丁时注意到。鉴于此代码已被破坏 5 年而无人注意到，因此可能不值得回溯。 https://git.postgresql.org/pg/commitdiff/0a208ed63ffe50a8d9d7c0b33996ec01cc4fdef6
Andres Freund 推送
修复 BootstrapModeMain() 中的虚假断言。由于我在提交前“简化”了它，因此该断言始终为真。根据 Coverity 和 Tom Lane。 https://git.postgresql.org/pg/commitdiff/e12694523e7e4482a052236f12d3d8b58be9a22c
修复拼写错误。报告人：Michael Paquier michael@paquier.xyz-- 讨论：https://postgr.es/m/YRIlNQhLNfx555Nx@paquier.xyz https://git.postgresql.org/pg/commitdiff/1d5135f0043b32a7d9fdc66a9553c2078900e240
移除对不使用 BGWORKER_SHMEM_ACCESS 的后台工作进程的支持。自从引入后台工作进程后不久，在 EXEC_BACKEND / Windows 构建上，不使用共享内存访问的后台工作进程就已损坏，但没有报告。显然，它们不常用。问题在于，后台工作进程的启动需要在 EXEC_BACKEND 子进程中连接到共享内存。StartBackgroundWorker() 会分离未连接工作进程的共享内存，但在那时，我们已经初始化了引用共享内存的子系统。修复此问题并非完全简单，因此删除不连接到共享内存的选项似乎是最好的前进方向。在大多数用例中，连接到共享内存的优势远远大于劣势。由于目前为止没有关于此问题的报告，我们已决定不值得在旧版本中解决此问题。根据与 Alvaro Herrera、Robert Haas 和 Tom Lane 的讨论。作者：Andres Freund andres@anarazel.de 讨论：https://postgr.es/m/20210802065116.j763tz3vz4egqy3w@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/80a8f95b3bca6a80672d1766c928cda34e979112
Michaël Paquier 推送了
在 ALTER TABLE 中，在表重写结束时添加对对象访问钩子的调用。ALTER TABLE .. SET {LOGGED,UNLOGGED,ACCESS METHOD} 从不执行表级的对象访问钩子，这与 SET TABLESPACE 不一致。请注意，与 SET TABLESPACE 相反，这些命令的空操作情况被排除在外，因为这需要跟踪命令是否已被调用，但它们可能不执行物理重写。另一个值得注意的事情是，在重写结束时的物理文件交换会为交换操作创建的内部对象进行几次访问调用（例如，sepgsql 的测试会跳过内部对象），但这不会触发对执行操作的表的钩子。f41872d 在 ALTER TABLE 中添加了对 SET LOGGED/UNLOGGED 的支持，显然忘记了考虑这一点。根据我的检查，ddl.sql 中 sepgsql 的两个回归测试将使用此测试记录更多信息，buildfarm 成员 rhinoceros 将很快告知。但我不太确定它们的格式，因此尚未刷新它们。这可以算是一个 bug，但不会进行回溯，因为这可能会对任何使用对象访问钩子的人造成行为更改。报告者：Jeff Davis 讨论：https://postgr.es/m/YQJKV29/1a60uG68@paquier.xyz https://git.postgresql.org/pg/commitdiff/7b565843a94412395149c6add0cbfc21d2bca0d4
修复 sepgsql 的回归测试输出。差异是由 7b56584 引起的，针对涉及表重写的测试。根据 buildfarm 成员 rhinoceros。讨论：https://postgr.es/m/YRHxXcyFjPuPTZui@paquier.xyz https://git.postgresql.org/pg/commitdiff/1e3445237b861fee2524defde79428058d90c0d8
在 psql 中为 DECLARE .. ASENSITIVE 添加 tab 补全。此选项在 dd13ad9 中引入。作者：Shinya Kato 讨论：https://postgr.es/m/TYAPR01MB289665526B76DA29DC70A031C4F09@TYAPR01MB2896.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/e2ce88b58f151753b094f28bc387cebae865927c
避免在 ROLLBACK PREPARED 中不必要的共享失效。性能提升很小，但这使得逻辑与 AtEOXact_Inval() 更加一致。在这种情况下不需要其他失效，因为 PREPARE 已经负责发送任何本地失效。作者：Liu Huailing 审阅人：Tom Lane, Michael Paquier 讨论：https://postgr.es/m/OSZPR01MB6215AA84D71EF2B3D354CF86BE139@OSZPR01MB6215.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/710796f0542180cca18ee93889da692df642bdf2
Daniel Gustafsson 推送了
移除未使用的回归测试证书 server-ss。server-ss 证书包含在 e39250c64 中，但从未在 TLS 回归测试中使用，因此将其移除。作者：Jacob Champion 讨论：https://postgr.es/m/d15a9838344ba090e09fd866abf913584ea19fb7.camel@vmware.com https://git.postgresql.org/pg/commitdiff/152c2e0ae1a8d0ed810b2e833b536e64b91da0a6
禁用 pgcrypto 中的 OpenSSL EVP 摘要填充。pgcrypto 中的 PX 层正在为所有后端实现统一处理摘要填充。从 OpenSSL 3.0.0 开始，如果启用填充，DecryptUpdate 不会刷新最后一个块，因此我们显式禁用它，因为我们不使用它。一旦 OpenSSL 3 的构建场中进行了充分的测试，这将回溯到所有受支持的版本。审阅人：Peter Eisentraut, Michael Paquier 讨论：https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se https://git.postgresql.org/pg/commitdiff/318df802355924015d4d8f21859bc0ef7a348970
为没有加载旧版库的 OpenSSL 3 添加备用输出。OpenSSL 3 引入了提供程序的概念以支持模块化，并将过时的密码移动到新的旧版提供程序。如果它没有在用户的 openssl.cnf 文件中加载，将会出现大量回归测试失败，因此添加覆盖这些失败的备用输出。此外，记录需要加载旧版提供程序才能将旧密码与启用 OpenSSL 的 pgcrypto 一起使用。一旦 OpenSSL 3 的构建场中进行了充分的测试，这将回溯到所有受支持的版本。审阅人：Michael Paquier 讨论：https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se https://git.postgresql.org/pg/commitdiff/72bbff4cd6eaf55239ccef79cec61766b5f8f1d2
修复 sslsni 连接参数布尔值检查。ssl 的检查只检查了参数是否存在，而不是参数的实际值。这意味着 SNI 扩展始终处于打开状态。通过检查 sslsni 的值，并且仅在 sslsni 被启用时才激活 SNI 扩展来修复。此外，更新文档以更符合其他布尔参数的记录方式。回溯到 14，即首次实现 sslsni 的版本。审阅人：Tom Lane 回溯到：14，添加了 sslni https://git.postgresql.org/pg/commitdiff/512f4ca6c6b5d2e3a1620288048ccaa712121e12
Heikki Linnakangas 推送了
John Naylor 推送了
修复哈希索引 README 中的语法错误。Dilip Kumar 讨论：https://postgresql.ac.cn/message-id/CAFiTN-tjZbuY6vy7kZZ6xO%2BD4mVcO5wOPB5KiwJ3AHhpytd8fg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/b05f7ecec44be22f6de703e5afdeb4ff3559315a
加速 Unicode 哈希函数的生成。Unicode 键集对生成完美哈希函数时使用的素数非常挑剔。调用者可能需要花费数秒时间迭代所有可能的候选乘数和种子的组合，以找到一个有效的组合。Unicode 更新通常每年只发生一次，但这仍然使 Unicode 脚本的开发和测试速度不必要地慢。要修复此问题，请在最内层循环中迭代素数。这不会更改任何已检入树的现有函数。https://git.postgresql.org/pg/commitdiff/ba958299eaf3d2f55bddb8efb037091d14ca6fd0
Tomáš Vondra 推送了
Thomas Munro 推送了
Michael Meskes 推送了
Peter Eisentraut 推送了