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

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

发布于 2021-04-12，作者：PWN
PWN

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

PostgreSQL 14 的功能冻结期已到。任何可能包含在 PostgreSQL 14 中的新功能都已在 git 存储库中。

PostgreSQL 产品新闻

AGE 0.4.0 发布，这是一个提供图形数据库功能的 PostgreSQL 扩展。https://github.com/apache/incubator-age/releases/tag/0.4.0

四月份的 PostgreSQL 工作

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

PostgreSQL 新闻

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

本周的 PostgreSQL 每周新闻由 David Fetter 为您带来

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

已应用的补丁

Tom Lane 推送了

  • 修复 SP-GiST 中更多的混淆。spg_box_quad_leaf_consistent 无条件地将叶子数据作为 leafValue 返回，即使在用于 poly_ops 时，该值的类型完全错误。在 12 之前的版本中，这是无害的，因为核心代码在非仅索引扫描中没有对 leafValue 执行任何操作...但自 commit 2a6368343 以来，如果我们执行 KNN 样式扫描，spgNewHeapItem 将无条件尝试使用错误的数据类型参数复制该值。 如果我们不打算返回数据，则该复制浪费时间和空间，但在我修复 ac9099fc1 中的数据类型混淆之前，它意外地没有失败。 因此，更改 spgNewHeapItem，使其仅在我们稍后实际返回数据时才复制数据。 这节省了周期，并回避了有损操作类是否返回正确类型的问题。 同时更改 spg_box_quad_leaf_consistent，使其不返回可能类型错误的数据，作为防止将来有人在核心代码中引入类似错误的保险。 将这两个更改回溯到 v12 和 v13 似乎是个好主意，但我害怕更改 spgNewHeapItem 在这些分支中对使用哪个数据类型的错误想法。 根据 ac9099fc1 的 buildfarm 结果。讨论： https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/dfc843d465689d2c2af8b0e01c66c51ccaae2343

  • 在 SP-GiST 中支持 INCLUDE'd 列。这里没什么好说的：正如其名称所示。 我们从叶子索引元组的 nextOffset 字段中窃取一个以前始终为零的位，以便跟踪是否存在空值位图。 否则，它的工作方式与其他索引类型中的包含列类似。 Pavel Borisov，由 Andrey Borodin 和 Anastasia Lubennikova 审查，我对其进行了大量的编辑。讨论：https://postgr.es/m/CALT9ZEFi-vMp4faht9f9Junb1nO3NOSjhpxTmbm1UGLMsLqiEQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/09c1c6ab4bc5764dd69c53ccfd43b2060b1fd090

  • 清理丢失的默认记录和 CHECK 约束记录的处理。Andrew Gierth 报告说，如果未找到与设置了 atthasdef 的属性匹配的 pg_attrdef 记录，则可能会导致后端崩溃。 AttrDefaultFetch 会警告这种情况，然后留下一个具有空“adbin”指针的关系 tupdesc，大多数地方都不会对此进行防护。 我们考虑将警告提升为错误，但是在 relcache 加载期间抛出错误非常极端：它实际上会阻止使用该关系。 更好的方法似乎是将加载时的行为保留为警告，然后在任何想要使用默认值但找不到默认值的代码路径中引发错误。 这将错误限制在表的 INSERT/UPDATE 操作的子集中，特别是至少允许 pg_dump 成功。 此外，我们应该修复 AttrDefaultFetch，使其不在 tupdesc 中留下任何空指针，因为这只会造成未经测试的错误风险。 同时，将“在加载时发出警告，仅在已知丢失信息被使用时才抛出错误”的相同理念应用于 CHECK 约束。 CheckConstraintFetch 的逻辑与 AttrDefaultFetch 非常相似，但由于时间流逝的原因，它对 AttrDefaultFetch 处理为 WARNING 的相同情况抛出了 ERROR。 使这两个函数更加相似。 顺便说一句，通过让 AttrDefaultFetch 在获取条目后对其进行排序，从而消除 equalTupleDesc 中潜在的 O(N^2) 循环，以便 equalTupleDesc 可以假设两个相等 tupdesc 中的条目必须以匹配的顺序排列。 （CheckConstraintFetch 已经对 CHECK 约束进行了排序，但 equalTupleDesc 尚未被告知）。 有一些理由可以回溯此更改，但是由于字段报告的数量如此之少，我很高兴在 HEAD 中修复它。 讨论：https://postgr.es/m/87pmzaq4gx.fsf@news-spur.riddles.org.uk https://git.postgresql.org/pg/commitdiff/091e22b2e673e3e8480abd68fbb827c5d6979615

  • 修复 nodeResultCache.h 中缺少 #include。 根据 cpluspluscheck。https://git.postgresql.org/pg/commitdiff/789d81de8a50d9a23cc1a3b8ea5d839246020689

  • 从 ExecInitModifyTable 中延迟执行一些操作。安排在需要时执行某些操作，而不是在执行程序启动期间立即执行，因为很有可能永远不需要执行它们： * 在需要之前不要打开结果关系索引。 * 在需要之前不要初始化分区元组路由，也不要初始化子到根元组转换映射。 当仅某些分区实际接收到更新时，这在分区表上的 UPDATE 中获胜；对于较大的分区计数，节省非常明显。 此外，我们可以删除 ExecInitModifyTable 中关于是否设置元组路由的一些粗略的启发式方法。 此外，删除 execPartition.c 的私有哈希表，该哈希表跟踪 ModifyTable 节点已打开哪些分区。 而改为使用 commit 86dc90056 添加到 ModifyTable 本身的哈希。为了允许延迟计算转换映射，我们现在在所有子 ResultRelInfos 中设置 ri_RootResultRelInfo。 我们以前仅在某些定义不太明确的情况下设置它。 这在用户可见的方面产生了影响，即现在更多的错误消息引用了根关系而不是某些分区（并且还以根的列顺序提供错误数据）。 在我看来，这在一致性方面是一个严格的改进，因此我对这个提交中可见的输出更改没有任何问题。 从一个较大的补丁中提取，在我看来，该补丁太混乱而无法在一个提交中推送。 Amit Langote，由 Heikki Linnakangas 和我本人在不同时间审查。讨论： https://postgr.es/m/CA+HiwqG7ZruBmmih3wPsBZ4s0H2EhywrnXEduckY5Hr3fWzPWA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c5b7ba4e67aeb5d6f824b74f94114d99ed6e42b7

  • 从 ExecInitModifyTable 中延迟执行更多操作。 延迟创建 INSERT 和 UPDATE 元组的投影，直到需要它们为止。 当仅实际触及某些分区时，这可以节省大量工作。 与在 UPDATE/DELETE 中识别垃圾列相关的逻辑已移动到另一个循环，从而可以删除对目标关系的一个循环；但是它实际上根本没有改变。 从一个较大的补丁中提取，在我看来，该补丁太混乱而无法在一个提交中推送。 Amit Langote，由 Heikki Linnakangas 和我本人在不同时间审查。讨论： https://postgr.es/m/CA+HiwqG7ZruBmmih3wPsBZ4s0H2EhywrnXEduckY5Hr3fWzPWA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a1115fa0782378a8238045d238ae70cac36be8ae

  • 收紧自定义 GUC 参数的允许名称。 以前，我们对自定义 GUC 的名称非常宽松；只要它至少有一个点，我们就会接受它。 但是，诸如名称中的破折号或等号之类的极端情况会导致各种功能出现异常。 与其试图使世界对于这种情况完全安全，不如要求自定义名称看起来像“identifier.identifier”，其中“identifier”表示 scan.l 在不使用双引号的情况下会接受的内容。 在此过程中，此补丁在 guc.c 中稍微重构了一些内容，以便 find_option() 负责报告 GUC 未找到的情况，从而可以删除其调用者中的重复代码。 根据 Hubert Depesz Lubaczewski 的报告。 不进行回溯，因为问题的后果似乎不足以保证更改稳定分支中的行为。讨论：https://postgr.es/m/951335.1612910077@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3db826bd55cd1df0dd8c3d811f8e5b936d7ba1e4

  • a1115fa07 的注释清理。Amit Langote 讨论： https://postgr.es/m/CA+HiwqEcawatEaUh1uTbZMEZTJeLzbroRTz9_X9Z5CFjTWJkhw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0d46771eaaf77ad08555cf34e421234d5943edfa

  • 删除 clientcert=verify-full 测试中的通道绑定要求。 这在缺少通道绑定支持的较旧的 OpenSSL 版本上会失败。 由于该功能对于此测试用例不是必需的，因此只需删除它，而不是使事情复杂化。 根据 buildfarm。Jacob Champion 讨论： https://postgr.es/m/fa8dbbb58c20b1d1adf0082769f80d5466eaf485.camel@vmware.com https://git.postgresql.org/pg/commitdiff/a282ee68a070a8adc6e6d45e8e643769c587ecc3

  • 允许 psql 的 \df 和 \do 命令指定参数类型。 在处理重载的函数或运算符名称时，必须浏览一长串匹配项是很乏味的。 让我们扩展这些命令以允许指定（输入）参数类型，从而缩小此类结果的范围。 每个附加参数的处理方式与 \dT 的模式参数相同，并与相应参数的类型名称匹配。 同时，修复 \dT（以及这些新选项）以识别“foo[]”的常用表示法，即“foo 上的数组类型”，并处理后端语法允许的特殊缩写，例如“int”表示“integer”。 Greg Sabino Mullane，由我进行了大幅修订。讨论：https://postgr.es/m/CAKAnmmLF9Hhu02N+s7uAyLc5J1xZReg72HQUoiKhNiJV3_jACQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a3027e1e7f3d3a107ecd72d3b4d6333ea2aab6a5

  • 抑制未初始化的变量警告。 几个通常不产生此类警告的 buildfarm 小工具正在抱怨 e717a9a18。 我认为它实际上是安全的，但是移动初始化以消除警告。https://git.postgresql.org/pg/commitdiff/01add89454d5dc289ed3126d5de03169bdeff41b

  • 在 \df、\do 中添加对类型参数的制表符补全的支持。 commit a3027e1e7 中的疏忽。https://git.postgresql.org/pg/commitdiff/d1fcbde579d440c35023baa0de7ebf27f644a314

  • 文档：更新 check_function_bodies 的文档。 调整文档和描述字符串，以注意 check_function_bodies 也适用于过程。 （事后看来，它应该被命名为 check_routine_bodies，但是现在似乎为时已晚。） Daniel Westermann 讨论：https://postgr.es/m/GV0P278MB04834A9EB9A74B036DC7CE49D2739@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM https://git.postgresql.org/pg/commitdiff/07b76833b15163c6574ea2c12d05d9a0800665e2

  • 修复 xlogprefetch.h 未包含所有先决头文件的故障。根据 cpluspluscheck 的检查。https://git.postgresql.org/pg/commitdiff/99964c4ade468c35a3f6e248a2380a1ff67d9cd3

  • 修复来自提交 a4d75c86b 的未初始化变量问题。 *exprs != NIL 的路径会出错，并可能崩溃，因为 pull_varattnos 期望其最后一个参数在调用时有效。由 Coverity 发现 --- 我们在回归测试中没有覆盖此路径。https://git.postgresql.org/pg/commitdiff/9cb92334092fa75afc62a71243bbc1f4612ecfa4

  • 添加宏 PGWARNING，并使 PGERROR 在所有平台上可用。我们之前注意到需要处理 Windows 头文件，这些头文件提供了与 elog.h 中不同的宏 "ERROR" 定义。事实证明，R 也想定义 ERROR，以及 WARNING。PL/R 一直以一种蹩脚的方式解决这个问题，但当最近我们更改了 ERROR 的数值时，这种方式就失效了。为了让他们有一个更具前瞻性的解决方案，我们为 WARNING 提供了一个备用宏 PGWARNING，并使 PGERROR 始终可见，而不仅限于 #ifdef WIN32 的情况。讨论：https://postgr.es/m/CADK3HHK6iMChd1yoOqssxBn5Z14Zar8Ztr3G-N_fuG7F8YTP3w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d7cff12c4c035b7cf12bb8454824f48f13018730

