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

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

由 PWN 发布于 2021-04-05
PWN

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

本周人物: https://postgresql.life/post/jan_karremans/

PostgreSQL 产品新闻

Ora2Pg 21.1 发布，这是一个用于将 Oracle 数据库迁移到 PostgreSQL 的工具。 https://github.com/darold/ora2pg/blob/master/changelog

pgtt 2.3 发布，这是一个用于实现全局临时表的扩展。 https://github.com/darold/pgtt/releases/tag/v2.3

SB Data Generator 发布，这是一个用于生成测试数据并填充数据库的 GUI 工具。 SB 数据生成器

四月份 PostgreSQL 工作机会

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

PostgreSQL 新闻

PostgreSQL 星球：https://planet.postgresql.org/

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

请在太平洋标准时间/太平洋夏令时间周日下午 3:00 前将新闻和公告提交至 david@fetter.org。

已应用的补丁

David Rowley 推送了

  • 如果 PathTarget 和 RestrictInfos 包含易失函数，则进行缓存。此处，我们的目标是通过缓存 PathTargets 和 RestrictInfos 是否包含任何易失函数（第一次调用 contain_volatile_functions() 时）来减少 contain_volatile_functions() 完成的重复工作。对于这些节点的任何未来调用都只使用缓存的值，而不是再次递归检查子节点。感谢 Tom Lane 的想法。代码中任何更改 PathTarget 或 RestrictInfo 的位置，如果可能会更改易失性检查的结果，都必须将缓存的值改回 VOLATILITY_UNKNOWN。contain_volatile_functions() 是唯一负责将缓存值设置为 VOLATILITY_VOLATILE 或 VOLATILITY_NOVOLATILE 的代码。一些现有代码确实受益于这种额外的缓存，但是，此更改的主要目的是用于即将到来的补丁，该补丁必须在连接搜索期间检查易失性。如果连接搜索包含多个关系，则在这种情况下重复的易失性检查可能会非常昂贵。作者：David Rowley 讨论：https://postgr.es/m/3795226.1614059027@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/f58b230ed0dba2a3d396794a2ec84541e321d92d

  • 调整每个工作进程并行顺序扫描数据结构的设计。允许在并行顺序扫描期间存储每个工作进程内存的数据结构的设计并不理想。56788d215 中的工作需要一个额外的数据结构，以允许工作进程记住在并行顺序扫描期间已分配给它们进行处理的页面范围。该提交将一个 void 指针字段添加到 TableScanDescData，以允许 heapam 存储每个工作进程的分配信息。但是，考虑到我们为此有 AM 特定的结构，例如 HeapScanDescData，将该字段放在那里几乎没有意义。在此，我们从 TableScanDescData 中删除 void 指针字段，并为此目的向 HeapScanDescData 添加一个专用字段。以前，我们还为所有扫描分配了此并行每个工作进程的数据内存，无论它是否是并行扫描。这对于非并行扫描来说只是一种浪费的分配，因此在此我们使分配取决于扫描是否是并行扫描。此外，添加了以前缺少的 pfree() 以释放 heap_endscan() 中每个工作进程的数据。报告人：Andres Freund 审阅人：Andres Freund 讨论：https://postgr.es/m/20210317023101.anvejcfotwka6gaa@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/af527705edc3fd0b335264d17e0521c05edc5cca

  • 允许 simplehash.h 的用户执行直接删除。以前，simplehash.h 仅公开一种使用哈希表键执行哈希表删除的方法。这意味着删除函数必须执行哈希查找才能找到要删除的条目。在此，我们添加了一个新函数，以便 simplehash.h 的用户可以使用条目指针直接执行哈希删除，从而节省哈希查找。即将到来的一个使用 simplehash.h 的补丁已经执行了哈希查找，因此已经有了条目指针。此更改将允许该补丁中的代码执行哈希删除，而无需 simplehash.h 中的代码执行额外的哈希查找。作者：David Rowley 审阅人：Andres Freund 讨论：https://postgr.es/m/CAApHDvqFLXXge153WmPsjke5VGOSt7Ez0yD0c7eBXLfmWxs3Kw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ff53d7b159b93ce9fc884897f9d96b97744781e2

  • 修复 unistr 函数中的编译器警告。某些编译器不知道 elog/ereport ERROR 不会返回。 https://git.postgresql.org/pg/commitdiff/efd9d92bb39c74c2aded64fc08e2d601ce20c39d

  • 允许 estimate_num_groups() 返回有关估计的更多详细信息。在此，我们向 estimate_num_groups() 添加了一个新的输出参数，以允许它向调用者通知有关估计的更多可能有用的信息。新的输出参数是一个结构，目前仅包含一个具有一组标志的字段。这样做而不是将标志作为输出参数，是为了允许在将来添加字段，而无需在以后我们想要传递可能不适合存储在标志字段中的更多信息时更改函数的签名。planner 有一天可能会想知道更多关于估计的信息，这似乎是合理的。例如，估计是从多少个单独的统计数据集生成的？如果我们在生成计划时想考虑风险和成本，planner 可能需要考虑这一点。目前，我们在标志字段中只设置 1 个标志。这是为了表明估计在任何部分的估计中都回退到使用硬编码常量。如果设置了此标志，调用者可能希望更改其行为，这使他们能够这样做。如果调用者对获取有关估计的任何其他信息不感兴趣，则可以将标志指针作为 NULL 传递。我们在此处不添加任何这些标志的实际用法。一些后续提交将利用此功能。此外，我们也没有进行任何更改以添加对 clauselist_selectivity() 和 clauselist_selectivity_ext() 的支持。但是，如果将来需要这样做，则此处添加的相同结构应该可以用作这些函数的新输出参数。作者：David Rowley 讨论：https://postgr.es/m/CAApHDvqQqpk=1W-G_ds7A9CsXX3BggWj_7okinzkLVhDubQzjA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ed934d4fa30f0f94e6f7125ad2154e6a58d1c7f7

  • 添加结果缓存执行器节点。这里我们添加了一种名为“结果缓存”的新执行器节点类型。规划器可以在计划中包含此节点类型，以便执行器缓存参数化嵌套循环连接的内侧结果。这样就可以为参数集缓存元组，以便在节点再次看到相同的参数值时，可以直接返回缓存的元组，而无需重新扫描连接的内侧。在内部，结果缓存使用哈希表来快速查找先前缓存的元组。对于某些数据集，这可以显著提高连接的性能。使用这种新节点类型的最佳情况是，连接问题中，来自连接内侧的大部分元组在连接外侧没有匹配的伙伴。在这种情况下，哈希连接必须哈希那些永远不会被查找的值，从而使哈希表膨胀，并可能导致其多批处理。合并连接必须跳过所有不匹配的行。如果我们使用带有结果缓存的嵌套循环连接，那么我们只缓存那些在连接外侧至少有一个连接伙伴的元组。当被查找的唯一值较少且每个值的查找次数很多时，使用带结果缓存的参数化嵌套循环的好处会增加。此外，查找缓存的哈希探测可能比哈希连接中的哈希探测快得多，因为结果缓存的哈希表通常比哈希连接的哈希表小得多，这是因为结果缓存只缓存有用的元组，而不是连接内侧的所有元组。当哈希连接的哈希表不再适合 CPU 的 L3 缓存，但结果缓存的哈希表可以时，这种哈希探测性能的差异更为显著。每次哈希探测对哈希桶的表面上的“随机”访问可能会导致大型哈希表的 L3 缓存命中率较低。较小的哈希表通常性能更好。用于缓存的哈希表会限制自身的大小，不会超过 work_mem * hash_mem_multiplier。我们为该缓存维护一个键的 dlist，当我们添加新元组并意识到我们已超出内存预算时，我们会从最近最少使用的条目开始驱逐缓存条目，直到我们有足够的内存将新元组添加到缓存中。对于参数化嵌套循环连接，我们现在考虑在嵌套循环节点和其内部节点之间使用这些结果缓存节点之一。我们根据成本来确定何时使用它可能有用，成本主要取决于预期的缓存命中率。估计缓存命中率依赖于嵌套循环参数的良好唯一性估计。目前，规划器只会考虑对参数化嵌套循环连接使用结果缓存。这适用于普通连接以及对子查询的 LATERAL 类型连接。将来可能会将此新节点用于其他用途。例如，缓存相关子查询的结果。但是，由于在外部计划上获得唯一性估计来计算估计的缓存命中率存在一些困难，因此这里没有这样做。目前，我们在规划外部计划之前规划内部计划，因此没有办法知道结果缓存是否会有用，因为我们无法估计子计划将被调用的次数，直到生成外部计划。此处添加的功能新引入了在连接搜索期间对 estimate_num_groups() 返回值的依赖。以前，在连接搜索期间，我们只需要执行选择性估计。通过此提交，我们需要使用 estimate_num_groups() 来估计结果缓存的命中率。简单来说，如果我们预期有 10 个唯一值并且我们预期有 1000 个外部行，那么我们将估计命中率为 99%。由于缓存命中与扫描嵌套循环连接内侧的基础节点相比非常便宜，因此这将显著降低规划器连接的成本。但是，很容易看出，当 estimate_num_groups() 错误地返回一个远低于实际唯一值数量的值时，情况会变得很糟糕。如果发生这种情况，那么可能会导致我们使用带结果缓存的嵌套循环连接，而不是其他类型的连接，例如合并或哈希连接。我们以前已知唯一性估计是麻烦的根源，因此此处对其的额外依赖可能会导致规划器选择比具有此功能之前更慢的计划。当已连接多个表或当 WHERE 子句筛选出一组与我们正在估计唯一值数量的表达式相关的唯一值时，唯一性估计也很难准确估计。目前，我们在查询规划期间对结果缓存执行的成本计算确实对唯一性估计的准确性抱有很大的信心。当这些准确时，我们通常会看到包含结果缓存的计划的执行时间更快。但是，在现实世界中，我们可能会发现我们需要更改成本计算以减少对唯一性估计准确性的信任，或者甚至默认禁用此功能。当我们教查询规划器执行新的技巧时，总会存在一定的风险，它可能会在错误的时间决定使用新的技巧，从而导致回归。用户可以选择使用 enable_resultcache GUC 关闭该功能来获得旧的行为。目前，默认情况下启用此功能。我们是否会在发布版本中保持该设置还有待观察。此外，“结果缓存”这个名称是我在开始编写补丁时所能想到的这个新节点的最佳名称。似乎没有人强烈不喜欢这个名称。有些人确实提出了其他名称，但在关于名称的简短讨论中，似乎没有其他名称占据主导地位。让我们让 Beta 测试期看看当前名称是否能让足够多的人满意。如果对更好的名称达成共识，那么我们可以在发布之前对其进行更改。请参阅下面的第二个讨论链接，以了解有关“结果缓存”名称的讨论。 作者：David Rowley 审阅人：Andy Fan, Justin Pryzby, Zhihong Yu 测试人：Konstantin Knizhnik 讨论：https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com 讨论：https://postgr.es/m/CAApHDvq=yQXr5kqhRviT2RhNKwToaWr9JAN5t+5_PzhuRJ3wvg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b6002a796dc0bfe721db5eaa54ba9d24fd9fd416

  • 还原 b6002a796。这将删除“添加结果缓存执行器节点”。似乎在缓存命中和未命中的跟踪方面出现了一些奇怪的问题，正如许多构建场动物所强调的那样。目前还不清楚问题是什么，因为计划的其他部分表明缓存工作正常，只是命中和未命中的报告为 0。现在正是构建场如此崩溃的糟糕时机，因此在更多动物变红之前进行还原。 讨论：https://postgr.es/m/CAApHDvq_hydhfovm4=izgWs+C5HqEeRScjMbOgbpC-jRAeK3Yw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/28b3e3905c982c42fb10ee800e6f881e9742c89d

  • 添加结果缓存执行器节点（第 2 次尝试）。这里我们添加了一个名为“结果缓存”的新执行器节点类型。规划器可以在计划中包含此节点类型，以便执行器缓存参数化嵌套循环连接内侧的结果。这允许缓存一组参数的元组，这样，如果节点再次看到相同的参数值，它可以直接返回缓存的元组，而无需重新扫描连接的内侧。在内部，结果缓存使用哈希表来快速查找以前缓存的元组。对于某些数据集，这可以显著提高连接的性能。使用这种新节点类型的最佳情况是连接问题，其中连接内侧的大部分元组在连接外侧没有连接伙伴。在这种情况下，哈希连接将不得不哈希永远不会被查找的值，从而膨胀哈希表，并可能导致其进行多批处理。归并连接将不得不跳过所有不匹配的行。如果我们使用带有结果缓存的嵌套循环连接，那么我们只会缓存在外侧至少有一个连接伙伴的元组。当要查找的唯一值较少且每个值的查找次数很大时，使用带有结果缓存的参数化嵌套循环的好处会增加。此外，用于查找缓存的哈希探测可能比哈希连接中的哈希探测快得多，因为结果缓存的哈希表通常比哈希连接的哈希表小得多，这是因为结果缓存仅缓存有用的元组，而不是连接内侧的所有元组。当哈希连接的哈希表不再适合 CPU 的 L3 缓存，而结果缓存的哈希表适合时，哈希探测性能的这种差异更为显著。每次哈希探测对哈希桶的明显“随机”访问可能会导致大型哈希表的 L3 缓存命中率较差。较小的哈希表通常性能更好。用于缓存的哈希表的大小限制为不超过 work_mem * hash_mem_multiplier。我们维护此缓存的键的 dlist，当我们添加新元组并意识到我们已超出内存预算时，我们从最近最少使用的缓存条目开始逐出，直到我们有足够的内存将新元组添加到缓存中。对于参数化嵌套循环连接，我们现在考虑在嵌套循环节点及其内部节点之间使用这些结果缓存节点之一。我们根据成本来确定何时使用它可能有用，这主要取决于预期的缓存命中率。估计缓存命中率依赖于嵌套循环参数的良好唯一估计。目前，规划器只会考虑对参数化嵌套循环连接使用结果缓存。这适用于普通连接，也适用于 LATERAL 类型的子查询连接。将来可以使用此新节点进行其他用途。例如，缓存相关子查询的结果。但是，由于在外部计划上获得唯一估计来计算估计的缓存命中率存在一些困难，因此这里不这样做。目前，我们在规划外部计划之前规划内部计划，因此没有很好的方法知道结果缓存是否会有用，因为在我们生成外部计划之前，我们无法估计子计划将被调用的次数。此处添加的功能是在连接搜索期间新引入了对 estimate_num_groups() 返回值的依赖。以前，在连接搜索期间，我们只需要执行选择性估计。有了此提交，我们需要使用 estimate_num_groups() 来估计结果缓存的命中率。简单来说，如果我们预期有 10 个唯一值，并且我们预期有 1000 个外部行，那么我们将估计命中率为 99%。由于与扫描嵌套循环连接内侧的底层节点相比，缓存命中非常便宜，因此这将显著降低规划器的连接成本。但是，很容易看出，当 estimate_num_groups() 不正确地返回明显低于实际唯一值数量的值时，情况会变得糟糕。如果发生这种情况，那么可能会导致我们使用带有结果缓存的嵌套循环连接，而不是其他连接类型，例如归并或哈希连接。我们已知唯一估计在过去是问题的根源，因此在这里额外依赖它们可能会导致规划器选择比具有此功能之前更慢的计划。当已经连接了多个表或 WHERE 子句过滤掉一组与我们正在估计唯一值数量的表达式相关的的值时，唯一估计也相当难以准确估计。目前，我们在查询规划期间对结果缓存执行的成本计算相当依赖于唯一估计的准确性。当这些准确时，我们通常应该看到包含结果缓存的计划的执行时间更快。但是，在现实世界中，我们可能会发现我们需要更改成本计算以减少对唯一估计准确性的信任，甚至可能默认禁用此功能。当我们教查询规划器执行新的技巧时，它可能会在错误的时间决定使用新的技巧并导致回归，这总是存在一定的风险。用户可以选择通过关闭 enable_resultcache GUC 来获得旧的行为。目前，默认情况下启用此选项。我们是否会为发布版本保留该设置还有待观察。此外，“结果缓存”这个名称是我在开始编写补丁时能想到的这个新节点的最佳名称。似乎没有人强烈不喜欢这个名字。有几个人提出了其他名称，但在关于名称的简短讨论中，似乎没有其他名称占主导地位。让我们允许测试版看看当前名称是否让足够的人满意。如果有关于更好名称的共识，那么我们可以在发布之前更改它。请参阅下面的第二个讨论链接，了解关于“结果缓存”名称的讨论。作者：David Rowley 审阅者：Andy Fan、Justin Pryzby、Zhihong Yu、Hou Zhijie 测试者：Konstantin Knizhnik 讨论：https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com 讨论：https://postgr.es/m/CAApHDvq=yQXr5kqhRviT2RhNKwToaWr9JAN5t+5_PzhuRJ3wvg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9eacee2e62d89cab7b004f97c206c4fba4f1d745

  • 尝试修复不稳定的结果缓存回归测试。force_parallel_mode = regress 导致的问题比我想象的要多一些。似乎领导者和单个工作者都可以参与执行。我错误地认为只有工作进程才会做任何工作。由于不确定这两个进程中的哪一个有机会处理该计划，因此禁用这些测试的 force_parallel_mode 似乎更好。至少这样做似乎比更改为仅 EXPLAIN 而不是 EXPLAIN ANALYZE 更好。此外，我忽略了一个事实，即结果缓存下的子计划的执行次数将根据缓存逐出情况执行不同的次数。32 位机器将使用较少的内存，并从缓存中逐出较少的元组。这会导致子节点在 32 位机器上执行的次数更少。让我们直接清空每个节点中的循环次数。https://git.postgresql.org/pg/commitdiff/a4fac4ffe8f8d543a10ac7debf1157e34963ece3

  • 删除结果缓存代码中无用的 Assert。测试一个无符号变量是否 >= 0 是毫无意义的。remove_cache_entry() 中可能有足够的代码来验证断言启用构建中的缓存内存记帐是否正确。这些 Assert 并没有添加太多额外的覆盖范围，即使它们一直在检查有符号变量是否 >= 0。报告者：Andres Freund 讨论：https://postgr.es/m/20210402204734.6mo3nfacnljlicgn@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/1267d9862fc6a4f8cdc0ca38d1988b61f39da585

