安全版本13.4、12.8、11.13、10.18、9.6.23 和14 Beta 3已发布请尽快升级。
9.6 系列将于 2021 年 11 月 11 日停止修复。现在就计划主要版本升级。
发布了 pgbouncer1.16.0 ，一个用于 PostgreSQL 的连接池和更多的连接。
Planet PostgreSQL
https : planet.postgresql.org/
由于提交 e462856a7a，pg_upgrade会自动创建一个脚本来更新扩展，所以提到它而不是 ALTER EXTENSION。https://git.postgresql.org/pg/commitdiff/d8a75b1308b133502ae3f02be485e9cd4eda9803为 MSVC x86_64 版本添加 POPCNT 支持。02a6a54ec 添加了代码以在 POPCNT 指令可用于我们的许多常见平台时使用。在这里，我们对 x86_64 机器的 MSVC 执行相同的操作。MSVC 的popcnt 内在函数似乎与 GCC 不同，因为它们似乎总是发出 popcnt 指令。在 GCC 中，行为将取决于源文件是否使用 -mpopcnt 编译。出于这个原因，MSVC 内在函数已被归入该pg_popcount*_asm函数，但是这样做会使该函数的名称无效，因此让我们将其重命名为 pg_popcount*_fast().
Discussion: https://postgr.es/m/CAApHDvqL3cbbK%3DGzNcwzsNR9Gi%2BaUvTudKkC4XgnQfXirJ_oRQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/2e281249af6c702fd057f34150fd9ac6cb8c7a8b在 EXPLAIN 中使用 ExplainPropertyInteger 作为 queryid。这节省了几行代码。还添加一条评论，说明为什么我们使用 ExplainPropertyInteger 而不是ExplainPropertyUInteger，因为 queryid 是 uint64 类型。Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/CAApHDvqhSLYpSU_EqUdN39w9Uvb8ogmHV7_3YhJ0S3aScGBjsg@mail.gmail.com Backpatch-through: 14, where this code was originally added https://git.postgresql.org/pg/commitdiff/4a3d806f38f99fecf8f2a2bf7990a7ebea9b6c63DOC:修复关于VACUUM 内存限制的误导性陈述。在 ec34040af 中，我添加了一个提及，将维护工作限制设置为高于 1GB 的真空是没有意义的，但这是不正确的，因为 ginInsertCleanup()还查看了 VACUUM 期间维护工作内存的设置，并且不限于1GB。在这里，我试图更清楚地说明，限制仅围绕我们在 VACUUM 期间可以收集的死元组标识符的数量。我还在 autovacuum_work_mem 中添加了一条注释以提及此限制。我没有在ec34040af 中这样做，因为我有一些关于将 GUC 的最大值限制为 1GB 的错误想法。Discussion:https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com Backpatch-through: 9.6, same as ec34040af https://git.postgresql.org/pg/commitdiff/deb6ffd4fdeb589de7a13ac1791380a7138cf59f在这里，我们添加了 Makefile 的额外解析，以确定何时添加对 libpgport 和 libpgcommon 的引用。我们还通过添加正弦非常基本的逻辑来实现Makefile 规则，当它们存在于 Makefile 中的给定 .o 文件时添加 .l 和 .y 文件，从而消除了添加当前 contrib_extrasource 的需要。这只是 Makefile 的一些非常基本的附加解析，以尝试在使用 make 和 MSVC 构建的构建之间保持更一致。这恰好适用于我们当前的 Makefile 的布局方式，但如果有人选择在 Makefile 中做一些我们没有解析支持的事情，它很容易在将来被破坏。 Discussion: https://postgr.es/m/CAApHDvoPULi5JW3933NxgwxOmu9Ncvpcyt87UhEHAUX16QqmpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/76ad24400d73fa10d527844d50bedf7dacb1e87b修复 simplehash.h 中不正确的哈希表大小调整代码。这修复了 simplehash.h 中的一个错误，该错误导致当哈希表增长到SH_MAX_SIZE (2^32) 时使用了不正确的大小掩码。当哈希表达到最大可能的桶数时，代码错误地将大小掩码设置为 0。这将导致总是尝试使用第 0 个存储桶，从而导致由于冲突过多而导致尝试增长哈希表的无限循环。看起来 simplehash 表变得这么大并不常见，因为这个错误可以追溯到 v10 并且之前似乎没有人注意到它。然而，可能人们最有可能注意到它会做一个大的内存哈希聚合，其中至少有 2^31 个组。此次修复后，该代码现在可以在多达 2^32 个组的 98% 内正常工作，并且在尝试将更多项目插入哈希表时将失败并显示以下错误：错误：超出哈希表大小但是，work_mem（或较新的 hash_mem_multiplier版本）设置通常会导致散列聚合在到达那么多组之前很久就溢出到磁盘。我所做的最小测试用例采用超过 192GB 的 work_mem 设置来解决该错误。simplehash 哈希表用于其他一些地方，例如位图索引扫描，但是，哈希表可以变成的大小也仅限于 work_mem，它需要大约 16TB (2^31) 页和一个非常大的 work_mem 设置来达到这个目的。使用较小的 work_mem 值，该表将变得有损并且永远不会增长到足以解决问题的程度。Reviewed-by: David Rowley, Ranier VilelaDiscussion: https://postgr.es/m/b1f7f32737c3438136f64b26f4852b96@postgrespro.ru Backpatch-through: 10, where simplehash.h was added https://git.postgresql.org/pg/commitdiff/37450f2ca9ad430d78673cc26816fc2085e65904修复 022_twophase_cascade.pl 中的错字。
Discussion:https://postgr.es/m/CAHut+Pta=zo8G1DWVVg-LU6b_JvHHCueC=AKVpKJOrwLzj9EZA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c9229d3d2b05b90fba32bd4afb5eb251b53b73be考虑到我们的正则表达式引擎的工作方式，确定括号子表达式的精确匹配位置是一项相当昂贵的任务，无论是在 regexp 编译时（我们必须为每个括号子表达式创建优化的 NFA）还是在运行时（确定精确匹配位置需要费力搜索）。到目前为止，我们几乎没有尝试优化这种情况。此补丁标识了我们在编译时知道不需要知道子表达式匹配位置的情况，并教导 regexp 编译器不要费心为括号对创建每个子表达式的正则表达式，这些括号对未被regexp 中的其他地方的 backref 引用。（为了保持语义，我们显然仍然需要确定 backref 引用的匹配位置。）在此之前，用户可以通过尽可能小心地编写“非捕获”括号来获得相同的结果，但很少有人为此烦恼。Discussion: 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() 覆盖率低的问题。Discussion: 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 开始以来，这一直是错误的，因此对所有支持的分支进行回补。Discussion: 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 上尝试它们。Discussion:https://postgr.es/m/dea97b6d-f55f-1f6d-9109-504aa7dfa421@gentoo.org https://git.postgresql.org/pg/commitdiff/c32fcac56a212b4e6bb5ba63596f60a25a18109aCommit 80abbeba2 显然没有费心检查这段代码。另外，在.gitignore 中列出生成的可执行文件（所以自从有人尝试这个已经很长时间了）。在尝试 RISC-V 自旋锁补丁时注意到。鉴于这已经被破坏了 5 年并且没有人注意到，它可能不值得重新修补。https://git.postgresql.org/pg/commitdiff/0a208ed63ffe50a8d9d7c0b33996ec01cc4fdef6修复 BootstrapModeMain() 中的虚假断言。由于我在提交之前对其进行了“简化”，因此该断言始终是正确的，正如所写的那样。
Per coverityand Tom Lane. https://git.postgresql.org/pg/commitdiff/e12694523e7e4482a052236f12d3d8b58be9a22cReported-By:Michael Paquier michael@paquier.xyz Discussion: https://postgr.es/m/YRIlNQhLNfx555Nx@paquier.xyz https://git.postgresql.org/pg/commitdiff/1d5135f0043b32a7d9fdc66a9553c2078900e240删除对没有 BGWORKER_SHMEM_ACCESS 的后台工作人员的支持。没有共享内存访问的后台工作人员在引入后台工作人员后不久就在 EXEC_BACKEND windows 构建中被破坏，没有报告。显然，它们并不常用。问题是 bgworker 启动需要附加到 EXEC_BACKEND 子进程中的共享内存。StartBackgroundWorker() 为未连接的工作人员从共享内存中分离，但此时我们已经初始化了引用共享内存的子系统。解决这个问题并非完全微不足道，因此删除不连接到共享内存的选项似乎是最好的方法。在大多数用例中，连接到共享内存的优点远远大于缺点。由于到目前为止还没有关于此问题的报告，我们认为不值得尝试在后台分支中解决此问题。Perdiscussion with Alvaro Herrera, Robert Haas and Tom Lane.Author:Andres Freund andres@anarazel.de Discussion: https://postgr.es/m/20210802065116.j763tz3vz4egqy3w@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/80a8f95b3bca6a80672d1766c928cda34e979112在 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 很快就会告诉您。不过我不完全确定它们的格式，所以这些还没有刷新。这可以说是一个错误，但没有完成任何backpatch，因为这可能会导致使用对象访问挂钩的任何人的行为发生变化。Discussion: https://postgr.es/m/YQJKV29/1a60uG68@paquier.xyz https://git.postgresql.org/pg/commitdiff/7b565843a94412395149c6add0cbfc21d2bca0d4修正sepgsql的回归测试输出。 对于涉及表重写的测试，差异是由7b56584造成的。 Perbuildfarm member rhinoceros. Discussion: https://postgr.es/m/YRHxXcyFjPuPTZui@paquier.xyzhttps://git.postgresql.org/pg/commitdiff/1e3445237b861fee2524defde79428058d90c0d8在 psql 中为 DECLARE .. ASENSITIVE 添加制表符补全。此选项已在 dd13ad9 中引入。Discussion: https://postgr.es/m/TYAPR01MB289665526B76DA29DC70A031C4F09@TYAPR01MB2896.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/e2ce88b58f151753b094f28bc387cebae865927c在 ROLLBACK PREPARED 中避免不必要的共享失效。性能增益很小，但这使得逻辑与 AtEOXact_Inval() 更加一致。在这种情况下不需要其他失效，因为PREPARE 已经负责发送任何本地的。Author: LiuHuailing Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/OSZPR01MB6215AA84D71EF2B3D354CF86BE139@OSZPR01MB6215.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/710796f0542180cca18ee93889da692df642bdf2删除未使用的回归测试证书 server-ss。server-ss 证书包含在 e39250c64 中，但从未在 TLS 回归测试中使用，因此删除。
Discussion: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 的 buildfarm 中进行了足够的测试，这将被回补到所有受支持的版本。Reviewed-by:Peter Eisentraut, Michael PaquierDiscussion: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 的 buildfarm 中进行了足够的测试，这将被回补到所有支持的版本。Reviewed-by:Michael PaquierDiscussion:https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se https://git.postgresql.org/pg/commitdiff/72bbff4cd6eaf55239ccef79cec61766b5f8f1d2修复 sslsni connparam 布尔检查。对 sslsni 的检查仅检查参数是否存在，而不检查参数的实际值。这意味着 SNI 扩展始终处于打开状态。通过检查 sslsni 的值进行修复，并且仅在 sslsni 已启用的情况下激活 SNI 扩展。还更新文档以更符合其他布尔参数的记录方式。Backpatch 到 sslsni 首次实现的 14。Backpatch to14 where sslsni was first implemented.Reviewed-by:Tom Lane Backpatch-through: 14, where sslni was added https://git.postgresql.org/pg/commitdiff/512f4ca6c6b5d2e3a1620288048ccaa712121e12 Heikki Linnakangas pushed
修复 EvalPlanQual 期间混合使用本地和外部分区的段错误。在EvalPlanQual 期间重新评估直接修改的外部更新或删除是不明智的。但是，如果表混合了本地和外部分区，则ExecInitForeignScan() 仍然可以被调用。EvalPlanQualStart() 使 es_result_relations 数组在子 EPQ EState 中未初始化，但 ExecInitForeignScan() 仍希望找到它。这导致了段错误。通过在EvalPlanQual 处理期间跳过 es_result_relations 查找来修复。为了使事情更加健壮，还可以跳过 BeginDirectModify 调用，并添加运行时检查，以确保在EvalPlanQual 处理期间不会在直接修改外部扫描上调用 ExecForeignScan()。这是 v14 中的新功能，提交 1375422c782。在此之前，EvalPlanQualStart() 将整个 ResultRelInfo 数组复制到 EPQ EState。回溯到 v14。
Report anddiagnosis by Andrey Lepikhov.Discussion:https://www.postgresql.org/message-id/cb2b808d-cbaa-4772-76ee-c8809bafcf3d%40postgrespro.ru https://git.postgresql.org/pg/commitdiff/c3928b467a4f0ed2b0ef21a33848e9fcdade37b4Discussion:https://www.postgresql.org/message-id/CAFiTN-tjZbuY6vy7kZZ6xO%2BD4mVcO5wOPB5KiwJ3AHhpytd8fg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/b05f7ecec44be22f6de703e5afdeb4ff3559315a在为它们生成完美的散列函数时，Unicode 键集对使用的素数很挑剔。调用者可以花很多时间遍历候选乘法器和种子的所有可能组合，以找到有效的组合。Unicode 更新通常每年只发生一次，但它仍然使 Unicode 脚本的开发和测试变得不必要地缓慢。要修复，请迭代最内层循环中的素数。这不会更改检入树中的任何现有函数。https://git.postgresql.org/pg/commitdiff/ba958299eaf3d2f55bddb8efb037091d14ca6fd0FDW 批处理代码对所有插槽（常规插槽和计划插槽）都使用相同的元组描述符，但这是不正确的 - 子计划可能使用不同的描述符。目前这是良性的，因为批处理仅用于插入，在这种情况下，描述符始终匹配。但是如果我们允许批量更新，那将会改变。通过复制适当的元组描述符来修复。Backpatch 到 14，其中实施了FDW 批处理。
Backpatch-through: 14, where FDW batching was addedDiscussion:https://postgr.es/m/CA%2BHiwqEWd5B0-e-RvixGGUrNvGkjH2s4m95%3DJcwUnyV%3Df0rAKQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/650663b4cb4714a34d7171981de4392486a85f86FDW 批处理代码对所有插槽（常规插槽和计划插槽）都使用相同的元组描述符，但这是不正确的 - 子计划可能使用不同的描述符。目前这是良性的，因为批处理仅用于插入，在这种情况下，描述符始终匹配。但是如果我们允许批量更新，那将会改变。通过复制适当的元组描述符来修复。Backpatch 到 14，其中实施了FDW 批处理。
Reviewed-by:Tom Lane tgl@sss.pgh.pa.us Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/88cbbbfa3e2b0d38d6047af83764f140face5991修复 DEALLOCATE 和 DESCRIBE 语句的连接处理。将语句绑定到带有 DECLARE STATEMENT 的连接后，该连接仍未用于 DEALLOCATE 和 DESCRIBE 语句。这个补丁修复了这个问题，添加了一个缺失的警告并清理了代码。
Reviewed-by: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/TYAPR01MB5866BA57688DF2770E2F95C6F5069%40TYAPR01MB5866.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/399edafa2aba562a8013fbe039f3cbf3a41a436ehttps://git.postgresql.org/pg/commitdiff/4279e5bc8c0b3a0cb6b6d3f1316ae81cd0028447
开班通知-PCP认证专家(重庆、成都站)培训开班0807
开班通知-PCP认证专家(南京站)培训开班0731
PostgreSQL认证专家考试(培训)-北京站-成功举办
如何在工业和信息化部教育与考试中心查询PostgreSQL证书