Michaël Paquier 推送

  • 重构所有执行连接检查的 TAP 测试套件。此提交重构了更多的 TAP 测试，以适应 PostgresNode 中最近引入的 connect_ok() 和 connect_fails()，它们由 0d1a3343 引入。这更改了以下测试套件以使用相同的连接检查代码路径：- Kerberos - LDAP - SSL - 身份验证。这些例程被扩展为能够处理根据每个套件的需求设置的可选参数，如下所示：- 自定义 SQL 查询。- 预期的 stderr 匹配模式。- 预期的 stdout 匹配模式。新设计可以通过更多参数进行扩展，并且未来有一些计划，将对基于后端日志内容进行检查的这些例程进行扩展。作者：Jacob Champion，Michael Paquier 讨论：https://postgr.es/m/d17b919e27474abfa55d97786cb9cfadfe2b59e9.camel@vmware.com https://git.postgresql.org/pg/commitdiff/c50624cdd248c13b4ba199f95e24c88d2cc8a097

  • 修复 collationcmds.c 中的拼写错误。由 51e225d 引入。作者：Anton Voloshin 讨论：https://postgr.es/m/05477da0-703c-7de7-998c-5879738e8f39@postgrespro.ru https://git.postgresql.org/pg/commitdiff/9f6f1f9b8e61f9ce47e1936fc68c21a4a8d6722c

  • 更改 PostgresNode::connect_fails() 以永远不发送查询。这种类型的失败类似于 c757a3da 中修复的错误，其中身份验证失败与 psql 向其通信管道推送命令会导致测试失败。此例程旨在失败，因此无论如何发送查询都没有意义。根据构建场成员 gaur 和 hoverfly 的分析，以及 Tom Lane 的修复。讨论：https://postgr.es/m/513200.1617634642@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6d41dd045ada28ee14182112fc4cf50fb3879d28

  • 修复 SSL 和 Kerberos 测试中的一些问题。最近在 c50624c 中完成的重构意外地破坏了查询后检查的一部分 kerberos 测试，因此将其功能添加回来。一些不活动的 SSL 测试的参数顺序不正确，如果它们要运行，则会导致它们失败。作者：Jacob Champion 讨论：https://postgr.es/m/4f5b0b3dc0b6fe9ae6a34886b4d4000f61eb567e.camel@vmware.com https://git.postgresql.org/pg/commitdiff/5a71964a832febfee23cedc3bb354049d6ca78a7

  • 通过 log_connections 添加一些有关身份验证标识的信息。“身份验证标识”是身份验证方法用于标识特定用户的字符串。在许多常见情况下，这与 PostgreSQL 用户名相同，但对于某些第三方身份验证方法，正在使用的标识符可能会被缩短或以其他方式转换（例如，通过 pg_ident 用户映射），然后再由服务器存储。为了帮助管理员查看谁实际与系统进行了交互，此提交添加了在后端 Port 中身份验证成功时存储原始标识的功能，并在启用 log_connections 时生成日志条目。生成的日志条目如下所示（其中名为 "foouser" 的本地用户正在以名为 "admin" 的数据库用户身份连接到数据库）：LOG: connection received: host=[local] LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88) LOG: connection authorized: user=admin database=postgres application_name=psql Port->authn_id 根据身份验证方法设置：bsd：PostgreSQL 用户名（又名本地用户名）cert：客户端的 Subject DN gss：用户主体 ident：远程用户名 ldap：最终绑定 DN pam：PostgreSQL 用户名（又名 PAM 用户名）密码（以及所有 pw-challenge 方法）：PostgreSQL 用户名 peer：对等方的 pw_name radius：PostgreSQL 用户名（又名 RADIUS 用户名）sspi：如果 compat_realm=1，则为降级（与 SAM 兼容）的登录名，如果 compat_realm=0，则为用户主体名称。trust 身份验证方法不会设置身份验证标识。clientcert=verify-full 也不会。Port->authn_id 可用于其他目的，例如 pg_stat_activity 中的仅限超级用户的额外列，但这留作将来的工作。PostgresNode::connect_{ok,fails}() 已被修改，以允许测试使用新的 log_like 和 log_unlike 参数检查后端日志文件中所需的或禁止的模式。这使用了一种基于截断现有服务器日志文件的方法，例如 issues_sql_like()。测试已添加到 ldap、kerberos、身份验证和 SSL 测试套件中。作者：Jacob Champion 审阅者：Stephen Frost、Magnus Hagander、Tom Lane、Michael Paquier 讨论：https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com https://git.postgresql.org/pg/commitdiff/9afffcb833d3c5e59a328a2af674fac7e7334fc1

  • 删除一些索引 AM 的页面初始化中多余的 memset(0) 调用。Bloom、GIN、GiST 和 SP-GiST 依赖于 PageInit() 来初始化页面的内容，此例程将大小为 BLCKSZ 的页面（包括特殊空间）完全填充为零。这些索引 AM 一直在使用额外的 memset() 调用来将特殊页面空间甚至整个页面填充为零，这是不必要的，因为 PageInit() 已经完成了这项工作，所以让我们删除它们。GiST 没有进行此额外的调用，但自 6236991 以来已注释掉执行此操作的系统调用。在此基础上，删除 SP-GiST 的一个 MAXALIGN()，因为 PageInit() 会处理它。这使得所有索引 AM 的整个页面初始化逻辑更加一致。作者：Bharath Rupireddy 审阅者：Vignesh C、Mahendra Singh Thalor 讨论：https://postgr.es/m/CALj2ACViOo2qyaPT7krWm4LRyRTw9kOXt+g6PfNmYuGA=YHj9A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4c0239cb7a7775e3183cb575e62703d71bf3302d

  • 修复 Windows 主机上的连接测试的一些失败。日志文件的截断（这组测试依赖它来确保连接尝试与其预期的后端日志模式匹配）失败，如构建场成员 fairywren 报告的那样。我们不是截断，而是轮换日志文件并重新启动节点。这将确保每个测试的连接尝试数据都是唯一的。讨论：https://postgr.es/m/YG05nCI8x8B+Ad3G@paquier.xyz https://git.postgresql.org/pg/commitdiff/c7578fa64019f27edc31261ea49066a4b2569a6c

  • 修复文档和代码注释中的拼写错误和语法错误。注释修复应用于 HEAD，文档改进应用于需要的后向分支。作者：Justin Pryzby 讨论：https://postgr.es/m/20210408164008.GJ6592@telsasoft.com 向后移植到：9.6 https://git.postgresql.org/pg/commitdiff/609b0652af00374b89411ea2613fd5bb92bca92c