Peter Geoghegan 推送

Peter Eisentraut 推送

Andrew Dunstan 推送了

Álvaro Herrera 推送了

Etsuro Fujita 推送了

Amit Kapila 推送了

Tom Lane 推送

  • 进一步调整 pg_dump 对 default_toast_compression 的处理。正如 bbe0a81db 中提交的那样，来自 pre-v14 服务器的 pg_dump 实际上就像您说了 --no-toast-compression。我认为正确的方式是让它表现得好像 default_toast_compression 设置为 "pglz" 一样，以便保留表的 toast 压缩行为。如果您想要其他行为，始终可以通过给出开关来实现。讨论：https://postgr.es/m/1112852.1616609702@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/54bb91c30e3964fd81059e6b02e377cc9dd2d64c

  • 移除 ExecARDeleteTriggers/ExecARUpdateTriggers 中的小效率低下。在研究 nodeModifyTable.c 时，我偶然注意到，当调用 ExecBRTriggers 和 ExecIRTriggers 时，有测试来检查是否有任何相关的触发器要触发，而对 ExecARTriggers 的调用则没有；后者函数自己进行等效测试。考虑到所涉及的更复杂的条件，这似乎是合理的，但不合理的是，当没有工作要做时，ExecAR函数不小心不做任何工作。ExecARInsertTriggers 做对了这一点，但另外两个都会强制创建一个查询可能不需要的槽。ExecARUpdateTriggers 还对该槽执行了一个通常无用的 ExecClearTuple()。在实际工作负载中，这可能都是微不足道的，但节省的周期就是获得的周期。https://git.postgresql.org/pg/commitdiff/65158f497a7d7523ad438b2034d01a560fafe6bd

  • 重构 UPDATE 和 DELETE 的规划和执行。此补丁进行了两组密切相关的更改：1. 对于 UPDATE，ModifyTable 节点的子计划现在只传递已更改列的新值（即，在查询的 SET 子句中计算的表达式）加上行标识信息（如 CTID）。ModifyTable 必须重新获取原始元组，以合并任何未更改列的旧值。这样做的核心优势在于，已更改的列在继承或分区目标关系的所有表中都是统一的，而其他列可能不是。当 UPDATE 涉及联接时，次要优势是需要通过计划树传递的数据更少。当然，缺点是每个要更新的元组都要额外获取一次。但是，这在上下文中几乎是免费的；即使是最坏情况的测试也不会显示它会使总查询成本增加超过几个百分点。在某个时候，将重新获取与 ModifyTable 必须执行的元组访问结合起来以标记旧元组死亡可能很有趣；但这需要大量的重构，而且似乎不会带来太多好处，因此此补丁不尝试这样做。2. 对于继承的 UPDATE/DELETE，我们现在不是为每个目标关系生成一个单独的子计划，而是生成一个与 SELECT 的计划完全相同的单个子计划，然后将 ModifyTable 放在其之上。为了让 ModifyTable 知道给定的传入行指的是哪个目标关系，将一个 tableoid 垃圾列添加到行标识信息中。这摆脱了 inheritance_planner() 中可怕的 hack，消除了在存在许多无法修剪的目标关系的情况下的 O(N^2) 规划成本和内存消耗。当然，第 2 点需要第 1 点，以便为子计划返回的非垃圾列提供统一的定义。但是，如果我们希望保留在分区层次结构中同时拥有普通表和外部表的能力，则不能坚持对行标识垃圾列进行统一的定义。由于让每个子表都有自己的行标识列不会扩展太多，因此此补丁包括将相似的行标识列合并到子计划结果的一个列中的规定。特别是，我们可以将通常由 FDW 用作行标识的整个行变量通过假装它们是 RECORD 类型来合并到一个列中。（但是，用表的行类型 OID 标记实际的复合 Datum 仍然可以。）为了减少此补丁中残留的效率低下，还有更多可以做的事情，但现在看来可以提交了。FDW 作者应注意几个 API 更改：* AddForeignUpdateTargets() 的参数列表已更改，它必须用于向查询添加垃圾列的方法也已更改。调用 add_row_identity_var() 而不是直接操作解析树。您可能还需要重新考虑您要添加的内容。* PlanDirectModify() 现在必须更加努力地查找 ForeignScan 计划节点；如果外部表是分区层次结构的一部分，则 ForeignScan 可能不是 ModifyTable 的直接子项。有关示例代码，请参见 postgres_fdw。* 要检查关系是否为目标关系，仅将其 relid 与 root->parse->resultRelation 进行比较是不够的。相反，请根据需要检查 all_result_relids 或 leaf_result_relids。Amit Langote 和 Tom Lane 讨论：https://postgr.es/m/CA+HiwqHpHdqdDn48yCEhynnniahH78rwcrv1rEX65-fsZGBOLQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/86dc90056dfdbd9d1b891718d2e5614e3e432f35

  • 改进一些与复制相关的错误消息的样式。将远程端的错误消息放入主错误字符串中，而不是将其降级到 errdetail()。尽管如果远程端向我们发送一个很长的错误消息，这最终可能会很尴尬，但这似乎更符合我们的消息样式指南，并且在 errdetail 可能被删除的情况下更有帮助。Peter Smith 讨论：https://postgr.es/m/CAHut+Ps-Qv2yQceCwobQDP0aJOkfDzRFrOaR6+2Op2K=WHGeWg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/6197db5340b8154adce1c6d07f6d3325547429c1

  • 抑制 libpq_pipeline.c 中的编译器警告。一些编译器似乎担心 recv_step 不是任何定义的枚举值。以不同于我在 9fb9691a8 中所做的方式来消除有关未初始化 cmdtag 的警告。https://git.postgresql.org/pg/commitdiff/522d1a89f8d7ed45681988c60bd0a687332a4023

  • 不要过早地将值塞入短整型。自从 a4d75c86b 以来，一些构建场的成员一直在警告说，如果 attnum 是 AttrNumber，则 Assert(attnum <= MaxAttrNumber); 是无用的。我不确定从位图出来的数值是否真的有可能超过 MaxAttrNumber，但我们似乎在 7300a6995 中认为这是可能的。将中间变量恢复为 int，以便我们具有与之前相同的溢出保护。https://git.postgresql.org/pg/commitdiff/c545e9524dcfcfce25c370f584b31562e8d7a4b7

  • 在非断言构建中消除编译器警告。根据构建场。https://git.postgresql.org/pg/commitdiff/8998e3cafa23632790787b8cc726998e84067259

  • 修复 pqTraceFormatTimestamp 中的可移植性和安全性问题。消除 time_t 和 pg_time_t 之间的混淆；无论是 gettimeofday() 还是 localtime() 都不使用后者。libpq 确实根本不应该使用 <pgtime.h>。使用 snprintf 而不是 sprintf，以确保我们不会溢出提供的缓冲区。（不太可能，但让我们安全一点。）根据构建场。https://git.postgresql.org/pg/commitdiff/f1be740a991406d7885047beb971e1ff5dbe8b71

  • 修复 isprint() 的不可移植用法。我们必须将 <ctype.h> 函数的参数强制转换为 unsigned char，以避免 char 为有符号类型时出现问题。说到这一点，考虑到这是一个 <ctype.h> 函数，我们没有看到更多关于未包含该标头的投诉真是太了不起了。根据构建场。https://git.postgresql.org/pg/commitdiff/9e20406dd847d0f8c1cbd803786c6d0ad33bcbdd

  • 修复 pg_restore 用于检测归档文件格式的错误设计的代码。尽管明确的注释指出 ReadHead() 和 _discoverArchiveFormat() 中的重复代码段需要同步，但它们没有：后者没有费心应用前者的任何健全性检查。我们之所以没有注意到这一点，部分原因是这些检查在我们通常测试的场景中都不会失败，部分原因是如果两个段都执行，则会掩盖疏忽，这在需要自动检测不可查找的 stdin 源的格式的情况之外会发生。但是，在满足所有这些要求的案例中 --- 例如，尝试从不可查找的 stdin 读取不受支持的较新归档格式 --- pg_restore 错过了应用版本检查，并且可能会转储核心或以其他方式出现异常行为。无论如何，整个事情都很愚蠢，因为除了对文件以 "PGDMP" 开头的一行验证之外，似乎没有理由重复该逻辑。似乎有一个未公开的假设，即多个主要格式（足以需要单独的读取器模块）仍将共享自定义格式标头的前几个字段。这似乎不太可能，因此让我们通过清除 _discoverArchiveFormat() 中的重复逻辑来修复它。还要删除成功自动检测后尝试寻求回到文件开头的毫无意义的尝试。这浪费了周期，这意味着我们有四种行为要验证，而不是两种。根据 Sergey Koposov 提供的错误 #16951。这已经坏了几十年了，因此反向移植到所有支持的版本。讨论：https://postgr.es/m/16951-a4dd68cf0de23048@postgresql.org https://git.postgresql.org/pg/commitdiff/ec03f2df17a8ba5b431b34dd924e020a0be729f6

  • 重新考虑 SP-GiST 中按值传递的叶子数据项的处理方式。SP-GiST 中现有的约定是，任何按值传递的数据类型都以 Datum 形式存储，即其宽度为 sizeof(Datum)，即使 typlen 小于此值。对于内部（上层）元组中的前缀数据项和节点标签数据项，这样做是可以的，或者至少现在更改它为时已晚。但对于叶子数据项来说，这是有问题的，因为我们更希望将它们以 Postgres 的标准磁盘表示形式存储，这样我们就可以轻松地扩展叶子元组以携带额外的“包含”列。但我认为，我们可以直接更改它。这将会是一个不可接受的磁盘格式破坏，但有两个重要的缓解因素：1. 似乎不太可能有任何 SP-GiST 操作类使用按值传递的叶子数据类型。当然，核心中的任何操作类都没有，codesearch.debian.net 也没有发现任何。考虑到 SP-GiST 的用途，很难想象叶子级别的值既小又固定宽度的情况。（例如，如果您想使用叶子级别为单个字节来索引文本值，则每个文本字符串都必须用每个前导字节一个内部元组级别来表示，这将是非常浪费空间且访问速度很慢的。您总是希望使用尽可能少的内部元组级别，尽可能多地保留在叶子值中。）2. 即使您有这样的索引，此更改也只会破坏大端机器上的数据。在小端机器上，Datum 格式的高位字节现在只会显示为对齐填充空间。因此，更改代码以按其通常的磁盘形式存储按值传递的叶子数据项。内部元组数据项不受影响。这是从一个更大的补丁中提取出来的，该补丁旨在添加对“包含”列的支持。我将其单独提交是为了在我们的提交日志中可见。Pavel Borisov 和 Tom Lane 审阅，Andrey Borodin 讨论：https://postgr.es/m/CALT9ZEFi-vMp4faht9f9Junb1nO3NOSjhpxTmbm1UGLMsLqiEQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1ebdec8c03294e55a9fdb6e676a9e8de680231cc

  • 同时剥离 Windows 上错误消息中报告的文件名。提交 dd136052b 建立了一项策略，即错误消息 FILE 项应仅包含报告源文件的基本名称，以实现统一和简洁。我们现在观察到一些 Windows 编译器在 FILE 字符串中使用反斜杠，因此也应该在反斜杠处截断。这预计会修复新的 libpq_pipeline 测试模块结果中的一些平台差异。讨论：https://postgr.es/m/3650140.1617372290@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/53aafdb9ff6a561c7dea0f428a7c168f2b7e0f16

  • 改进 psql 在编辑器退出而不保存时的行为。当编辑先前的查询缓冲区时，如果编辑器在不修改临时文件的情况下退出，则清除查询缓冲区，而不是重新加载（并可能重新执行）先前的查询缓冲区。这降低了意外重新执行您不打算执行的操作的可能性。类似地，在“\e file”中，如果文件实际上没有被修改，则不要将其加载到查询缓冲区中。在“\ef”和“\ev”中，如果没有进行任何更改，则清除查询缓冲区，而不是将其加载到函数或视图定义中。我们完全无法调用编辑器或它返回非零状态的情况，都被视为没有文件修改的情况。Laurenz Albe，由 Jacob Champion 审阅 讨论：https://postgr.es/m/0ba3f2a658bac6546d9934ab6ba63a805d46a49b.camel@cybertec.at https://git.postgresql.org/pg/commitdiff/55873a00e3c3349664e7215077dca74ccea08b4d

  • 修复 SP-GiST 中属性类型和叶子存储类型之间的混淆。根据文档，传递给操作类配置函数的 attType（以及核心代码所依赖的）是正在索引的堆列或表达式的类型。但实际上被传递的是为索引列存储的类型。这对于用户定义的 SP-GiST 操作类没有影响，因为我们不允许使用 CREATE OPCLASS 的 STORAGE 子句，因此这两种类型将相同。但是不允许这样做是愚蠢的，因为内置的 poly_ops 操作类的 opckeytype 和 opcintype 具有不同的值，并且如果您想进行有损存储，则类型必须确实不同。（因此，进行有损存储的用户定义操作类必须谎报索引中的类型。）因此，删除限制，并确保我们在相关位置使用输入列类型而不是 opckeytype。出于与现有用户定义操作类向后兼容的原因，我们不能完全坚持指定的 leafType 与 STORAGE 子句匹配；相反，如果它们不匹配，则仅添加 amvalidate() 警告。同时修复了一些仅在 attType 与 attLeafType 不同时尝试返回索引条目时才会出现的错误。这些错误没有被报告并不奇怪，因为这种差异的唯一常见原因是进行有损存储叶子值，从而使仅索引扫描变得不可能。添加一个 src/test/modules 模块来练习 attType 与 attLeafType 不同但支持仅索引扫描的情况。讨论：https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ac9099fc1dd460bffaafec19272159dd7bc86f5b

