PG Build 2021 将于 2021 年 11 月 30 日和 12 月 1 日格林威治标准时间 09:00-17:00 在线举行。 详细信息。
PostgresDAC 3.11,一个用于 PostgreSQL 的直接访问组件套件,已发布。 http://microolap.com/products/connectivity/postgresdac/download/
JDBC 42.3.1 已发布。
ODB C++ ORM 版本 2.5.0-b.21 已发布。
DynamoDB FDW 1.0.0 已发布。
Babelfish,一个用于 PostgreSQL 的 MS SQL Server 兼容层,已发布。
https://archives.postgresql.org/pgsql-jobs/2021-11/
Planet PostgreSQL: https://planet.postgresql.org/
本周的 PostgreSQL 每周新闻由 David Fetter 为您带来
请在太平洋标准时间下午 3:00 之前将新闻和公告提交至 david@fetter.org。
Tom Lane 推送了
plpgsql:报告变量初始化错误的正确行号。 以前,我们指向周围块的 BEGIN 关键字。 如果在 DECLARE 部分中有多个变量被初始化,这还不够好:这会非常令人困惑和无益。 我们知道变量声明的开始位置,因此只需要稍微多一点的错误报告基础设施即可使用它。 讨论: https://postgr.es/m/713975.1635530414@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/acb2d7d5d2301f07d5857ee252995e62ce9e7055
当备用进程释放许多锁时,避免 O(N^2) 行为。 当重放一个在主服务器上持有许多独占锁的事务时,备用服务器的启动进程会在操作锁列表上花费 O(N^2) 的工作量。 当编写此代码时,它是没有问题的,但是提交 1cff1b95a 使重复的 list_delete_first() 调用效率低下,正如其提交消息中所述。 通过正常迭代列表并在完成后才释放存储来修复。 (如果我们需要从部分发生的错误中恢复,这将是不够的;但是我们不需要。)回溯到 v13,其中 1cff1b95a 进入。 Nathan Bossart 讨论: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com https://git.postgresql.org/pg/commitdiff/6301c3adabd947394682e37c933b0f3f83353b28
文档:改进与 TAP 测试关联的 README 文件。 重新排列 src/test/perl/README,使第一部分更清楚地是“如何运行这些测试”,其余部分是“如何编写新测试”。 在那里添加一些关于调试测试失败的基本信息。 然后,从其他描述如何运行 TAP 测试的 README 中添加对该 README 的交叉引用。 根据 Kevin Burke 的建议,尽管这不是他的原始补丁。 讨论: https://postgr.es/m/CAKcy5eiSbwiQnmCfnOnDCVC7B8fYyev3E=6pvvECP9pLE-Fcuw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b21415595cace7f3a45cfeb3023359b4b4d56b85
不要在一次调用中尝试读取多 GB 的 pg_stat_statements 文件。 Windows 在请求读取超过 INT_MAX 字节时会失败,并且可能其他平台也可能存在类似问题。 让我们调整此代码,以便每次调用最多读取 1GB。 (人们不会认为该文件会变得那么大,但是现在我们有了一个麻烦的现场报告,所以它可以。我们可能应该添加一些机制来单独限制查询文本文件的大小和哈希表的大小。 但这不是此补丁。)根据 Yusuke Egashira 的 bug #17254。 它已经存在一段时间了,因此将其回溯到所有受支持的分支。 讨论: https://postgr.es/m/17254-a926c89dc03375c2@postgresql.org https://git.postgresql.org/pg/commitdiff/a667b066837849c5e55e0d626f1f7c93e267b8b7
避免列表操作中的其他一些 O(N^2) 风险。 本着 6301c3ada 的精神,修复更多我们在循环中使用 list_delete_first() 并因此冒着 O(N^2) 行为风险的地方。 不清楚在这些地方操作的列表是否会变得足够长以至于真正有问题...但是也不清楚它们是否不会,并且修复方法足够简单。 与以前一样,回溯到 v13。 讨论: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com https://git.postgresql.org/pg/commitdiff/e9d9ba2a4ddc39e331dd8461b511aa59ec0dc8af
避免 SyncPostCheckpoint() 中的 O(N^2) 行为。 与提交 6301c3ada 和 e9d9ba2a4 一样,避免执行重复的 list_delete_first() 操作,因为当有许多文件等待取消链接时,这会非常昂贵。 这比在那些情况下的变化略大。 我们必须保持列表状态对于 AbsorbSyncRequests() 的调用有效,因此有必要发明一个“已取消”字段,而不是立即删除 PendingUnlinkEntry 条目。 此外,由于我们可能无法处理所有条目,因此我们需要一个新的列表原语 list_delete_first_n()。 list_delete_first_n() 几乎是 list_copy_tail(),但是它会修改输入列表,而不是创建新副本。 我发现一些现有使用后者的代码可以有效地使用新函数。 (可能还有更多,但是其他调用方看起来可能不应该覆盖输入列表。)与以前一样,回溯到 v13。 讨论: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com https://git.postgresql.org/pg/commitdiff/65c6cab1365ac33b11a49a2a193f6b3f9c53e487
文档:更准确地说明关系名称之间的冲突。 在所有这些对象类型的参考页面中使用诸如“表的名称必须与同一模式中任何其他关系(表、序列、索引、视图、物化视图或外部表)的名称不同”之类的措辞。 此处的主要更改是显式提及物化视图;尽管其中一些页面根本没有提到任何关于名称冲突的信息。 根据 Daniel Westermann 的建议。 讨论: https://postgr.es/m/ZR0P278MB0920D0946509233459AF0DEFD2889@ZR0P278MB0920.CHEP278.PROD.OUTLOOK.COM https://git.postgresql.org/pg/commitdiff/af8c580e5cf32bb85dde70083a260c93a1f783eb
文档:清理一些提到 template1 而没有提到 template0 的地方。 改进了当我们向标准数据库集中添加 template0 时未更新的旧文本。 根据 P. Luzanov 的建议。 讨论: https://postgr.es/m/163583775122.675.3700595100340939507@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/7d9ec0754afeabb9f336c5220ef415c3ea27a0b6
修复 ExecInitCoerceToDomain() 中的变量生存期。 这撤消了 1ec7679f1 中的错误:domainval 和 domainnull 旨在跨循环迭代存在,但它们被错误地移到了循环内部。 其效果只是发出无用的额外 EEOP_MAKE_READONLY 步骤,因此这没什么大不了的;尽管如此,还是将其回溯到引入错误的 v13。 Ranier Vilela 讨论: https://postgr.es/m/CAEudQAqXuhbkaAp-sGH6dR6Nsq7v28_0TPexHOm6FiDYqwQD-w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/01fc6527034a6f70ed44a078af8f636b1ab64947
确保日期时间和 float8 值的逻辑复制一致。 在 walreceiver 中,将发布者的相关 GUC(datestyle、intervalstyle、extra_float_digits)设置为与 pg_dump 使用的值相同,原因也相同:我们需要以相同的方式读取输出,而不管接收者的设置如何。 如果没有此设置,订阅者可能会错误地解释传输的值。 尽管这显然是一个错误修复,但并非没有缺点:将值存储到其他一些数据类型(例如文本)中的订阅者可能会获得与以前不同的结果,并且可能对此不满意。 鉴于之前没有投诉,似乎最好仅在 HEAD 中更改此设置,并将其称为 v15 中的不兼容更改。 Japin Li,根据 Sadhuprasad Patro 的报告 讨论: https://postgr.es/m/CAFF0-CF=D7pc6st-3A9f1JnOt0qmc+BcBPVzD6fLYisKyAjkGA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f3d4019da5d026f2c3fe5bd258becf6fbb6b4673
盲目尝试消除 hamerkop 上的 SSL 编译失败。 Buildfarm 成员 hamerkop 最近几天一直失败,错误看起来像是 OpenSSL 的与 X509 相关的符号没有被导入到 be-secure-openssl.c 中。 不清楚为什么会这样,但是让我们尝试显式包含 <openssl/x509v3.h>,就像 fe-secure-openssl.c 中长期以来一直存在的那样。 讨论: https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/24f9e49e430b4173d75a570e06abef8e3fd12c5e
修复 pg_basebackup 的 MSVC 构建。 提交 23a1c6578 认为使用新变量 BBOBJS 重构 pg_basebackup/Makefile 会很酷,但是我们的 MSVC 构建系统对此一无所知。 根据 buildfarm。 https://git.postgresql.org/pg/commitdiff/d8bf0a1c1d3429cafb3019f2773e2f3aa68f3b65
第二次尝试消除 hamerkop 上的 SSL 编译失败。 经过进一步调查,似乎问题的原因是我们最近决定开始定义 WIN32_LEAN_AND_MEAN。 这会导致 <windows.h> 不再包含 <wincrypt.h>,这意味着 OpenSSL 标头无法通过 #undef'ing 冲突的宏来防止与该标头冲突。 显然,be-secure-openssl.c 在 OpenSSL 标头之后 #include 的其他一些系统标头正在拉入 <wincrypt.h>。 不清楚它在哪里发生以及为什么我们没有在其他 Windows buildfarm 动物上看到它。 但是,将 OpenSSL #include 移动到列表的末尾应该可以工作。 为了面向未来,在 fe-secure-openssl.c 中也这样做。 顺便说一句,删除无用的 <openssl/ssl.h> 的双重包含。 感谢 Thomas Munro 找出相关信息。 讨论: https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/1241fcbd7e649414f09f9858ba73e63975dcff64
禁止通过 array_to_tsvector() 创建空词位。tsvector 数据类型一直禁止词位为空。然而,array_to_tsvector() 函数并没有遵循这一规则,它允许空字符串数组元素成为空词位。这可能导致后续的转储/恢复失败,更不用说原始禁止背后的语义问题。然而,其他直接将纯文本输入作为词位值的函数不需要类似的限制,因为它们只将字符串与现有的 tsvector 条目进行匹配。特别是,让 ts_delete() 拒绝空字符串将是一个糟糕的主意,因为这是清理通过此错误进入 tsvector 列的任何错误数据的最方便的方法。考虑到这一点,我们也删除 tsvector_delete_arr 和 tsvector_setweight_by_filter 中对 NULL 数组元素的禁止。忽略它们似乎更一致,就像忽略空字符串元素一样。这是一个可以向后移植的案例,因为它显然是一个错误修复。但总的来说,这似乎不是一个在小版本中需要更改的事情。Jean-Christophe Arnu 讨论:https://postgr.es/m/CAHZmTm1YVndPgUVRoag2WL0w900XcoiivDDj-gTTYBsG25c65A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cbe25dcff73a297adbada9dc1d6cad3df18014e9
盲目尝试修复 MSVC pgcrypto 构建。提交 db7d1a7b0 取消了 Mkvcbuild.pm 对构建 contrib/pgcrypto 的自定义支持,但忽略了通知它该模块现在可以正常构建。或者至少我猜它现在可以正常构建了。但这肯定会导致 bowerbird 失败,因为它试图测试一个它尚未构建的模块。https://git.postgresql.org/pg/commitdiff/3c2c391dc9f82fae181508ebcc2f7621ffefd024
文档:添加一些关于 List 函数性能的说明。根据 Andres Freund 的建议。讨论:https://postgr.es/m/20211104221248.pgo4h6wvnjl6uvkb@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/27ef132a805c8633ed8bb94ed70be995c681ab1f
contrib/sslinfo 也需要修复以使 hamerkop 满意。这里重新排序 #include 语句有点问题,因为 libpq/libpq-be.h 需要包含 <openssl/ssl.h>。相反,让我们在所有 #include 语句之后 #undef 不需要宏。这肯定比另一种方式更丑陋,但尽管将来可能进行头文件重新排列,它应该可以工作。(查看 openssl 头文件表明 X509_NAME 是我们使用的唯一冲突符号。)顺便提一下,删除 pg_backup_archiver.h 中一个相关但长期不正确的注释。讨论:https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/568620dfd6912351b4127435eca5309f823abde8
消除未初始化变量警告。很多构建场动物都在警告这一点,而 lapwing 实际上正在失败(因为 -Werror)。在我看来,这是一个误报,所以无需做更多的事情,只需从零开始初始化该变量即可。讨论:https://postgr.es/m/YYXJnUxgw9dZKxlX@paquier.xyz https://git.postgresql.org/pg/commitdiff/c3ec4f8fe867807613c08fe16789434ab1a74a15
Michaël Paquier 推送了
在 REINDEX CONCURRENTLY 中保留操作符类参数。旧索引的操作符类参数 Datums 通过直接从系统目录中获取的方式,与谓词和表达式相同。然后将它们复制到新 IndexInfo 中,该新 IndexInfo 将用于创建新副本。这导致新索引使用默认参数而不是用户预定义的参数进行重建。恢复具有正确操作符类参数的新索引的唯一方法是从头开始重新创建新索引。该问题由 911e702 引入。作者:Michael Paquier 审核人:Zhihong Yu 讨论:https://postgr.es/m/YX0CG/QpLXcPr8HJ@paquier.xyz 向后移植:13 https://git.postgresql.org/pg/commitdiff/add5cf28d48149459466b9aff374d78aebf17482
为带有时间线切换的 pg_receivewal 添加 TAP 测试。pg_receivewal 能够跟踪时间线切换,但没有对此进行测试。此测试使用空存档位置,并从插槽执行重启,这使得它的实现比重用现有存档目录稍微简单一些。作者:Ronan Dunklau 审核人:Kyotaro Horiguchi、Michael Paquier 讨论:https://postgr.es/m/18708360.4lzOvYHigE@aivenronan https://git.postgresql.org/pg/commitdiff/0f9b9938a0367313fcf6a32fcb7fb5be9e281198
重构 pg_receivewal 的压缩选项。自 cada1af 以来,pg_receivewal 包含 --compress 选项,允许使用 gzip 压缩 WAL 段,其中值 0(默认值)表示不使用压缩。此提交引入了一个名为 --compression-method 的新选项,可以使用值“none”(默认值)和“gzip”,以使事情更具可扩展性。在这种选项层中,--compress=0 的情况变得模糊,因此我们选择在使用“none”和非零压缩级别时使 pg_receivewal 返回错误,这意味着 --compress 的授权值现在是 [1,9] 而不是 [0,9]。如果不指定 --compress 和压缩方法为“gzip”,则 pg_receivewal 将使用 zlib 的默认值(Z_DEFAULT_COMPRESSION)。当扫描现有存档时,负责查找流式启动 LSN 的代码被重构并更具可扩展性。在此过程中,在 walmethods.c 中将“compression”重命名为“compression_level”,以减少与压缩方法引入的混淆,即使 pg_basebackup 使用的 tar 方法不依赖于压缩方法(至少现在是这样),而只是依赖于压缩级别(实际上,这个领域可以改进更多)。这是为即将到来的补丁做准备,该补丁将 LZ4 支持添加到 pg_receivewal 中。作者:Georgios Kokolatos 审核人:Michael Paquier、Jian Guo、Magnus Hagander、Dilip Kumar、Robert Haas 讨论:https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/d62bcc8b07f921bad105c7a826702c117ea7be58
修复 pg_receivewal --compression-method 的一些笔误。在其中一个错误消息中,选项名称不正确,并且在代码中使用了短选项“I”,但我们不打算这样做。在此过程中,修复文档以引用“方法”,而不是“级别”。在提交 d62bcc8 中的疏忽,我在进一步审查 pg_receivewal 的 LZ4 补丁后检测到。https://git.postgresql.org/pg/commitdiff/9588622945754305836555273a6a3be814db315c
在 pg_receivewal 中添加对 LZ4 压缩的支持。当使用 --with-lz4 编译代码时,pg_receivewal 会获得一个新选项 --compression-method=lz4。与 gzip 类似,这提供了使用 LZ4 压缩存档 WAL 段的可能性。此选项与 --compress 不兼容。该实现使用 LZ4 帧,并且与简单的 lz4 命令兼容。与 gzip 类似,使用 --synchronous 可确保将任何数据刷新到当前 .partial 段内的磁盘,以便即使从未完成的段中也可以检索尽可能多的 WAL 数据(这需要在解压缩后使用零填充部分文件,直到后端支持的 WAL 段大小,但这与 gzip 相同)。流式启动 LSN 的计算能够透明地查找和检查 LZ4 压缩段。与 gzip 不同,gzip 的未压缩大小直接存储在读取的对象中,而 LZ4 块协议默认情况下不存储未压缩的数据。可以使用带有 LZ4 帧的 contentSize,但这对于使用包含使用“lz4”命令默认值压缩的段的存档没有帮助,因为此处没有存储。因此,此提交采用了最可扩展的方法,通过分块解压缩已存档的段,以 64kB 的空白输出缓冲区来检查其未压缩的大小(在 8kB、16kB 或 32kB 中没有注意到实际的性能差异,并且操作本身实际上很快)。已添加测试来验证生成的 LZ4 文件的创建和正确性。后者是通过使用环境中的命令“lz4”(如果找到)来实现的。walmethods.c 中基于 tar 的 WAL 方法(现在仅由 pg_basebackup 使用)还不了解 LZ4。其代码可以为此目的进行扩展。作者:Georgios Kokolatos 审核人:Michael Paquier、Jian Guo、Magnus Hagander、Dilip Kumar 讨论:https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/babbbb595d2322da095a1e6703171b3f1f2815cb
改进 psql 对 COMMENT 的制表符补全。为更多对象类型添加了补全,例如域约束、文本搜索对象或策略。此外,该区域被重新组织,将 COMMENT 支持的对象列表更改为与文档相同的顺序,以方便将来添加。作者:Ken Kato 审核人:Fujii Masao、Shinya Kato、Suraj Khamkar、Michael Paquier 讨论:https://postgr.es/m/6e0c2f3f657b229bea32d098d118f307@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/a5b336b8b9e04a93e7c8526302504d2e5201eb80
Álvaro Herrera 推送了
在 DecodeXLogOp 中处理 XLOG_OVERWRITE_CONTRECORD。不这样做会导致逻辑解码无法处理 WAL 流。通过不执行任何操作来处理它。一路向后移植。报告人:Petr Jelínek petr.jelinek@enterprisedb.com https://git.postgresql.org/pg/commitdiff/40c516bba864395c77bcfb1bae65ba9562ba8f71
重写 vacuumdb --analyze-in-stages 的文档简介。使用户意识到在具有现有统计信息的数据库中使用它可能会导致瞬时问题。作者:Nikolai Berkoff nikolai.berkoff@pm.me 讨论:https://postgr.es/m/s-kSljtWXMWgMfGTztPTPcS80R8FHdOrBxDTnrQI6GMZbT7au1A4b0fzaSFtKwCI8nwN0MhgPLfVOTvJ7DwTjkip4P3d0o4VgrMJs4OLN-o=@pm.me https://git.postgresql.org/pg/commitdiff/00a354a13560dc529ac34a303c85c265aaf033b7
记录 log_startup_progress_interval 的默认值和可更改性。9ce346eabf35 的审查。作者:Álvaro Herrera alvherre@alvh.no-ip.org 审核人:Robert Haas robertmhaas@gmail.com 讨论:https://postgr.es/m/202110292123.bnf6axcp27vx@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/e543906e217509ad95c1e341de4e874f027f871b
管道模式不允许使用多命令字符串。...所以在 libpq 文档的适当位置提及这一点。向后移植到 14。报告人:RekGRpth rekgrpth@gmail.com 讨论:https://postgr.es/m/17235-53bb38fc5be593dc@postgresql.org https://git.postgresql.org/pg/commitdiff/105c1de0197473dac8ada55dc8cf773d782224cb
记录 ALTER TABLE .. TYPE 会删除统计信息。共同作者:Nikolai Berkoff nikolai.berkoff@pm.me 讨论:https://postgr.es/m/vCc8XnwDmlP4ZnHBQLIVxzD405BiYHVC9qZlhIF7IsfxK0gC9mZ4PUUOH0-3y6kv5p-87-3_ljqT1KvQVAnb8OoWhPU3kcqWn2ZpmxRBCQg=@pm.me https://git.postgresql.org/pg/commitdiff/df80f9da5c6541e744eeb20eaca919c7fc189999
避免在罕见的并发 DROP 情况下崩溃。当正在删除的角色被同时也在删除的目录对象引用时,在尝试构造描述这些对象的字符串时,可能会导致崩溃。通过忽略描述返回为 NULL 的对象来抑制这种情况。大多数相关代码站点已经对此保持谨慎;我们只是错过了一些。这是一个旧错误,因此一路向后移植。报告人:Alexander Lakhin exclusion@gmail.com 讨论:https://postgr.es/m/17126-21887f04508cb5c8@postgresql.org https://git.postgresql.org/pg/commitdiff/d74b54b3ddf710926a44bf3f9c87c00e6f82d825
Daniel Gustafsson 推送了
Amit Kapila 推送
将 XLOG_INCLUDE_XID 标志替换为更局部的标志。提交 0bead9af484c 引入了 XLOG_INCLUDE_XID 标志,以指示 WAL 记录包含 subXID 到 topXID 的关联。它稍后使用该标志在 CurrentTransactionState 中标记 top-xid 已被记录,这样我们就不应该在当前子事务中的下一个 WAL 记录中再次尝试记录它。但是,我们可以使用局部变量来传递该信息。顺便说一下,更改相关的函数和变量名称,使其与代码实际执行的操作保持一致。作者:Dilip Kumar 审核人:Alvaro Herrera, Amit Kapila 讨论:https://postgr.es/m/E1mSoYz-0007Fh-D9@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/71db6459e6e4ef623e98f3b1e3e9fed1bfb0ae3b
将 MarkCurrentTransactionIdLoggedIfAny() 移出临界区。我们没有在此函数中修改任何可能对任何并发会话造成问题的共享状态。这将使其看起来类似于同一结构 (TransactionState) 的其他更新,从而避免了未来代码阅读者的困惑。作者:Dilip Kumar 审核人:Amit Kapila 讨论:https://postgr.es/m/E1mSoYz-0007Fh-D9@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/335397456b7e3f9f619038cb322fbfc9dd649d4f
藤井雅雄推送
pgbench:改进 pgbench 中的错误处理。以前,初始连接和日志文件打开的失败会导致 pgbench 继续基准测试,报告不完整的结果并以状态 2 退出。即使 pgbench 无法按规定启动,继续基准测试也没有意义。此提交改进了 pgbench,以便在启动基准测试时发生的早期错误(例如这些失败)应使 pgbench 立即以状态 1 退出。作者:Yugo Nagata 审核人:Fabien COELHO, Kyotaro Horiguchi, Fujii Masao 讨论:https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/cd29be5459f0e138c0f19d49ee588feeda78e3c9
pgbench:修复注释中的拼写错误。讨论:https://postgr.es/m/f9041ec2-46b6-1b41-0e84-9c8a1e2d6bda@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/d8dba4d03068eeee1ea3ffc8e7c7b4fa3e35a7f4
Peter Geoghegan 推送
不要在并行 VACUUM 期间忽略索引。提交 b4af70cb 简化了 VACUUM 管理的状态,并顺便重构了并行 VACUUM。由于对领导进程负责的任务的具体细节的混淆,导致代码使得并行 VACUUM 可能完全遗漏表索引的子集。具体来说,低于 min_parallel_index_scan_size 大小截止值的索引被遗漏了。这些索引应该由领导者(以及任何并行不安全的索引)进行清理,但根本没有被清理。一旦堆 TIDs 被回收用于新的堆元组,受影响的索引很容易最终出现重复的堆 TIDs。这会产生通用的症状,这些症状可能会出现在几乎任何涉及索引和表之间结构不一致的索引损坏中。为了解决这个问题,请确保并行 VACUUM 领导进程对恰好低于大小截止值的索引执行任何必需的索引清理。还记录并行 VACUUM 的设计,其中包含这些低于大小截止值的索引。目前还不清楚有多少用户可能会受到此错误的影响。表上至少要有三个索引才能触发该错误:一个较小的索引,加上至少两个超过大小截止值的附加索引。只有一个附加索引的情况不会遇到问题,因为并行 VACUUM 成本模型需要在表上有两个大于截止值的索引才能应用任何并行处理。另请注意,自动清理不受影响,因为它从不使用并行处理。测试用例基于 Masahiko Sawada 的更大补丁中的测试,用于测试并行 VACUUM。非常感谢 Kamigishi Rei 在追踪此问题上提供的宝贵帮助。作者:Peter Geoghegan pg@bowt.ie 作者:Masahiko Sawada sawada.mshk@gmail.com 报告人:Kamigishi Rei iijima.yun@koumakan.jp 报告人:Andrew Gierth andrew@tao11.riddles.org.uk 诊断人:Andres Freund andres@anarazel.de 错误:#17245 讨论:https://postgr.es/m/17245-ddf06aaf85735f36@postgresql.org 讨论:https://postgr.es/m/20211030023740.qbnsl2xaoh2grq3d@alap3.anarazel.de 回溯:14-,其中出现了重构提交。https://git.postgresql.org/pg/commitdiff/9bacec15b67d1a643915858f054790f36b2b7871
修复并行 amvacuumcleanup 安全性错误。提交 b4af70cb 反转了函数 parallel_processing_is_safe() 的返回值,但错过了 amvacuumcleanup 测试。完全不支持并行清理的索引 AM 受到了影响。此错误的实际后果不是很严重。哈希索引受到影响,但由于它们在 hashvacuumcleanup 期间无论如何都只返回块数,因此它不可能产生太大影响。作者:Masahiko Sawada sawada.mshk@gmail.com 讨论:https://postgr.es/m/CAD21AoA-Em+aeVPmBbL_s1V-ghsJQSxYL-i3JP8nTfPiD1wjKw@mail.gmail.com 回溯:14-,其中出现了提交 b4af70cb。https://git.postgresql.org/pg/commitdiff/c59278a1aa5ef2ee8a6d5d83bd987a7ce5c89e84
将另一个旧提交添加到 git-blame-ignore-revs。添加另一个历史性的 pgindent 提交,该提交被提交 8e638845 中完成的初始工作遗漏了。https://git.postgresql.org/pg/commitdiff/581055c32fbb5018431265877754cbd8019bc012
向堆修剪代码添加各种断言。这些断言记录(并验证)我们对修剪如何以及如何不影响目标堆页中现有项的高级假设。例如,其中一个新断言验证修剪不会将仅堆元组设置为 LP_DEAD。作者:Peter Geoghegan pg@bowt.ie 审核人:Andres Freund andres@anarazel.de 讨论:https://postgr.es/m/CAH2-Wz=vhvBx1GjF+oueHh8YQcHoQYrMi0F0zFMHEr8yc4sCoA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5cd7eb1f1c32e1b95894f28b277b4e4b89add772
添加硬化以捕获索引中的无效 TID。向 heapam 索引元组删除路径添加硬化,以捕获索引页中指向索引元组永远不应指向的堆项的 TID。我们在这里尝试捕获的损坏特别难以检测,因为它通常涉及“额外”(损坏的)索引元组,而不是索引中缺少必需的索引元组。例如,索引页中的堆 TID 如果指向堆页中的 LP_UNUSED 项,则很有可能被其中一项新检查捕获。最近修复的并行 VACUUM 错误(请参阅提交 9bacec15)如果 Postgres 14 中存在该特定检查,则很有可能被捕获。目前没有对此额外的硬化进行回溯。作者:Peter Geoghegan pg@bowt.ie 审核人:Andres Freund andres@anarazel.de 讨论:https://postgr.es/m/CAH2-Wzk-4_raTzawWGaiqNvkpwDXxv3y1AQhQyUeHfkU=tFCeA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e7428a99a13f973549aab30c57ec8380ddda1869
更新过时的堆修剪注释。添加新的注释,说明 VACUUM 对堆修剪的期望:修剪绝不能留下仍然具有元组存储的 DEAD 元组。至少自提交 8523492d 以来一直是这种情况,该提交确立了 vacuumlazy.c 不必直接处理仍然具有元组存储的 DEAD 元组的原则,除非可能只是通过重试修剪(以处理涉及并发事务中止的罕见情况)。顺便说一句,更新了一些在快照可伸缩性工作(特别是提交 dc7420c2c9)中遗漏的旧符号名称的引用。https://git.postgresql.org/pg/commitdiff/f214960adde6028a39ba3014b1ab2b224faeefed
更新 vacuumlazy.c 中过时的引用。提交 7ab96cf6 中的疏忽。https://git.postgresql.org/pg/commitdiff/02f9fd129432cab565b2a3cb9f3b3a5000dfe540
Peter Eisentraut 推送
修复不正确的格式占位符。https://git.postgresql.org/pg/commitdiff/ef6f047d2c87b91318364341c058dd6b715951b2
pgcrypto:删除非 OpenSSL 支持。pgcrypto 具有一些加密算法的内部实现,作为调用 OpenSSL 的替代方案。这些很少使用,因为大多数生产安装都使用 OpenSSL 构建。此外,维护并行代码路径使代码更复杂且难以维护。此补丁删除了这些内部实现。现在,只有在配置了 OpenSSL 支持的情况下才会构建 pgcrypto。审核人:Daniel Gustafsson daniel@yesql.se 讨论:https://postgresql.ac.cn/message-id/flat/0b42f1df-8cba-6a30-77d7-acc241cc88c1%40enterprisedb.com https://git.postgresql.org/pg/commitdiff/db7d1a7b0530e8cbd045744e1c75b0e63fb6916f
Heikki Linnakangas 推送
如果 lo_export 失败,修复快照引用泄漏。如果 lo_export() 无法打开目标文件或写入目标文件,则会在顶层事务上下文和资源所有者中泄漏创建的 LargeObjectDesc 及其快照。这很无害,毕竟只是一个小泄漏,但它会给用户一个“快照引用泄漏”警告。修复方法是对在一个函数调用中打开和关闭的瞬态 LargeObjectDescs 使用短寿命内存上下文,并且不使用资源所有者。最容易使用 lo_export() 在不存在的目录上重现泄漏,但原则上,其他 lo_*
函数也可能会失败。回溯到所有支持的版本。报告人:Andrew B 审核人:Alvaro Herrera 讨论:https://postgresql.ac.cn/message-id/32bf767a-2d65-71c4-f170-122f416bab7e@iki.fi https://git.postgresql.org/pg/commitdiff/6b1b405ebfdce9da47f59d8d4144b1168709fbce
更新替代的预期输出文件。之前的提交向 'largeobject' 添加了一个测试,但忽略了替代的预期输出文件 'largeobject_1.source'。根据 buildfarm 动物 'hamerkop' 上的失败。讨论:https://postgresql.ac.cn/message-id/DBA08346-9962-4706-92D1-230EE5201C10@yesql.se https://git.postgresql.org/pg/commitdiff/d5ab0681bf1bbf6c0c2cba9a2d55fe8e080597b6
Robert Haas 推送
amcheck:添加额外的 TOAST 指针检查。扩展对 toasted 属性的检查,如果 rawsize 过大则发出警告。对于压缩属性,如果压缩似乎扩大了属性或压缩方法无效,也发出警告。Mark Dilger 贡献,Justin Pryzby、Alexander Alekseev、Heikki Linnakangas、Greg Stark 和我进行了审查。讨论:http://postgr.es/m/8E42250D-586A-4A27-B317-8B062C3816A8@enterprisedb.com https://git.postgresql.org/pg/commitdiff/bd807be6935929bdefe74d1258ca08048f0aafa3
引入 'bbsink' 抽象以模块化基本备份代码。多年来,基本备份代码积累了大量新功能,但由于没有真正的关注点分离,维护和进一步增强该代码变得越来越困难。例如,了解如何使用 libpq 协议向客户端发送数据的代码分散在整个 basebackup.c 中,而不是集中在一个地方。为了改进这种情况,引入了一个新的“bbsink”对象,它充当基本备份过程期间生成的归档文件和备份清单的接收器。此提交引入了三种类型的 bbsink:“copytblspc” bbsink 使用每个表空间的一个 COPY OUT 操作以及清单的另一个操作将备份转发给客户端,“progress” bbsink 执行命令进度报告,“throttle” bbsink 执行速率限制。“progress”和“throttle”bbsink 类型也将数据转发到后继 bbsink;目前,链中的最后一个 bbsink 将始终是“copytblspc”类型。计划在未来的提交中添加更多类型的“bbsink”。在进度报告的情况下,这种抽象有点泄漏,但这仍然比我们之前的做法更干净。我编写了此补丁,Andres Freund、Sumanta Mukherjee、Dilip Kumar、Suraj Kharage、Dipesh Pandit、Tushar Ahuja、Mark Dilger 和 Jeevan Ladhe 进行了审查和测试。讨论:https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com 讨论:https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/bef47ff85df18bf4a3a9b13bd2a54820e27f3614
引入 'bbstreamer' 抽象以模块化 pg_basebackup。pg_basebackup 知道如何对从服务器获取的备份执行许多操作,例如仅写出文件,或先压缩它们,甚至解析 tar 格式并将修改后的 postgresql.auto.conf 文件注入到服务器生成的归档文件中。不幸的是,这使得 pg_basebackup.c 成为一个非常大的源文件,并且也有点难以增强,例如,服务器正在向我们发送“tar”文件而不是其他类型的归档文件的知识散布在各处,而不是集中在一起。为了改进这种情况,此提交发明了一个新的“bbstreamer”抽象。从服务器接收的每个归档文件都会被馈送到一个 bbstreamer,该 bbstreamer 可以选择丢弃它或将其传递给其他 bbstreamer。还可以根据块是归档文件中文件的有效负载数据的一部分还是归档元数据的一部分来“标记”块。因此,例如,如果我们想获取一个 tar 文件,修改其中包含的 postgresql.auto.conf 文件,然后对结果进行 gzip 压缩并将其写出,我们可以使用 bbstreamer_tar_parser 来解析从服务器接收的 tar 文件,使用 bbstreamer_recovery_injector 来修改 postgresql.auto.conf 的内容,使用 bbstreamer_tar_archiver 来替换前一步中修改的文件 的 tar 标头,使用新构建的标头,这些标头对于修改后的文件是正确的,以及使用 bbstreamer_gzip_writer 来对结果数据进行 gzip 压缩并写入。只有名称中带有“tar”的对象才知道 tar 归档格式的任何信息,并且理论上,如果有人想编写代码,我们可以使用其他格式而不是“tar”重新归档。这些更改确实添加了大量的代码,但我认为结果更易于维护和扩展。pg_basebackup.c 本身缩小了大约三分之一,以前包含在那里的许多复杂性都转移到了新添加的文件中。我编写了此补丁。作为此一部分的更大的补丁系列已经由 Andres Freund、Sumanta Mukherjee、Dilip Kumar、Suraj Kharage、Dipesh Pandit、Tushar Ahuja、Mark Dilger、Sergei Kornilov 和 Jeevan Ladhe 在不同时间进行了审查和测试。讨论:https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com 讨论:https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/23a1c6578c87fca0e361c4f5f9a07df5ae1f9858
在没有理由的情况下不要设置 ThisTimeLineID。在 slotfuncs.c 中,pg_replication_slot_advance() 需要确定应该将槽推进到的 LSN,但这不需要我们更新 ThisTimeLineID,因为此处调用的任何代码都不依赖于它。如果复制槽是逻辑的,pg_logical_replication_slot_advance 将调用 read_local_xlog_page,它确实使用 ThisTimeLineID,但也负责确保它是最新的。如果复制槽是物理的,则时间线根本不用于任何用途。在 logicalfuncs.c 中,pg_logical_slot_get_changes_guts() 也有同样的问题:我们将要运行的唯一关心时间线的代码位于 read_local_xlog_page 中或下游,它已经确保设置了正确的值。因此,不要在此处执行此操作。我编写了此补丁,Michael Paquier、Amul Sul 和 Álvaro Herrera 进行了审查和测试。讨论:https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/caf1f675b88d1aa67ea3fb642e8f38b470cc911e
删除 xlog.c 之外对 ThisTimeLineID 全局变量的所有使用。所有此类代码都以三种方式之一处理此全局变量。有时,同一函数会同时以多种方式使用它。首先,有时它是一个或多个在 xlog.c 或其他地方调用的函数的隐式参数,并且必须在调用这些函数之前将其设置为适当的值,以免它们行为不端。在这些情况下,现在将其作为显式参数传递。其次,有时它用于在恢复结束后获取当前时间线,即正在写入和刷新 WAL 的时间线。此类代码现在调用 GetWALInsertionTimeLine() 或依赖于添加到 GetFlushRecPtr() 的新 out 参数。第三,有时它在恢复期间用于存储当前的重放时间线。这可能会发生变化,因此此类代码通常必须在每次使用前更新该值。它仍然可以这样做,但现在必须使用局部变量代替。这些更改的净效应是减少了直接访问此全局变量的代码量。这很好,因为历史表明,我们并不总是清楚地了解它在任何给定时间点应该包含哪个时间线 ID,或者实际上它是否已在代码中的任何给定点初始化或需要初始化。我编写了此补丁,Michael Paquier、Amul Sul 和 Álvaro Herrera 进行了审查和测试。讨论:https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e997a0c642860a96df0151cbeccfecbdf0450d08
将 ThisTimeLineID 从全局变量更改为局部变量。StartupXLOG() 仍然将 ThisTimeLineID 作为局部变量,但 xlog.c 中的其余代码现在需要通过其他方式获取相关的时间线 ID。大多数情况下,这意味着我们现在将其作为函数参数传递给之前没有传递的一些函数。但是,少数情况需要特殊处理:- 对于可能被外部调用者调用的函数,这些调用者不一定知道要指定哪个时间线,我们从共享内存中获取时间线 ID。在大多数情况下可以使用 XLogCtl->ThisTimeLineID,因为已知在调用这些函数时恢复已完成。在 xlog_redo() 中,我们可以使用 XLogCtl->replayEndTLI。- XLogFileClose() 需要知道打开的日志文件的 TLI。使用新的全局变量 openLogTLI 来执行此操作。虽然有人可能会争辩说这只是将一个全局变量换成了另一个全局变量,但新变量的用途要狭窄得多,并且仅在少数地方引用。- read_backup_label() 现在返回它通过解析 backup_label 文件获得 TLI。以前,可以调用 ReadRecord() 来解析检查点记录,而无需初始化 ThisTimeLineID。现在,时间线被传递下去,我不想传递一个未初始化的变量;此更改使我们能够避免这种情况。旧的编码似乎没有任何我们需要担心的实际后果,但这更简洁。- 在 BootstrapXLOG() 中,它只是一个常量。我编写了此补丁,Michael Paquier、Amul Sul 和 Álvaro Herrera 进行了审查和测试。讨论:https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4a92a1c3d1c361ffb031ed05bf65b801241d7cdd
删除 bd807be6935929bdefe74d1258ca08048f0aafa3 添加的测试。构建场不高兴。目前还不清楚它为什么不喜欢这些测试,但在我们弄清楚之前,我们先删除它们。讨论:http://postgr.es/m/462618.1636171009@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ccf289745d3e50360653181dce6a277a1fc79730
Tomáš Vondra 推送
修复 BRIN minmax 多列中 NaN 值的处理。在计算 float4/float8 值之间的距离时,我们需要更加小心处理 NaN 值,以避免触发断言。我们认为 NaN 值是相等的(距离为 0.0),并且与所有其他值的距离为无穷远。在不进行断言的构建版本中,此问题大多无害 - 范围可能会以效率较低的顺序合并,但索引仍然是正确的。根据 Andreas Seltenreich 的报告。回溯到引入此新 BRIN 操作符类的 14 版本。报告者:Andreas Seltenreich 讨论:https://postgr.es/m/87r1bw9ukm.fsf@credativ.de https://git.postgresql.org/pg/commitdiff/d91353f4b21f10417d142e6ac17a0490adae867c
将 mystreamer 变量标记为 PG_USED_FOR_ASSERTS_ONLY。在不进行断言的构建版本中,消除有关未使用变量的警告。https://git.postgresql.org/pg/commitdiff/dafcf887daa472b0a49bee7e07042372bc37cee4
向 btree_gist 添加布尔 GiST 操作符类。向 btree_gist 扩展添加布尔操作符类,以允许在布尔列上创建 GiST 索引。单个布尔列上的 GiST 索引似乎不是特别有用,但这允许定义涉及布尔列的排除约束,例如。作者:Emre Hasegeli 审阅者:Andrey Borodin 讨论:https://postgr.es/m/CAE2gYzyDKJBZngssR84VGZEN=Ux=V9FV23QfPgo+7-yYnKKg4g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/57e3c5160b24e61758f817feb7aac152cd695c6f
修复 gist_bool_ops 以使用 gbtreekey2。提交 57e3c5160b 添加了一个新的 GiST 布尔操作符类,但它使用 gbtreekey4 来存储数据,这导致了两个字节未定义,正如我们的 valgrind 动物 skink 报告的那样。还有一些困惑,因为操作符类在定义中也使用了 gbtreekey8。通过定义一个新的 gbtreekey2 结构并在所有地方使用它来解决此问题。讨论:https://postgr.es/m/CAE2gYzyDKJBZngssR84VGZEN=Ux=V9FV23QfPgo+7-yYnKKg4g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e2fbb883720aa222f61eb9f3affad1c63bac7cbb
Alexander Korotkov 推送了
Andres Freund 推送了