Peter Eisentraut 推送

Álvaro Herrera 推送

Fujii Masao 推送了此提交

  • 在启动进程退出时关闭事务跟踪。Maxim Orlov 报告称，备用服务器的关闭可能导致以下断言失败。此问题的原因是，当关闭导致启动进程退出时，即使恢复时事务跟踪已经初始化，也不会关闭，并且被跟踪事务持有的一些锁无法释放。在这种情况下，如果调用了其他进程，并且启动进程使用的 PGPROC 条目被分配给它，它会发现这些未释放的锁，并在其初始化期间导致断言失败。TRAP：FailedAssertion("SHMQueueEmpty(&(MyProc->myProcLocks[i]))") 此提交通过使启动进程在退出时关闭事务跟踪并释放所有锁来修复此问题。向所有支持的分支进行回溯。报告人：Maxim Orlov 作者：Fujii Masao 审核人：Maxim Orlov 讨论：https://postgr.es/m/ad4ce692cc1d89a093b471ab1d969b0b@postgrespro.ru https://git.postgresql.org/pg/commitdiff/ad8b674922eb70dc5cd02951dd82fe2c4c37c80a

  • 添加函数以记录指定后端进程的内存上下文。提交 3e98c0bafb 添加了 pg_backend_memory_contexts 视图以显示后端进程的内存上下文。但是，它的目标进程仅限于访问该视图的后端。因此，在调查其他后端进程的本地内存膨胀时，这不是很方便。为了改善这种情况，此提交添加了 pg_log_backend_memory_contexts() 函数，该函数请求记录指定后端进程的内存上下文。此信息也可以通过调试器调用 MemoryContextStats(TopMemoryContext) 来收集。但是，此技术在某些环境中无法使用，因为那里没有可用的调试器。因此，pg_log_backend_memory_contexts() 使我们可以更轻松地查看指定后端的内存上下文。只允许超级用户请求记录内存上下文，因为允许任何用户以无限制的速率发出此请求会导致大量日志消息，并可能导致拒绝服务。收到请求后，在下一个 CHECK_FOR_INTERRUPTS()，目标后端会在 LOG_SERVER_ONLY 级别记录其内存上下文，以便这些内存上下文会出现在服务器日志中，但不会发送给客户端。它为每个内存上下文记录一条消息。因为如果它将所有内存上下文缓冲到 StringInfo 中以将其作为一条消息记录，则可能需要非常大地扩大缓冲区，并导致 OOM 错误，因为后端中可能存在大量内存上下文。当后端进程消耗大量内存时，记录其所有内存上下文可能会超出可用磁盘空间。为了防止这种情况，现在此补丁将每个父级要记录的子上下文数量限制为 100 个。与 MemoryContextStats() 一样，它假设日志变长的实际情况通常是同一父上下文下的大量同级；而看到 100 个以上同级内存的详细信息带来的额外调试价值不大。在讨论中，还有另一个提议的补丁，用于添加函数，以返回指定后端的内存上下文作为结果集，而不是记录它们。但是，该补丁未包含在此提交中，因为它有几个问题需要解决。感谢 Tatsuhito Kasahara、Andres Freund、Tom Lane、Tomas Vondra、Michael Paquier、Kyotaro Horiguchi 和 Zhihong Yu 的讨论。更新目录版本。作者：Atsushi Torikoshi 审核人：Kyotaro Horiguchi、Zhihong Yu、Fujii Masao 讨论：https://postgr.es/m/0271f440ac77f2a4180e0e56ebd944d1@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/43620e328617c1f41a2a54c8cee01723064e3ffa

  • 修复 pgstat.c 中的拼写错误。由 9868167500 引入。作者：Vignesh C 讨论：https://postgr.es/m/CALDaNm1DqgaLBAJrtGznKk1sR1mH-augmp7LfGvxWwTUhah+rg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f5d94e405e17a49487672316610630be2f9d0bb7

  • 如果发现使用 wal_level=minimal 生成的 WAL，则停止归档恢复。以前，如果启用了热备用，则当归档恢复发现使用 wal_level=minimal 生成的 WAL 时，会以错误退出。但是，如果禁用了热备用，则在这种情况下，它只会报告警告并继续。这可能会导致正常操作期间的数据丢失或错误。会发出警告，但用户很容易错过该警告，并且在遇到实际错误之前不会注意到这种严重情况。为了改善这种情况，此提交更改了归档恢复，以便无论热备用的设置如何，当它发现使用 wal_level=minimal 生成的 WAL 时，都会以 FATAL 错误退出。这使使用者可以很快注意到严重情况。如果归档恢复从将 wal_level 更改为 minimal 之前拍摄的基本备份开始，则会引发 FATAL 错误。当归档恢复以错误退出时，如果用户具有在将 wal_level 设置为高于 minimal 之后拍摄的基本备份，则可以通过从该较新的备份开始归档恢复来恢复数据库。但是请注意，如果不存在此类备份，则没有简单的方法来完成归档恢复，这可能会使数据库服务器无法启动，并且用户可能会丢失整个数据库。该提交在文档中添加了有关此风险的说明。即使在数据库服务器无法启动的情况下，以前只需禁用热备用，用户就可以避免在归档恢复期间发生错误，强制启动服务器并从中挽救数据。但是请注意，此提交使此过程完全不可用。作者：Takamichi Osumi 审核人：Laurenz Albe、Kyotaro Horiguchi、David Steele、Fujii Masao 讨论：https://postgr.es/m/OSBPR01MB4888CBE1DA08818FD2D90ED8EDF90@OSBPR01MB4888.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/9de9294b0c4dac77edb80f029648afca79d14653

  • postgres_fdw：允许导入在 LIMIT TO 中指定的分区。提交 f49bcd4ef3 禁止 postgres_fdw 导入表分区。因为可以通过作为分区层次结构根的分区表访问所有数据，所以仅导入分区表应该允许访问所有数据，而无需创建额外的对象。在导入整个模式时，这是一个合理的默认设置。但是，可能存在用户想要显式导入分区表的分区之一的情况。对于该用例，此提交允许 postgres_fdw 导入仅在 LIMIT TO 子句中显式指定的表或外表，这些表是某些其他表的分区。它不会更改在 IMPORT FOREIGN SCHEMA 命令中自动排除 LIMIT TO 中未指定的任何分区的行为。作者：Matthias van de Meent 审核人：Bernd Helmle、Amit Langote、Michael Paquier、Fujii Masao 讨论：https://postgr.es/m/CAEze2Whwg4i=mzApMe+PXxCEfgoZmHGqdqQFW7J4bmj_5p6t1A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a3740c48eb2f91663c7c06c948dfcfb6493d2588

  • 修复提交 9de9294b0c 添加的测试。构建场成员“drongo”和“fairywren”报告说，提交 9de9294b0c 添加的回归测试 (024_archive_recovery.pl) 失败。此失败的原因是测试在没有“allows_streaming => 1”的情况下调用 $node->init()，这不会为来自 pg_basebackup 的 TCP/IP 连接添加 pg_hba.conf 条目。此提交通过在调用 $node->init() 时指定“allows_streaming => 1”来修复此问题。作者：Fujii Masao 讨论：https://postgr.es/m/3cc3909d-f779-7a74-c201-f1f7f62c7497@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/8ee9b662daa6d51b54d21ec274f22a218462ad2d

  • 允许 TRUNCATE 命令截断外表。此提交为 TRUNCATE 引入了新的外部数据包装器 API。它扩展了 TRUNCATE 命令，使其接受外表作为要截断的目标，并调用该 API。此外，它还扩展了 postgres_fdw，使其可以通过为该 TRUNCATE API 添加新例程来向外部服务器发出 TRUNCATE 命令。TRUNCATE 命令中指定的选项（例如，ONLY、CACADE 等）的信息通过 API 传递给 FDW。要截断的外表列表也会传递给 FDW。FDW 根据这些信息截断传递的外表指定的外部数据源。例如，postgres_fdw 使用它们构造 TRUNCATE 命令并将其发送到外部服务器。为了提高性能，TRUNCATE 命令为每个要截断的外表所属的外部服务器调用一次 FDW 例程。作者：Kazutaka Onishi、Kohei KaiGai，由 Fujii Masao 略作修改。审核人：Bharath Rupireddy、Michael Paquier、Zhihong Yu、Alvaro Herrera、Stephen Frost、Ashutosh Bapat、Amit Langote、Daniel Gustafsson、Ibrar Ahmed、Fujii Masao 讨论：https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com 讨论：https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8ff1c94649f5c9184ac5f07981d8aea9dfd7ac19

  • 删除 COMMIT_TS_SETTS 记录。提交 438fc4a39c 阻止 WAL 重放写入 COMMIT_TS_SETTS 记录。通过此更改，在 PostgreSQL 核心中没有代码生成 COMMIT_TS_SETTS 记录。此外，我们可以认为没有扩展使用该记录，因为我们到目前为止没有收到任何关于提交 438fc4a39c 修复的问题的投诉。因此，此提交删除了 COMMIT_TS_SETTS 记录及其相关代码。即使没有此记录，也可以从 COMMIT 记录中获取提交时间戳功能所需的时间戳。更新 WAL 页面魔术值。报告人：lx zou zoulx1982@163.com 作者：Fujii Masao 审核人：Alvaro Herrera 讨论：https://postgr.es/m/16931-620d0f2fdc6108f1@postgresql.org https://git.postgresql.org/pg/commitdiff/08aa89b326261b669648df97d4f2a6edba22d26a

  • 避免在 TRUNCATE 命令中不必要的表打开/关闭操作。ExecuteTruncate() 函数会过滤掉 TRUNCATE 命令中重复指定的表，例如在执行 “TRUNCATE foo, foo” 的情况下。很明显，这些重复的表不需要打开和关闭，因为它们会被跳过。但之前，它总是在检查它们是否重复之前打开表，如果它们是重复的，则关闭它们。也就是说，重复的表被不必要地打开和关闭了。此提交更改了 ExecuteTruncate() 函数，使其在确认表不是重复的之后才打开表，从而避免了不必要的表打开/关闭操作。不进行回溯修补，因为这种不必要的表打开/关闭操作不是一个错误，尽管它存在于较旧的版本中。作者：Bharath Rupireddy 审核人：Amul Sul，Fujii Masao 讨论：https://postgr.es/m/CALj2ACUdBO_sXJTa08OZ0YT0qk7F_gAmRa9hT4dxRcgPS4nsZA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/81a23dd87999ec9fb62554328c69c5b678612d56