Stephen Frost 推送

Bruce Momjian 推送

Michaël Paquier 推送

  • 在 pg_dump 中添加对 --extension 的支持。指定后，仅将与给定模式匹配的扩展名包含在转储中。与 --table 和 --schema 类似，当使用 --strict-names 时，需要完全匹配。此外，与另外两个选项一样，此新选项不保证已转储依赖对象，因此在干净的数据库上还原可能会失败。在 test_pg_dump/ 中添加了测试，在生成转储时，在包含或不包含扩展内容的情况下，检查了一组肯定和否定情况。作者：Guillaume Lelarge 由 David Fetter、Tom Lane、Michael Paquier、Asif Rehman、Julien Rouhaud 审阅 讨论：https://postgr.es/m/CAECtzeXOt4cnMU5+XMZzxBPJ_wu76pNy6HZKPRBL-j7yj1E4+g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/6568cef26e0f40c25ae54b8e20aad8d1410a854b

  • 修复 parsenodes.h 中的注释。CreateStmt->inhRelations 是 RangeVars 列表，但注释对此不正确。作者：Julien Rouhaud 讨论：https://postgr.es/m/20210330123015.yzekhz5sweqbgxdr@nol https://git.postgresql.org/pg/commitdiff/7ef64e7e72a65f191fc2f7d4bbe220f53dd8d5de

  • 将一些客户端特定的例程从 SSLServer 移动到 PostgresNode。test_connect_ok() 和 test_connect_fails() 一直是 SSL 测试的一部分，它们检查与后端的连接是否应该工作，并且如果连接失败，会对 libpq 丢弃的特定错误模式进行健全性检查。这从根本上来说是错误的，有两个方面。首先，SSLServer.pm 主要用于设置和更改 PostgresNode 的 SSL 配置，与客户端无关。其次，鉴于 b34ca595，情况变得更糟，其中 SSL 测试将使用 psql 命令完成，该命令可能与设置的节点来自不同的安装。此提交将这些客户端例程移动到 PostgresNode 中，使 SSLServer 的重构更容易，从而使其更具 SSL 实现感知能力。这也可以被 ldap、kerberos 和身份验证测试套件重用于连接检查，后续补丁应扩展这些接口以与后端日志模式匹配。作者：Michael Paquier 由 Andrew Dunstan、Daniel Gustafsson、Álvaro Herrera 审阅 讨论：https://postgr.es/m/YGLKNBf9zyh6+WSt@paquier.xyz https://git.postgresql.org/pg/commitdiff/0d1a33438d3a88938264e12e94c22818307d2f4d

  • 文档：澄清在各个部分中使用 ACCESS EXCLUSIVE 锁的情况。文档的某些部分使用“排他锁”来描述在给定操作期间会获取 ACCESS EXCLUSIVE 锁。这可能会让读者感到困惑，因为 ACCESS SHARE 锁允许与 EXCLUSIVE 锁一起使用，但在文档的这些部分描述的情况并非如此。作者：Greg Rychlewski 讨论：https://postgr.es/m/CAKemG7VptD=7fNWckFMsMVZL_zzvgDO6v2yVmQ+ZiBfc_06kCQ@mail.gmail.com 向后移植：9.6 https://git.postgresql.org/pg/commitdiff/ffd3391ea94165fbb5adc9534894c62d41138505

  • 提高 reloptions.sql 中 vacuum_truncate 测试的稳定性。此测试一直在使用简单的 VACUUM 命令和 pg_relation_size() 函数来检查关系是否被物理截断，但忽略了这样一个事实，即某些并发活动（如检查点缓冲区写入）可能会导致跳过某些页面。启用 vacuum_truncate 的第二个测试可能会失败，因为它会看到一个非空的关系。第一个测试不会失败，但可能会以测试与目标不同的行为结束。两个测试都获得了 FREEZE 选项，以使 VACUUM 命令更具侵略性并防止页面跳过。这与 c2dc1a7 中修复的问题类似。作者：Arseny Sher 审核者：Masahiko Sawada 讨论：https://postgr.es/m/87tuotr2hh.fsf@ars-thinkpad 向后移植：12 https://git.postgresql.org/pg/commitdiff/fe246d1c111d43fd60a1b0afff25ed09b7ae11eb

  • 文档：澄清如何使用非独占备份生成备份文件。当前描述如何写入 backup_label 和 tablespace_map 文件的说明令人困惑。例如，在 Windows 上以文本模式打开文件并复制粘贴该文件的内容会导致恢复时失败，因为会生成额外的 CRLF 字符。文档没有明确说明这一点，并且根据讨论，这不被视为受支持的场景。此提交稍微扩展了文档，以提及可能需要在写入数据之前以二进制模式打开文件。报告者：Wang Shenhao 作者：David Steele 审核者：Andrew Dunstan, Magnus Hagander 讨论：https://postgr.es/m/8373f61426074f2cb6be92e02f838389@G08CNEXMBPEKD06.g08.fujitsu.local 向后移植：9.6 https://git.postgresql.org/pg/commitdiff/6fb66c268df2de1112cac3cf0a6cf0a8b96ceaf0

  • 重构 HMAC 实现。与 cryptohash 实现类似，此项将现有的 HMAC 代码重构为一组可以通过 PostgreSQL 构建的任何加密库（目前仅限 OpenSSL）插入的 API。如果没有此类库，则可以使用回退实现。这些新的 API 的设计与现有的 cryptohash 层类似，因此这里没有真正的新设计，围绕缓冲区边界检查和内存处理的逻辑也相同。HMAC 依赖于 cryptohash，因此 cryptohash{_openssl}.c 支持的所有 cryptohash 类型都可以与 HMAC 一起使用。此重构的主要优势在于 SCRAM，它包含了使用 SHA256 的自己的 HMAC 实现，即使 PostgreSQL 构建时支持加密库，也没有依赖于现有的加密库。此代码已在 Windows 和 Linux 上，使用和不使用 OpenSSL 的情况下，在 HEAD 上支持的所有版本（从 1.1.1 到 1.0.1）上进行了测试。我还通过一些示例结果、我自己的自定义扩展以及通过客户端和后端使用 SCRAM 在不同主要版本之间进行交叉检查，检查了实现是否正常工作。作者：Michael Paquier 审核者：Bruce Momjian 讨论：https://postgr.es/m/X9m0nkEJEzIPXjeZ@paquier.xyz https://git.postgresql.org/pg/commitdiff/e6bdfd9700ebfc7df811c97c2fc46d7e94e329a2

  • 在 SSL TAP 测试中使用更详细的错误匹配模式。src/test/ssl/ 的 TAP 测试一直在使用相当通用的匹配模式来检查某些失败情况，例如“SSL error”或只是“FATAL”。这些是在 081bfc1 中引入的。这些消息本身没有错误，但是在使用新的 SSL 库进行集成时，很难知道这些错误是否合法，并且现有场景可能会以不正确的方式失败。此提交通过添加 OpenSSL 生成的信息使所有这些消息更加详细。幸运的是，相同的错误消息用于 HEAD 上支持的所有版本（在运行从 1.0.1 到 1.1.1 的测试后检查过），因此更改很简单。报告者：Jacob Champion, Álvaro Herrera 讨论：https://postgr.es/m/YGU3AxQh0zBMMW8m@paquier.xyz https://git.postgresql.org/pg/commitdiff/8d3a4c3eae5367fba60ab77c159814defba784fe