Stephen Frost 推送了此更改

  • 添加 pg_read_all_data 和 pg_write_all_data 角色。一个常见的要求是拥有一个角色，该角色可以运行不受限制的 pg_dump，而无需显式地授予该用户访问所有表、模式等的权限，并且该角色不是超级用户。此问题通过添加“pg_read_all_data”角色来解决，该角色隐式地授予该角色的任何成员对所有表、视图和序列的 SELECT 权限，以及对所有模式的 USAGE 权限。由于在某些情况下，拥有一个对所有对象具有写入权限的角色也可能很有用，因此还引入了 pg_write_all_data，它授予用户对所有表、视图和序列的隐式 INSERT、UPDATE 和 DELETE 权限。这些角色不能直接登录，而应该 GRANT 给一个能够登录的角色。正如文档中指出的那样，如果正在使用 RLS，那么管理员可能（也可能不）希望在这些预定义角色被 GRANT 的登录角色上设置 BYPASSRLS。审核人：Georgios Kokolatos 讨论：https://postgr.es/m/20200828003023.GU29590@tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/6c3ffd697e2242f5497ea4b40fffc8f6f922ff60

Peter Geoghegan 推送了此更改

  • 简化 VACUUM 管理的状态。重新组织 VACUUM 使用的状态结构 - 将相关项组合在一起，使其更易于理解。此外，停止依赖 lazy_scan_heap() 内的堆栈变量 - 将这些变量移动到状态结构中。这样做简化了大量相关函数，这些函数的函数签名存在许多不必要的冗余。切换到使用 int64 作为用于计算通过 log_autovacuum 和 VACUUM VERBOSE 输出报告给用户的事务的结构字段。我们之前使用的是 double，但这似乎没有任何优势。使用 int64 可以添加断言，验证在堆上的第一次传递（修剪）中遇到的 LP_DEAD 项目的数量与稍后在堆上的第二次传递中从索引中删除的数量完全相同。这些断言将在后续的提交中添加。最后，在参数与单个索引或所有索引相关存在歧义的情况下，调整具有 IndexBulkDeleteResult 指针参数的函数的签名。函数现在使用 ambulkdelete() 和 amvacuumcleanup() 一直使用的惯用法（在适当的情况下）：接受可变的 IndexBulkDeleteResult 指针参数，并返回一个结果 IndexBulkDeleteResult 指针给调用者。作者：Peter Geoghegan pg@bowt.ie 审核人：Masahiko Sawada sawada.mshk@gmail.com 审核人：Robert Haas robertmhaas@gmail.com 讨论：https://postgr.es/m/CAH2-WzkeOSYwC6KNckbhk2b1aNnWum6Yyn0NKP9D-Hq1LGTDPw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b4af70cb210393c9c8f41643acf6b213e21178e7

  • 传播并行 VACUUM 的缓冲区访问策略。并行 VACUUM 依赖于从 leader 进程 fork() 时传播给 worker 的全局变量状态。提交 b4af70cb 删除了 vacuumlazy.c 内部的大多数全局变量使用，但没有考虑缓冲区访问策略状态。为了修复，改为通过共享内存传播状态。根据 elver、curculio 和 morepork 上的构建场故障。非常感谢 Thomas Munro 在此问题上提供的非列表帮助。https://git.postgresql.org/pg/commitdiff/49f49defe7c0a330cca084de5da14ccdfdafc6a3

  • 在并行 VACUUM worker 中分配访问策略。提交 49f49def 采用了完全错误的方法来解决此问题。只需在每个单独的 worker 中分配一个本地缓冲区访问策略，而不是尝试传播状态。此状态从一开始就从未被并行 VACUUM 传播。看起来提交 40d964ec 之后之所以能工作，唯一的原因是它涉及静态全局变量，根据 C 标准，这些变量被初始化为 0。可能需要更全面的修复，即使在 HEAD 中也是如此。此修复至少应该使构建场再次变为绿色。再次感谢 Thomas Munro 在此问题上提供的持续非列表帮助。https://git.postgresql.org/pg/commitdiff/f6b8f19a084ce949522fcbc940dc116c034cfc47

  • 重构 lazy_scan_heap() 循环。添加一个 lazy_scan_heap() 子函数，用于处理堆修剪和元组冻结：lazy_scan_prune()。这更加清晰。现在，lazy_scan_heap() 的每个块循环中保留的代码可以被认为是 lazy_scan_prune() 调用之前或之后出现的代码，而 lazy_scan_prune() 现在是明确的焦点。这种划分是通过我们现在管理状态的方式来强制执行的。lazy_scan_prune() 输出状态（使用其自身的结构），描述在修剪和冻结后如何处理页面（例如，可见性图维护，记录 FSM 中的可用空间）。它不会从前言代码传递任何特殊的指令状态。此外，将使用 INDEX_CLEANUP=off 的 VACUUM 使用的逻辑与单堆传递 VACUUM 使用的逻辑完全分开。前一种情况现在被构造为由两遍 VACUUM 省略索引和堆清理的情况。后一种情况仅在表恰好没有索引时才重新被使用（就像提交 a96c41fe 之前一样）。这种结构更加自然，因为 INDEX_CLEANUP=off 的全部意义在于跳过否则会发生的索引和堆清理。但是，单堆传递的情况不会跳过任何有用的工作 - 它只是在表恰好没有索引时一起执行堆修剪和堆清理。这两个更改都是为即将到来的补丁做准备，该补丁将概括 INDEX_CLEANUP=off 使用的机制。后续的补丁将允许 VACUUM 动态地放弃索引和堆清理，随着问题的出现（例如，环绕），以便受影响的 VACUUM 操作可以尽快完成。此外，修复了单传递 VACUUM VERBOSE 输出中的一个非常旧的错误。我们之前将通过修剪删除的元组数量作为报告在处理堆的第二遍的函数中删除的 LP_DEAD 项目数量的直接替代。但这根本行不通 - 它们是两个不同的事物。为了修复，开始跟踪修剪期间遇到的 LP_DEAD 项目的总数，并在报告中使用它。单传递 VACUUM 将始终清理掉堆页面在修剪后立即拥有的任何 LP_DEAD 项目，因此修剪期间遇到的 LP_DEAD 项目总数等于清理掉的总数。（在 INDEX_CLEANUP=off 的情况下，它们不相等，但这没关系，因为跳过索引清理现在是一个完全正交于单传递 VACUUM 的概念。）此外，停止在 VACUUM VERBOSE 输出中报告 LP_UNUSED 项目的数量。这使得 VACUUM VERBOSE 的输出与 log_autovacuum 的输出更加一致（因为它从未显示有关 LP_UNUSED 项目的信息）。VACUUM VERBOSE 报告了上一次 VACUUM 留下的 LP_UNUSED 项目，以及在当前 VACUUM 期间通过修剪 HOT 链创建的 LP_UNUSED 项目（它从未包括当前 VACUUM 的第二遍在堆上留下的 LP_UNUSED 项目）。这使得它作为行指针膨胀的指标毫无用处，这肯定是最初的意图。（与第一个 VACUUM VERBOSE 问题类似，此问题可以说是在提交 282d2a03 中的一个疏忽，该提交添加了仅堆元组优化。）最后，停止在 VACUUM VERBOSE 输出中报告 empty_pages，并开始报告 pages_removed。这也使得 VACUUM VERBOSE 的输出与 log_autovacuum 的输出更加一致（它不显示 empty_pages，但会显示 pages_removed）。空页面与几乎为空的页面，或者仅剩下少量 LP_UNUSED 项目的空页面没有明显的区别。作者：Peter Geoghegan pg@bowt.ie 审核人：Robert Haas robertmhaas@gmail.com 审核人：Masahiko Sawada sawada.mshk@gmail.com 讨论：https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/7ab96cf6b312cfcd79cdc1a69c6bdb75de0ed30f

  • 从 vacuumlazy.c 中移除 tupgone 特例。在极少数情况下，当 heap_prune_page() 调用与紧随其后的 HeapTupleSatisfiesVacuum() 调用之间存在不一致时，重试对 heap_prune_page() 的调用。当并发中止的事务在每个步骤之间的小窗口期将元组标记为 DEAD 时，可能会出现不一致。这是唯一一种被 VACUUM 视为 DEAD 的元组在修剪后仍然有存储空间的情况。VACUUM 对死元组的定义现在统一简单且明确：来自每个页面的死元组始终是 LP_DEAD 行指针，这些指针是在我们执行修剪之后（以及在我们考虑冻结剩余带有元组存储的项目之前）遇到的。消除 tupgone=true 的特例，使得基于灵活的动态标准跳过索引清理 (INDEX_CLEANUP=off) 风格的索引清理成为可能。由于与该特例的微妙交互（见提交 dd695979），INDEX_CLEANUP=off 的情况必须在之前就了解跳过索引。这本身就是一个特例。现在没有特例了。因此，现在我们何时以及如何决定跳过索引清理都无关紧要：它不会影响修剪的行为，也不会受到修剪或冻结的任何实现细节的影响。同时删除 XLOG_HEAP2_CLEANUP_INFO 记录。这些记录不再是必需的，因为我们现在完全依赖堆修剪来处理恢复冲突。不再需要为修剪刚刚错过的 DEAD 元组生成恢复冲突。这也意味着堆清理现在使用与索引清理始终相同的恢复冲突策略：REDO 例程永远不需要处理 WAL 记录中的 latestRemovedXid，因为在所有情况下，更早的来自修剪的 WAL 记录的 REDO 都足够了。通用的 XLOG_HEAP2_CLEAN 记录类型现在分为两个新的记录类型，以反映这种新的划分（它们被称为 XLOG_HEAP2_PRUNE 和 XLOG_HEAP2_VACUUM）。在 VACUUM 的第二次堆遍历期间对堆页面进行清理时，也不再获取超级独占锁。常规的独占锁就足够了。这是正确的，因为堆页面清理现在严格来说是将 LP_DEAD 行指针设置为 LP_UNUSED 的问题。没有其他后端可以拥有指向固定缓冲区中元组的指针，该指针可能会被并发的堆页面清理操作无效。堆清理现在可以被认为是概念上类似于索引清理，而概念上不同于堆修剪。堆修剪现在对涉及数据库逻辑内容的任何事情负有全部责任（例如，管理事务状态信息、恢复冲突、考虑如何处理 HOT 链）。索引清理和堆清理现在只关心从支持逻辑数据库的物理数据结构中回收垃圾项目。由于修剪和堆页面 WAL 记录的更改，增加 XLOG_PAGE_MAGIC。重试修剪页面以避免 tupgone 情况的想法归功于 Andres Freund。作者：Peter Geoghegan pg@bowt.ie 审阅人：Andres Freund andres@anarazel.de 审阅人：Masahiko Sawada sawada.mshk@gmail.com 讨论：https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8523492d4e349c4714aa2ab0291be175a88cb4fc

  • 在 VACUUM 期间截断行指针数组。让 VACUUM 学会在每个堆页面的行指针数组末尾出现连续的 LP_UNUSED 行指针组时截断该数组——这些未使用的且未引用的项目将被排除在外。此过程发生在 VACUUM 第二次遍历堆期间，就在页面上的 LP_DEAD 行指针（在第一次遍历期间遇到/修剪的那些）被标记为 LP_UNUSED 之后。截断避免了某些工作负载中的行指针膨胀，尤其是那些涉及针对同一表进行的持续范围 DELETE 和批量 INSERT 的工作负载。同时加强 heapam 代码，以检查我们尚未执行的范围外的页面偏移量数字。作者：Matthias van de Meent boekewurm+postgres@gmail.com 作者：Peter Geoghegan pg@bowt.ie 审阅人：Masahiko Sawada sawada.mshk@gmail.com 审阅人：Peter Geoghegan pg@bowt.ie 讨论：https://postgr.es/m/CAEze2WjgaQc55Y5f5CQd3L=eS5CZcff2Obxp=O6pto8-f0hC4w@mail.gmail.com 讨论：https://postgr.es/m/CAH2-Wzn6a64PJM1Ggzm=uvx2otsopJMhFQj_g1rAj4GWr3ZSzw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3c3b8a4b26891892bccf3d220580a7f413c0b9ca

  • 向 VACUUM 添加回绕保护。添加一个由 VACUUM 触发的保护机制，当它注意到表的 relfrozenxid 和/或 relminmxid 严重滞后时。VACUUM 会定期动态检查表的年龄。当保护触发时，VACUUM 会采取非常措施，以尽快完成，以便可以推进 relfrozenxid 和/或 relminmxid。VACUUM 将停止应用任何可能生效的基于成本的延迟。VACUUM 还会绕过任何进一步的索引清理和堆清理——它只会完成所需的剩余修剪和冻结。通过提交 8523492d 启用了绕过索引/堆清理的功能，该提交使得当 VACUUM 在 INDEX_CLEANUP 关闭的情况下运行时，可以动态触发 VACUUM 中已使用的机制。预计保护机制几乎总是在自动清理中触发，以防止回绕，这在自动清理开始很久之后。但是，保护机制可以在任何 VACUUM 操作中触发。即使在非激进的 VACUUM 中，我们可能不会推进 relfrozenxid，完成剩余的修剪和冻结似乎仍然是个好主意。之后将立即启动激进/反回绕的 VACUUM。请注意，随后的反回绕 VACUUM 本身会触发保护机制，通常甚至在其开始第一次（也是唯一一次）遍历堆之前。保护机制由两个新的 GUC 控制：vacuum_failsafe_age 和 vacuum_multixact_failsafe_age。没有等效的 reloptions，因为这预计没有用。GUC 具有相当高的默认值（两者都默认为 16 亿），并且预计通常仅用于使保护机制更快/更频繁地触发。作者：Masahiko Sawada sawada.mshk@gmail.com 作者：Peter Geoghegan pg@bowt.ie 讨论：https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com 讨论：https://postgr.es/m/CAH2-WzmgH3ySGYeC-m-eOBsa2=sDwa292-CFghV4rESYo39FsQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1e55e7d1755cefbb44982fbacc7da461fa8684e6

  • 教 VACUUM 跳过不必要的索引清理。在第一次遍历堆（在这种情况下也是唯一一次遍历）结束时，如果其 dead_tuples 数组中恰好有零个 TID，则 VACUUM 从来不需要为每个索引调用 ambulkdelete()。发生这种情况时，根本不需要进行索引清理。索引清理仍然会继续进行，但实际上，当先前没有零次 ambulkdelete() 调用时，大多数对 amvacuumcleanup() 的调用通常都是空操作。简而言之，当显然没有索引元组要从索引中删除时，VACUUM 通常设法避免了索引扫描。但是，要删除的索引元组接近零的情况是另一回事——进行了一轮 ambulkdelete() 调用（每个索引一次），每次调用都会执行完整的索引扫描。在实际上有“几乎为零”个此类元组的情况下，VACUUM 现在表现得就像有零个索引元组要删除一样。也就是说，它现在可以跳过索引清理和堆清理作为优化（尽管不是索引清理）。VACUUM 是否绕过索引是动态确定的，基于刚刚观察到的表中具有一个或多个 LP_DEAD 项目的堆页数（堆页面中的 LP_DEAD 项目与最坏情况下仍然需要从每个索引中删除的索引元组具有 1:1 的对应关系）。当表中只有 2% 或更少的页面具有一个或多个 LP_DEAD 项目时，我们才跳过索引清理——作为优化的跳过索引清理不能明显阻碍在可见性映射中设置位。作为进一步的条件，在第一次遍历堆结束时，dead_tuples 数组（即 VACUUM 的 LP_DEAD 项目 TID 数组）不得超过 32MB，这也是做出跳过决定的时间点。（VACUUM 还必须能够将其所有 TID 容纳在其 maintenance_work_mem 界限的 dead_tuples 空间中，尽管使用默认的 maintenance_work_mem 设置并不重要。）这避免了例行清理的持续时间和开销出现令人惊讶的跳跃，在工作负载中，连续的 VACUUM 操作始终几乎没有死索引元组。LP_DEAD 项目的数量可能会在多个 VACUUM 操作中累积，然后最终才超过阈值，并且 VACUUM 执行传统的索引清理。即使这样，该优化也将避免大量基本不必要的索引清理。将来，我们可能会教 VACUUM 基于每个索引跳过索引清理，使用一种更加复杂的方法。目前，我们只考虑极端情况，在这种情况下，我们可以相当确信，使用简单的启发式方法，索引清理根本不值得。当启用自动清理日志记录时，还会记录有关有多少堆页面具有一个或多个 LP_DEAD 项目的信息。作者：Masahiko Sawada sawada.mshk@gmail.com 作者：Peter Geoghegan pg@bowt.ie 讨论：https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com 讨论：https://postgr.es/m/CAH2-WzmkebqPd4MVGuPTOS9bMFvp9MDs5cRTCOsv1rQJ3jCbXw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5100010ee4d5c8ef46619dbd1d17090c627e6d0a

  • 消除另一个 _bt_check_unique 编译器警告。根据 Tom Lane 的投诉 讨论：https://postgr.es/m/1922884.1617909599@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/796092fb84c08162ae803e83a13aa8bd6d9b23d0