Noah Misch 推送了代码

Joe Conway 推送了代码

  • 修复 has_column_privilege 函数的边界情况。根据注释，当将无效或已删除的列 oid 传递给 has_column_privilege() 时，意图始终是返回 NULL。但是，当调用者具有表级权限时，永远不会发现无效/缺失的列，因为会先检查表权限。通过引入扩展版本的 pg_attribute_acl(check|mask) 和 pg_class_acl(check|mask) 来修复此问题，它们采用一个新参数 is_missing。当 is_missing 为 NULL 时，将保留旧的行为。但是，当调用者传递 is_missing 时，不会为已删除或缺失的列/关系抛出 ERROR，并且 is_missing 将被翻转为 true。反过来，这允许 has_column_privilege 首先检查列权限，从而提供所需的语义。由于这是一个用户可见的行为更改，以前没有收到任何投诉，而且修复程序有点侵入性，因此不进行向后移植。作者：Joe Conway 审核者：Tom Lane 报告者：Ian Barwick 讨论：https://postgr.es/m/flat/9b5f4311-157b-4164-7fe7-077b4fe8ed84%40joeconway.com https://git.postgresql.org/pg/commitdiff/b12bd4869b5e64b742a69ca07915e2f77f85a9ae

  • 澄清 RESET ROLE 的文档。命令行选项或之前的“ALTER (ROLE|DATABASE) ... SET ROLE ...”命令可以更改会话的默认角色值。如果存在其中一个，则 RESET ROLE 会将当前用户标识符更改为默认角色，而不是会话用户标识符。修复文档以反映此现实。向后移植到所有受支持的版本。作者：Nathan Bossart 审核者：Laurenz Albe, David G. Johnston, Joe Conway 报告者：Nathan Bossart 讨论：https://postgr.es/m/flat/925134DB-8212-4F60-8AB1-B1231D750CB4%40amazon.com 向后移植：9.6 https://git.postgresql.org/pg/commitdiff/174edbe9f9c1538ab3347474e96d176223591cd1

Heikki Linnakangas 推送了代码

  • 向编码转换函数添加 'noError' 参数。使用 'noError' 参数，您可以尝试转换缓冲区，而无需事先知道字符边界。现在，这些函数需要返回成功转换的输入字节数。如果您使用 CREATE CONVERSION 创建了自定义编码转换，则这是一个向后不兼容的更改。这会向 pg_upgrade 添加对此的检查，如果存在任何用户定义的编码转换，则拒绝升级。自定义转换非常罕见，据我所知，没有常用的扩展程序使用该功能。没有其他对象可以依赖转换，因此，如果您确实有一个转换，您可以在升级前相当容易地删除它，然后在升级后使用更新的版本重新创建它。为内置编码转换添加回归测试。这并不涵盖所有转换，但它涵盖了 conv.c 中用于实现转换的所有内部函数。审核者：John Naylor 讨论：https://postgresql.ac.cn/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi https://git.postgresql.org/pg/commitdiff/ea1b99a6619cd9dcfd46b82ac0d926b0b80e0ae9

  • 在更大的块中执行 COPY FROM 编码转换/验证。这通过减少对转换/验证函数的调用次数并使其处理更大的输入，从而略微提高性能。此外，重新组织输入管道使得更容易并行化输入解析：在将输入转换为数据库编码后，查找换行符的下一阶段可以并行完成，因为在我们支持作为服务器编码的编码中，多字节字符中不能“嵌入”任何换行符。这在一个边界情况下更改了行为：如果客户端和服务器编码是相同的单字节编码（例如 latin1），则之前不会检查输入中是否存在零字节（'\0'）。任何包含零字节的字段都将在零处被截断。但是，如果需要编码转换，则转换例程会在零上抛出错误。在此提交之后，始终会检查输入中是否存在零。审核者：John Naylor 讨论：https://postgresql.ac.cn/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi https://git.postgresql.org/pg/commitdiff/f82de5c46bdf8cd65812a7b04c9509c218e1545d