Amit Kapila 推送

David Rowley 推送了

  • 修复 fe-trace.c 中针对 MSVC 的编译器警告。看起来在 MSVC 中，timeval 的 tv_sec 字段类型为 long。localtime() 接受一个 time_t 指针。由于 long 在 MSVC 中即使在 64 位构建上也是 32 位的，因此传递一个 long 指针而不是正确的 time_t 指针会生成一个编译器警告。修复了这个问题。审核人：Tom Lane 讨论：https://postgr.es/m/CAApHDvoRG25X_=ZCGSPb4KN_j2iu=G2uXsRSg8NBZeuhkOSETg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9bc9b4609a246ded5caf3f3d4c0013a002ba2323

  • 修复 libpq_pipeline.c 中针对 MSVC 的编译器警告。DEBUG 已经被 MSVC 工具链为“Debug”构建定义了。在这些系统上，无条件的 #define DEBUG 导致了 'DEBUG': 宏重定义的警告。这里我们将 DEBUG 重命名为 DEBUG_OUPUT，并且去掉了定义这个常量的 #define。这似乎是错误地遗留在代码中的。讨论：https://postgr.es/m/CAApHDvqTTgDm38s4HRj03nhzhzQ1oMOj-RXFUB1pE6Bj07jyuQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3b82d990ab784881153c0f127e4c1211e9b6065c

  • 清理分区裁剪步骤生成。gen_prune_steps_from_opexps 中的一些代码不必要地检查列表是否为空，而该列表显然必须包含至少一项。这促使在 partprune.c 中进行了进一步的清理操作。此外，之前的代码可能会最终添加额外的无用的 INTERSECT 步骤。然而，这些似乎不会导致任何错误行为。gen_prune_steps_from_opexps 现在不再负责生成组合裁剪步骤。相反，gen_partprune_steps_internal 已经负责生成所有组合步骤，它已经进行了一些组合步骤的创建。这意味着当我们递归调用 gen_partprune_steps_internal 时，因为它现在总是在生成多个步骤时添加一个组合步骤，我们只需要关注返回的最终步骤。顺便说一句，对注释进行大量修改，以尝试更清楚地解释 gen_partprune_steps_internal 和 gen_prune_steps_from_opexps 的作用。这是一段相当复杂的代码，因此为新读者提供关于事物如何工作的概述似乎是一个好主意。作者：Amit Langote 报告人：Andy Fan 审核人：Kyotaro Horiguchi、Andy Fan、Ryan Lambert、David Rowley 讨论：https://postgr.es/m/CAKU4AWqWoVii+bRTeBQmeVW+PznkdO8DfbwqNsu9Gj4ubt9A6w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5ac9c4307337313bedeafc21dbbab93ba809241c

  • 加速 ScalarArrayOpExpr 评估。具有 "useOr=true" 并且右侧有一组 Consts 的 ScalarArrayOpExprs 传统上是通过对数组进行线性搜索来评估的。当这些数组包含大量元素时，这种线性搜索可能会成为执行时间的重要组成部分。这里我们添加了一种新的评估 ScalarArrayOpExpr 表达式的方法，允许通过首先构建一个包含每个元素的哈希表来评估它们，然后在后续评估中，我们只需探测该哈希表来确定是否存在匹配项。规划器负责确定何时可以进行此优化，并通过在 ScalarArrayOpExpr 中设置 hashfuncid 来启用它。执行器仅在设置了 hashfuncid 时才执行哈希表评估。这意味着并非所有情况都进行了优化。例如，包含 IN 子句的 CHECK 约束不会通过规划器，因此不会设置 hashfuncid。我们可能会在稍后的日期处理这个问题。我们现在不这样做的原因是担心我们可能会减慢仅评估一次表达式的情况。这些情况可能很常见，例如，向包含 IN 子句的 CHECK 约束的表中插入单行。在规划器中，当 ScalarArrayOpExpr 的运算符有合适的哈希函数时，并且仅当数组中至少有 MIN_ARRAY_SIZE_FOR_HASHED_SAOP 个元素时，我们才会启用此功能。该阈值当前设置为 9。作者：James Coleman，David Rowley 审核人：David Rowley、Tomas Vondra、Heikki Linnakangas 讨论：https://postgr.es/m/CAAaqYe8x62+=wn0zvNKCj55tPpg-JBHzhZFFc6ANovdqFw7-dA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/50e17ad281b8d1c1b410c9833955bc80fbad4078

  • 改进 nodeFuncs.c 中稍微有误导性的注释。nodeFuncs.c 中有一些注释，根据您对“result”一词的解释，可能会让您认为这些注释是从其他地方错误地复制和粘贴的。如果您将“result”理解为注释所在的函数的返回值，那么您就会被误导。但是，如果您正确地将“result”解释为给定节点类型的结果类型，那么您就不会看到任何问题。这里我们进行一个小清理，以尝试防止将来出现任何误解。根据 Tom Lane 的措辞建议。审核人：Tom Lane 讨论：https://postgr.es/m/CAApHDvp+Bw=2Qiu5=uXMKfC7gd0+B=4JvexVgGJU=am2g9a1CA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/152d33bccec7176f50be225bdbedf2e6de214e54