Robert Haas 推送了代码

Fujii Masao 推送了代码

Thomas Munro 推送

Andres Freund 推送

  • 将等待事件相关代码从 pgstat.[ch] 拆分到 wait_event.[ch]。等待事件相关代码独立于 pgstat.[ch] 代码的其余部分，具有相当大的规模并定期更改。将其放入自己的一组文件中。由于似乎没有用于此类代码的合适预先存在的目录，因此添加 src/backend/utils/activity。审核者：Robert Haas robertmhaas@gmail.com 讨论：https://postgr.es/m/20210316195440.twxmlov24rr2nxrg@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/a333476b925134f6185037eaff3424c07a9f466f

  • 不要依赖 pgstat.h 来间接包含 storage/ 标头。即将到来的补丁可能会删除（现在是间接的）proc.h 包含（反过来包含其他标头），并且修改后的文件直接包含其依赖项更简洁... 讨论：https://postgr.es/m/20210402194458.2vu324hkk2djq6ce@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/1d9c5d0ce2dcac05850401cf266a9df10a68de49

  • 将后端状态和进度相关功能从 pgstat.c 中分离出来。后端状态（支持 pg_stat_activity）和命令进度（支持 pg_stat_progress*）相关代码在很大程度上独立于 pgstat.[ch] 的其余部分（支持诸如 pg_stat_all_tables 之类的视图，这些视图会随着时间的推移累积数据）。另请参见 a333476b925。此提交不会重命名函数名称以使其与 pgstat 的其余部分更清晰地区分 - 这会更具侵入性，并且没有明显的好处。如果我们决定在某个时候进行这样的重命名，最好与移动代码分开进行。Robert 的审查是针对早期版本的。审核者：Robert Haas robertmhaas@gmail.com 讨论：https://postgr.es/m/20210316195440.twxmlov24rr2nxrg@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/e1025044cd4e7f33f7304aed54d5778b8a82cd5d

  • 提高等待事件报告的效率，删除 proc.h 依赖项。到目前为止，pgstat_report_wait_start() 和 pgstat_report_wait_end() 需要两个条件分支。一个用于检查 MyProc 是否为 NULL，另一个用于检查是否设置了 pgstat_track_activities。由于等待事件在相对轻量级的操作周围使用，并且是内联的（降低了分支预测器的效率），因此这不是很好。对 MyProc 的依赖还有第二个缺点：诸如 storage/file/fd.c 之类的低级子系统报告等待事件，但从架构上来说，它们最好不要依赖于诸如 proc.h（定义 PGPROC）之类的进程间子系统。在此更改之后，包括 pgstat.h（或其子组件，如 backend_status.h、wait_event.h 等）不再引入与 IPC 相关的标头。这些目标，效率和抽象，是通过使 pgstat_report_wait_start/end() 不与 MyProc 交互，而是与新的 my_wait_event_info 变量交互来实现的。在后端启动时，它指向一个局部变量，从而无需检查 MyProc 是否为 NULL。在进程初始化期间，my_wait_event_info 被重定向到 MyProc->wait_event_info。在关闭时，此操作会反转。由于等待事件报告现在不需要知道等待事件的存储位置，因此它不再需要知道 PGPROC。删除检查 pgstat_track_activities 分支的方法更简单：不再检查。分支的成本通常高于存储 - 即使不是，pgstat_track_activities 也很少禁用。现在提交此工作的主要动机是，从 pgstat.h 中删除（间接的）pgproc.h 包含简化了将统计信息报告移动到共享内存的补丁（它仍有机会进入 14）。作者：Andres Freund andres@anarazel.de 讨论：https://postgr.es/m/20210402194458.2vu324hkk2djq6ce@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/225a22b19ed2960acc8e9c0b7ae53e0e5b0eac87