Etsuro Fujita 推送了

Dean Rasheed 推送了

  • pgbench：用于生成随机排列的函数。这增加了一个新函数 permute()，它可以生成任意大小的伪随机排列。这可以用来随机打乱一组值以消除不必要的关联。例如，置换来自非均匀随机分布的输出，使所有最常见的值不会并置，从而可以执行更真实的测试。以前，建议将 hash() 用于此目的，但它会受到可能改变分布的冲突的影响，因此建议改用 permute()。Fabien Coelho 和 Hironobu Suzuki，由我进行额外的修改。Thomas Munro、Alvaro Herrera 和 Muhammad Usama 审核。讨论：https://postgr.es/m/alpine.DEB.2.21.1807280944370.5142@lancre https://git.postgresql.org/pg/commitdiff/6b258e3d688db14aadb58dde2a72939362310684

Heikki Linnakangas 推送了

Tomáš Vondra 推送了

  • 修复与扩展统计信息不兼容的子句的处理。在应用扩展统计信息时，对不兼容子句的处理有点混乱 - 在处理兼容和不兼容子句的混合时，有时会错误地将不兼容子句视为兼容，从而导致崩溃。通过重新编写应用所选统计信息对象的代码，使其更易于理解，并添加适当的兼容性检查来修复了此问题。报告人：David Rowley 讨论：https://postgr.es/m/CAApHDvpYT10-nkSp8xXe-nbO3jmoaRyRFHbzh-RWMfAJynqgpQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/518442c7f334f3b05ea28b7ef50f1b551cfcc23e

  • 不要从 BRIN 向位图添加不存在的页面。bringetbitmap() 中的代码只是将整个匹配的页面范围（由 pages_per_range 确定）添加到 TID 位图，即使某些页面超出了堆的末尾。然后查询可能会失败，并出现如下错误：ERROR：无法打开文件“base/20176/20228.2”（目标块 262144）：上一段只有 131021 个块 在这种情况下，该关系有 262093 个页面（131072 和 131021 个页面），但我们试图访问块 262144，即第三段的第一个块。此时，_mdfd_getseg() 注意到前一段不完整，因此失败。在实践中遇到这种情况的可能性很小，因为

  • 大多数索引使用 2 的幂范围，因此段和页面范围完美对齐（段结尾也是页面范围结尾）。* 表的大小必须恰到好处，最后一个段几乎已满 - 距离满段不到一个页面范围，以便最后一个页面范围实际上跨越段边界。* 必须启用预取。常规页面访问会检查页面是否超出堆末尾，但预取不会。在较旧的版本（12 之前）中，执行会在遇到第一个不存在的页面后停止，因此预取距离必须足以到达下一段中的第一个页面以触发该问题。自 12 以来，只需启用预取就足够了，预取距离无关紧要。通过不向 TID 位图添加不存在的页面来修复此问题。向后移植到 9.6（BRIN 索引是在 9.5 中引入的，但该版本已 EOL）。向后移植：9.6 https://git.postgresql.org/pg/commitdiff/23607a8156d595522c232ff3933d77041d3adaa1

Andres Freund 推送了

Magnus Hagander 推送了

Robert Haas 推送了

  • amcheck：删除重复的 XID/MXID 边界检查。提交 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0 导致在 check_tuple() 和 check_tuple_visibility() 中执行相同的 xmin 和 xmax 边界检查。删除重复项。同时，调整该提交中被忽略的一些代码注释。Mark Dilger 讨论：http://postgr.es/m/AC5479E4-6321-473D-AC92-5EC36299FBC2@enterprisedb.com https://git.postgresql.org/pg/commitdiff/4573f6a9af6e232ba073392716a051ae2017d1e9

  • amcheck：修复 TOAST 指针验证的多个问题。首先，不要在持有缓冲区锁定时执行数据库访问。在检查堆时，我们可以通过对 TOAST 索引执行扫描并查找与主表中 TOAST 指针中出现的每个值 ID 对应的块来验证 TOAST 指针是否正常。但是，在持有缓冲区锁定时执行此操作至少可能会导致其他后端不可中断地等待，并且可能会导致未检测到且不可中断的死锁。因此，改为创建一个要在持有锁定时执行的检查列表，然后在释放锁后执行检查。其次，调整事物，以便我们不会尝试跟踪已经符合修剪条件的元组的 TOAST 指针。TOAST 元组与主元组同时符合修剪条件，因此尝试检查它们可能会导致虚假的损坏报告，就像在构建场中观察到的那样。提交 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0 添加了确定正在检查的元组是否可修剪的必要基础设施，但是在此补丁之前，它实际上并未用于其预期目的。Mark Dilger，我进行了调整以避免内存泄漏。讨论：http://postgr.es/m/AC5479E4-6321-473D-AC92-5EC36299FBC2@enterprisedb.com https://git.postgresql.org/pg/commitdiff/ec7ffb8096e8eb90f4c9230f7ba9487f0abe1a9f