Tomáš Vondra 推送

待定补丁

James Hilliard 发送了另一个补丁修订版，以修复对 OSX 的 preadv/pwritev 支持的检测。

Mark Rofail 发送了另一个补丁修订版，以实现外键数组。

Tomáš Vondra 发送了一个补丁，使用新的子命令 ANALYZE (MERGE) 合并来自子关系的统计信息。

Zeng Wenjing 发送了另一个补丁修订版，以实现全局临时表。

Marcus Wanner 发送了另外四个补丁修订版，以向输出插件的 filter_prepare 回调添加 xid 参数。

Euler Taveira de Oliveira 发送了另一个补丁修订版，以添加由逻辑复制的 WHERE 子句指定的行过滤。

Peter Smith 发送了另一个补丁修订版，以向内置逻辑复制添加对预备事务的支持。

Arne Roland 发送了另外两个补丁修订版，以使 ALTER TRIGGER ... RENAME TO 在分区表上工作。

Tang 发送了一个补丁，以更新 nbtsearch.c 的版权年份。

Paul Guo 提交了补丁的另一个修订版本，以支持从包含表空间的备份初始化节点，修复备用服务器上创建数据库记录的重放，并修复数据库创建/删除 WAL 描述。

Masahiro Ikeda 提交了补丁的另外两个修订版本，以加快 WAL 统计信息的报告速度。