Bruce Momjian 推送了

Thomas Munro 推送了

Noah Misch 推送

待处理的补丁

Bharath Rupireddy 发送了另一个补丁修订版，以添加用于多插入和单插入的表 AM，并将其用于 CTAS、REFRESH MATERIALIZED VIEW 和 COPY。

Sait Talha Nisanci 发送了另一个补丁修订版，旨在修复一个在 `record_type_typmod_compare` 中表现为崩溃的错误。

Bharath Rupireddy 发送了另外两个补丁修订版，以澄清由于向发布添加非表而导致的错误消息，命名对象的类型而不是它不是的类型（表）。

Jaime Casanova 发送了一个补丁，使用 AV 工作项基础设施清理 GIN 待处理列表。

Jürgen Purtz 发送了另一个补丁修订版，在教程中添加了关于架构的章节。

Andres Freund 发送了另一个补丁修订版，将统计收集器的临时存储从文件移动到共享内存。

Amul Sul 发送了另外三个补丁修订版，以实现 `ALTER SYSTEM READ {ONLY | WRITE}`。

Michaël Paquier 发送了另一个补丁修订版，使可以使用 NSS 作为 libpq TLS 后端。

Vigneshwaran C、Amit Kapila 和 Masahiko Sawada 交换了补丁，以使用 HTAB 作为复制槽统计。

Bruce Momjian 发送了两个补丁修订版，以修复和澄清间隔算术中某些极端情况的文档。

Jaime Casanova 发送了一个补丁，记录了 BRIN 的 autosummarize 参数默认关闭的事实。

Heikki Linnakangas 发送了另一个补丁修订版，通过强制前瞻来简化 `COPY FROM` 解析。

Bruce Momjian 发送了另一个补丁修订版，以实现密钥管理。

Amit Langote 发送了另外两个补丁修订版，以允许在跨分区更新期间批量插入。

Bertrand Drouvot 发送了另外三个补丁修订版，使备机上可以进行最小逻辑解码。

Himanshu Upadhyaya 发送了两个补丁修订版，以修复 `PREPARE TRANSACTION` 和临时表之间的不一致性。

Thomas Munro 和 Kyotaro HORIGUCHI 交换了补丁，以从 `XLogReadRecord` 中删除 `read_page` 回调。

Justin Pryzby 发送了另外两个补丁修订版，以使 `pg_ls_*` 显示目录和共享文件集。

Hou Zhijie、Masahiko Sawada、Amit Langote 和 Shi Yu 交换了补丁，以解决逻辑复制中的表引用泄漏。

Fabien COELHO 和 Michaël Paquier 交换了补丁，为 psql 添加 `SHOW_ALL_RESULTS` 选项。

Takamichi Osumi 发送了另一个补丁修订版，使可以禁用 WAL 日志记录以加速数据加载。

Yugo Nagata 发送了另一个补丁修订版，以实现增量视图维护。

Michael Banck 发送了另一个补丁修订版，以添加新的 `PGC_ADMINSET` GUC 上下文、管理员，并添加一个 `pg_change_role_settings` 预定义角色。

Pavel Borisov 发送了一个补丁，以确保在页面初始化期间对页面头和页面特殊大小对齐进行相同的处理。现在，两者都只是检查是否与断言正确对齐，而不会静默地 `MAXALIGN` 任何内容。调用者应将正确 `maxalinged` 的值传递到页面初始化函数中。

Thomas Munro 发送了另一个补丁修订版，为 psql 的 `\watch` 命令添加 `PSQL_WATCH_PAGER` 设置。

Tom Lane 发送了另外三个补丁修订版，使 psql `\df` 可以通过参数选择函数。

Vigneshwaran C 发送了另一个补丁修订版，以在 `CREATE/ALTER SUBSCRIPTION` 期间识别来自发布者的缺失发布。

Ajin Cherian 和 Amit Kapila 交换了补丁，以添加有关流式传输进行中事务的缺失文档。

Peter Smith 发送了另外三个补丁修订版，以添加两阶段事务的逻辑解码。

Thomas Munro 发送了另一个补丁修订版，以实现 WAL 预取。

Thomas Munro 和 Andrey Borodin 交换了补丁，使所有 SLRU 缓冲区大小可配置。

Andrey V. Lepikhov 发送了另一个补丁修订版，以删除 64k 范围表限制。

Haotian Wu 发送了一个补丁，为 `pg_dump/restore` 添加 `--drop-cascade`。

Bharath Rupireddy 发送了一个补丁，禁止 `CREATE SEQUENCE` 的 `RESTART` 选项，因为它仅在 `ALTER SEQUENCE` 的情况下才有意义。

Andres Freund 发送了一个补丁，以修复 `InvalidateObsoleteReplicationSlots()` 中的竞争条件，并重新删除 `SlotAcquireBehavior`。

Bharath Rupireddy 发送了三个补丁修订版，以简化 postgres_fdw 测试中的后端终止和等待逻辑。

Justin Pryzby 发送了另一个补丁修订版，将 `track_activity_query_size` 从以前正确的“资源使用/内存”类别更改为 `STATS_COLLECTOR` 类别，将 `log_autovacuum_min_duration` 更改为 `LOGGING_WHAT`，将 `track_commit_timestamp` 更改为 `REPLICATION_SENDING`，将 `force_parallel_mode` 更改为 `DEVELOPER` GUC，并将其从示例配置中删除，以帮助避免用户找到此选项并在不阅读文档或理解其作用的情况下更改它，希望这将使他们的查询更快。

Justin Pryzby 发送了另一个补丁修订版，以加快 `COPY FROM` 到带有外部分区的分区表的速度。

Thomas Munro 发送了一个补丁，使用 SIGIO 检测 postmaster 死亡。

Pavel Borisov 发送了一个补丁，以稳定分区索引的表空间测试。在进行表空间测试时，有时（很少）父表和子表的顺序会发生变化，导致测试失败。

Maxim Orlov 发送了另一个补丁修订版，旨在修复在大量连接/断开连接时表现为 SSL 协商错误的错误。

Andrey V. Lepikhov 发送了另一个补丁修订版，通过教导优化器考虑非分区表与分区表的每个分区进行分区连接，使非对称分区连接更有效地工作。此技术会导致对“按子参数化”机制的更改。

Michaël Paquier 发送了一个补丁，将表空间路径的重新创建从 makefile 移动到 pg_regress。

Pavel Stěhule 发送了另一个补丁修订版，以实现模式变量。

Tom Lane 提交了一个补丁，旨在修复一个因类型而导致的引用泄漏错误。该补丁放弃了将长期存在的 tupdesc 引用计数与这些表达式节点相关联的做法，而是依赖于类型缓存条目一旦创建就不会消失的事实。

Rémi Lapeyre 提交了三个修订版本的补丁，以向 "COPY TO" 文本格式添加标题支持，并为 "COPY FROM" 添加相应的标题匹配模式。

Justin Pryzby 提交了另一个修订版本的补丁，以使 ALTER TABLE ... DETACH CONCURRENTLY 避免创建冗余约束。

Pavel Stěhule 提交了另一个修订版本的补丁，以向 pg_dump/pg_restore 添加一个 --options-file 选项。

Tom Lane 提交了一个补丁，使 PGWARNING 和 PGERROR 全局可用。

Peter Geoghegan 提交了一个补丁，旨在修复一个错误，该错误表现为 PANIC: 传递给 visibilitymap_clear 的缓冲区错误，方法是在 lazy_vacuum_heap_rel() 中再次获取超级独占锁。

Ranier Vilela 提交了一个补丁，以修复 src/backend/statistics/extended_stats.c 中未初始化的标量变量。