Daniil Zakhlystov 提交了补丁的另外两个修订版本，以添加 zlib 和 zstd 流式压缩，并实现 libpq 压缩。

Atsushi Torikoshi 和 Fujii Masao 交换了补丁，以获取任意后端进程的内存上下文。

John Naylor 提交了补丁的两个修订版本，用于记录最近添加的 date_bin() 函数。

Dean Rasheed 和 Fabien COELHO 交换了补丁，以向 pgbench 添加伪随机排列函数。

Isaac Moreland 提交了一个补丁，以添加 abs(interval) 函数和相关的 @ 运算符。

Kyotaro HORIGUCHI 提交了一个补丁，使 box 类型的描述更清晰。

Vigneshwaran C 提交了补丁的另一个修订版本，如果预备事务锁定了系统表/用户目录表，则使其失败。

Douglas Hirn 提交了补丁的另一个修订版本，允许在 WITH RECURSIVE 中使用多个线性递归自引用。

Sait Talha Nisanci 提交了一个补丁，旨在修复在 record_type_typmod_compare 中表现为崩溃的错误。

Tomáš Vondra 提交了一个补丁，使用扩展统计信息来改进连接估计。

Stephen Frost 提交了补丁的另一个修订版本，将默认角色重命名为预定义角色。

Vigneshwaran C 提交了补丁的三个修订版本，以处理复制槽统计信息被覆盖的问题，并将总事务数和总事务字节数添加到复制统计信息中。

Peter Geoghegan 提交了补丁的另外两个修订版本，以简化 VACUUM 管理的状态，重构 lazy_scan_heap()，从 vacuumlazy.c 中删除 tupgone 特例，在 VACUUM 期间截断行指针数组，并在某些情况下绕过索引清理。

Peter Geoghegan 和 Matthias van de Meent 交换了补丁，当页面具有尾部未使用的 ItemIds 时，截断页面的行指针数组，并覆盖 PageRepairFragmentation 中的空闲页面空间。

Tang 提交了补丁的另一个修订版本，以支持 psql 中对大写字符输入使用查询结果进行 tab 补全。

Fujii Masao 提交了补丁的另一个修订版本，以修复 walreciever 中的断言失败。

John Naylor 提交了补丁的另一个修订版本，用两个更快的实现替换 pg_utf8_verifystr()：一个用于使用 SSE-4.1 指令集的 Intel 类处理器，另一个使用定制的回退函数，而不是依赖于 pg_utf8_verifychar() 和 pg_utf8_isvalid() 的函数。

Peter Eisentraut 提交了补丁的另一个修订版本，以将 EXTRACT 的返回类型更改为 numeric。

Stephen Frost 提交了一个补丁，以添加 pg_read_all_data 和 pg_write_all_data 角色。

Thomas Munro 提交了一个补丁，以在 OpenBSD 上使用 POSIX_NAMED_SEMAPHORES。

Fujii Masao 和 Bharath Rupireddy 交换了补丁，以添加 postgres_fdw 服务器级别的选项 keep_connections，以不缓存连接。

Heikki Linnakangas 提交了一个补丁，通过强制前瞻来简化 COPY FROM 解析。

Daniel Gustafsson 提交了补丁的另外两个修订版本，以支持 NSS 作为 libpq TLS 后端。

Yuzuko Hosoya 和 Álvaro Herrera 交换了补丁，以修复分区表上的自动清理。

Bharath Rupireddy 提交了一个补丁，当分区表的持久性发生更改时发出警告。

Amit Langote 提交了补丁的另一个修订版本，以也在分区表中创建外键触发器，并使用相同的方法在跨分区更新期间正确强制执行外键。

Euler Taveira de Oliveira 提交了补丁的另一个修订版本，以重构 parse_output_parameters 函数，使用封装所有 pgoutput 选项的 struct PGOutputData，而不是使用多个参数，并使用相同的方法为 pgoutput 添加逻辑解码消息支持。

Peter Eisentraut 提交了补丁的另一个修订版本，以实现 SQL 标准函数体。

Justin Pryzby 提交了补丁的另一个修订版本，以实现分区表的 CLUSTER。

Amit Langote 提交了补丁的另外两个修订版本，以导出 get_partition_for_tuple()，并使用相同的方法避免对某些 RI 检查使用 SPI。

Julien Rouhaud 提交了补丁的另外三个修订版本，以将 pg_stat_statements 查询洗牌移动到核心，并使用相同的方法在 pg_stat_activity、log_line_prefix 和详细 explain 中公开 queryid。

Joel Jacobson 提交了一个补丁，以添加 MotD 函数。

Bharath Rupireddy 提交了补丁的另一个修订版本，以实现 ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION ...

Erik Rijkers 提交了补丁的另一个修订版本，以修复一个旧的令人困惑的 JSON 示例。

Kazutaka Onishi 提交了补丁的另外六个修订版本，以在外部表上实现 TRUNCATE。

Thomas Munro 提交了补丁的另一个修订版本，为 SLRUs 添加缓冲区映射表，并使所有 SLRU 缓冲区大小可配置。

Takamichi Osumi 提交了补丁的另外两个修订版本，以保护归档恢复不会丢失数据。这会禁用服务器在检测到使用 wal_level=minimal 生成的 WAL 时启动。无论 EnableHotStandby 的值如何，都应该这样做，因为我们认为在 wal_level=minimal 的期间不会发生这种情况。此补丁的动机是保护用户最终获得可能在备用模式下丢失数据的副本，并导致服务器在恢复模式下丢失数据。

Amit Langote 提交了补丁的另一个修订版本，以惰性地设置 ForeignScanState.resultRelInfo，并惰性地初始化结果关系信息。

Justin Pryzby 提交了一个补丁，使 track_activity_query_size 成为 STATS_COLLECTOR 类别，确保 log_autovacuum_min_duration 为 LOGGING_WHAT，使 track_commit_timestamp 为 REPLICATION_SENDING，并将 force_parallel_mode 更改为 DEVELOPER GUC，并将其从示例配置中删除。

Pavel Stěhule 提交了补丁的另一个修订版本，以实现模式变量。

Anton Voloshin 提交了一个补丁，以修复 collationcmds.c 中的一个错别字。

Zhihong Yu 提交了一个补丁，以从 AttrDefaultFetch 中删除一个未使用的变量。

Amit Langote 提交了补丁的另一个修订版本，允许在跨分区更新期间进行批量插入。

Anton Voloshin 提交了一个补丁，在 icu_convert_case() 中使用 repalloc() 而不是 palloc()，因为有问题的结构可能已经被 palloc() 了。

Tom Lane 提交了一个补丁，以修复一些 adbin 不一致性。