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

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

由 PWN 发布于 2021-11-29
PWN

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

本周人物

11月PostgreSQL工作

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

PostgreSQL 本地

2022年北欧 PGDay 将于 2022 年 3 月 22 日在芬兰赫尔辛基的希尔顿赫尔辛基海滩酒店举行。征集论文截止日期为 2021 年 12 月 31 日，此处

PostgreSQL 新闻

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

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

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

应用的补丁

Peter Geoghegan 推送

  • 移除 lazy_scan_heap 并行 VACUUM 注释块。这不应该出现在对 lazy_scan_heap 执行的任务的高级讨论旁边。在 vacuumlazy.c 的顶部已经有一个类似的、更长的注释块，直接提到了 lazy_scan_heap。https://git.postgresql.org/pg/commitdiff/97f5aef609ce51422934b7dbdba599a7de4dbafd

  • 回到考虑在标记为满的页面上使用 HOT。提交 2fd8685e7f 简化了在 heap_update() 中发生的修改属性的检查。这包括一个微优化，影响标记为 PD_PAGE_FULL 的页面：不要试图使用 HOT 来节省一些周期来确定 HOT 安全性。假设这次不会成功，因为它上次不可能成功。移除微优化。它只能节省被绝大多数 heap_update() 调用消耗的周期，这似乎不值得增加复杂性。而且，似乎很有可能存在某些工作负载，通过重复应用微优化，随着时间的推移会变得更糟，尽管在短期内平均节省了一些周期。作者：Peter Geoghegan pg@bowt.ie 审核人：Álvaro Herrera alvherre@alvh.no-ip.org 讨论：https://postgr.es/m/CAH2-WznU1L3+DMPr1F7o2eJBT7=3bAJoY6ZkWABAxNt+-afyTA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1a6f5a0e876306293fda697e7820b404d5b93693

  • 更新高级 vacuumlazy.c 注释。更新 vacuumlazy.c 文件头注释（以及 lazy_scan_heap 函数上面的注释），这些注释主要是在引入 HOT 优化之前编写的，当时 lazy_scan_heap 做的事情少得多，并且实际上并没有在其初始堆传递期间进行修剪。由于 lazy_scan_heap 现在将更多工作外包给较低级别的函数，因此通过讨论决定每个阶段发生顺序的高级不变性来介绍该函数是有意义的。此外，淡化我们用完 TID 内存的情况的讨论，因为推迟该讨论可以更容易地讨论中心重要的问题。最后，从头注释中删除并行 VACUUM 的讨论。这些并没有增加太多内容，而且位置不正确。https://git.postgresql.org/pg/commitdiff/12b5ade9023f3ecaddcbc423a22dc284c91c79f6

  • vacuumlazy.c：首选术语“清理锁”。术语“超独占锁”是“清理锁”的可接受的同义词。尽管如此，在同一个文件中从一个术语切换到另一个术语会令人困惑。在 vacuumlazy.c 中统一使用“清理锁”。根据 Andres Freund 的投诉。https://git.postgresql.org/pg/commitdiff/276db875d4f9be2911582f367596d444d6986c77

Fujii Masao 推送

Peter Eisentraut 推送

Álvaro Herrera 推送

Tom Lane 推送

  • 在检查 TAP 测试所需的模块时，使用 $PROVE 而不是 $PERL。通常，“prove”和“perl”来自同一个 Perl 安装，但我们支持它们不来自同一个安装的情况（主要是因为 MSys 构建农场的机器需要这样）。在这种情况下，AX_PROG_PERL_MODULES 完全不应该使用，因为它检查的是“perl”拥有的模块。相反，创建一个包含所需模块的 TAP 测试脚本，并在“prove”下运行它。更改之后，我们完全不需要 ax_prog_perl_modules.m4，因此将其删除。为了构建农场的利益，回溯修补到所有受支持的分支。(在 v10 中，这也回溯修补了 commit 264eb03aa 的影响。) Andrew Dunstan 和 Tom Lane，根据 Noah Misch 的观察得出。讨论：https://postgr.es/m/E1moZHS-0002Cu-Ei@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/c4fe3199a6d65212537a59eb0d7e6fad22b9e903

  • 修复 pg_dump --inserts 模式下包含已删除列的生成列的问题。如果表包含一个前面有已删除列的生成列，则 dumpTableData_insert 未能考虑已删除的列，并且会在错误的列中发出 DEFAULT 占位符。这会导致恢复时失败。默认的 COPY 代码路径没有这个错误，这可能解释了为什么没有更早地注意到它。在修复此问题的同时，我们可以对情况进行更智能的处理：(1) 避免不必要地获取生成列的值，(2) 如果我们使用 --column-inserts，也从输出中省略生成列。虽然预计这些模式的性能不如 COPY 路径，但我们不妨尽可能地高效；它并没有增加太多复杂性。根据 Дмитрий Иванов 的报告。回溯修补到 v12，因为生成列是在 v12 中引入的。讨论：https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0b126c6a4b00972f2f3533e1718bbe297e2851c2

  • 消除 perlcritic 的警告。根据构建农场的报告。https://git.postgresql.org/pg/commitdiff/db3a660c6327a6df81a55c4aa86e6c0837ecd505

  • 调整 pg_dump 对转换的优先级排序。当存储的表达式依赖于用户定义的转换时，后端会将依赖关系记录为对转换的实现函数的依赖关系 --- 或者实际上，如果没有涉及转换函数，而只是 RelabelType 或 CoerceViaIO，则根本不记录任何依赖关系。这对 pg_dump 来说是有问题的，它存在以错误的顺序转储内容从而导致恢复失败的风险。鉴于之前没有报告过此问题，风险并不高，但如果转换用于某个视图中，该视图的行类型随后用作其他函数的输入或结果类型，则可以演示此问题。（这会导致视图被提升到转储的 functions 部分，在转换之前。）对于此问题，一个逻辑上万无一失的修复方法是在表达式的解析形式中包含转换的 OID，然后可以通过 dependency.c 提取该 OID，并且存储的依赖关系将强制 pg_dump 执行正确的操作。这种更改具有相当的侵入性，而且肯定不能回溯修补。此外，由于我们希望使用转换语法的表达式与通过显式函数调用执行相同操作的表达式相等()，因此转换 OID 字段必须具有特殊的可忽略比较语义，这使得事情变得混乱。因此，我们改为通过 pg_dump 中的一个非常简单的技巧来修复此问题：更改对象类型的优先级顺序，以便转换最初在函数之前（紧跟在类型之后）排序。对于没有实现函数的转换，这以相当直接的方式修复了问题。对于有实现函数的转换，实现函数将通过依赖关系排序步骤提升到转换之前，以便我们仍然具有有效的转储顺序。（我不确定这是否完全保证没有问题；但由于这种情况已经存在很多年，并且之前没有任何报告，因此这可能足以在实践中修复它。）根据 Дмитрий Иванов 的报告。回溯修补到所有受支持的分支。讨论：https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b55f2b6926556115155930c4b2d006c173f45e65

  • 文档：改进有关 nextval()/setval() 的文档。澄清 nextval 和 setval 的结果在调用事务提交之前不能保证持久化。有些人似乎从这些函数永远不会回滚的声明中得出了相反的结论，因此重新措辞以避免以那种方式表达。讨论：https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4ac452e2285da347c75f5960ae211e183a87b57b

Michaël Paquier 推送

  • 添加 SQL 函数来监视复制槽的目录内容。此提交添加了一组函数，能够查看与复制槽相关的各种路径的内容： - pg_ls_logicalsnapdir，用于 pg_logical/snapshots/ - pg_ls_logicalmapdir，用于 pg_logical/mappings/ - pg_ls_replslotdir，用于 pg_replslot/<slot_name>/ 这些函数旨在由监控工具使用。与 pg_ls_dir() 不同，可以将执行权限授予非超级用户。pg_monitor 角色的成员可以访问这些函数。增加目录版本。作者：Bharath Rupireddy。审核者：Nathan Bossart, Justin Pryzby。讨论：https://postgr.es/m/CALj2ACWsfizZjMN6bzzdxOk1ADQQeSw8HhEjhmVXn_Pu+7VzLw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1922d7c6e1a74178bd2f1d5aa5a6ab921b3fcd34

  • 在构建脚本中添加对 Visual Studio 2022 的支持。更新了文档和与 VS 相关的任何代码路径，以保持整体一致性。与 2017 和 2019 类似，我们用于确定要用于构建的代码路径的 VS 版本和 nmake 版本仍然以其自己的方式不一致。向下回溯修补到 10，以便构建农场的成员能够在所有受支持的稳定分支上使用此新版本的 Visual Studio。作者：Hans Buschmann。讨论：https://postgr.es/m/1633101364685.39218@nidsa.net 回溯修补至：10 https://git.postgresql.org/pg/commitdiff/b2265d305d81b0c1a2cec6c5b66a190a9e69e853

  • 删除写入文件头时失败时无用的 LZ4 系统调用。如果在写入 LZ4 文件头时发生错误，则会在 write() 的错误代码路径中调用 LZ4F_compressEnd()，然后调用 LZ4F_freeCompressionContext() 以完成清理。原代码没有问题，但事实证明 LZ4F_compressEnd() 不是必要的，因为在此阶段没有要刷新内容，因此将其删除。根据 Jeevan Ladhe 和 Robert Haas 的抱怨。讨论：https://postgr.es/m/CAOgcT0PE33wbD7giAT1OSkNJt=p-vu8huq++qh=ny9O=SCP5aA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f79962d8264b8d205ce45a8aa11d1b37f9592a81

  • 修复 Windows 上使用标准流时的 fstat() 模拟。win32stat.c 中对 fstat() 的模拟导致了现有核心调用者的两个问题，当使用流作为参数时会失败并出现 EINVAL 错误： - psql 的 \copy 在使用流时会崩溃。 - pg_recvlogical 将会以 -f - 失败。来自主测试套件的 copyselect.sql 中的测试涵盖了第一种情况，并且对于第二种情况有一个 TAP 测试。但是，在这两种情况下，由于标准流总是被重定向，因此自动化测试没有注意到这些问题，需要 Windows 上的终端才能重现。此问题是在 bed9075 中引入的，问题的根源在于 GetFileInformationByHandle() 不能直接在流上工作，因此此提交添加了一个额外的代码路径来模拟并返回一组与实际情况最匹配的统计信息。请注意，重定向的流依赖于可以使用 GetFileInformationByHandle() 查询的句柄，但我们可以依靠 GetFinalPathNameByHandleA() 来检测这种情况。作者：Dmitry Koval, Juan José Santamaría Flecha。讨论：https://postgr.es/m/17288-6b58a91025a8a8a3@postgresql.org 回溯修补至：14 https://git.postgresql.org/pg/commitdiff/10260c794b211117a56ee2eb2deacf609bcca25f

  • 阻止在副本身份索引中的列上使用 ALTER TABLE .. DROP NOT NULL。直接依赖索引的副本身份依赖于一组属性，其中一个属性是此索引中定义的所有列都必须标记为 NOT NULL。在 ALTER TABLE DROP NOT NULL 的逻辑中存在一个漏洞，有可能删除用作副本身份的索引的一部分的列的 NOT NULL 属性，因此阻止它以避免将来出现逻辑解码的问题。对于主键中的列已经进行了相同的检查，因此修复非常简单。作者：Haiying Tang, Hou Zhijie。审核者：Dilip Kumar, Michael Paquier。讨论：https://postgr.es/m/OS0PR01MB6113338C102BEE8B2FFC5BD9FB619@OS0PR01MB6113.jpnprd01.prod.outlook.com 回溯修补至：10 https://git.postgresql.org/pg/commitdiff/f0d43947a1b0c30f0bf2c117cd78bf95a3161268

David Rowley 推送

  • 允许 Memoize 在二进制比较模式下运行。Memoize 始终使用缓存键类型的哈希相等运算符来确定当前参数集是否与之前缓存的某个参数集相同。某些类型（例如浮点数，其中 -0.0 和 +0.0 在其二进制表示形式中不同，但被哈希相等运算符归类为相等）可能会导致问题，除非联接使用相同的运算符，否则正在使用的任何联接运算符都可能能够区分这两个值。在这种情况下，我们可能会意外地从缓存中返回不正确的行。为了解决这个问题，我们在这里向 Memoize 添加一个二进制模式，允许它通过逐位比较而不是逻辑上使用哈希相等运算符，将当前参数集与先前缓存的值进行比较。此二进制模式始终用于 LATERAL 联接，当任何联接运算符不可哈希时，它也用于正常联接。报告者：Tom Lane。作者：David Rowley。讨论：https://postgr.es/m/3004308.1632952496@sss.pgh.pa.us 回溯修补至：14，这是添加 Memoize 的版本 https://git.postgresql.org/pg/commitdiff/e502150f7d0be41e3c8784be007fa871a32d8a7f

  • 当非键参数更改时刷新 Memoize 缓存。Memoize 节点下面的子计划可能包含来自 Memoize 节点之上的参数。如果此参数发生更改，则缓存条目可能会因新的参数值而过时。以前，Memoize 错误地没有意识到这一点。我们在这里通过在任何不属于缓存键的参数发生更改时刷新缓存来解决此问题。错误：#17213。报告者：Elvis Pranskevichus。作者：David Rowley。讨论：https://postgr.es/m/17213-988ed34b225a2862@postgresql.org 回溯修补至：14，这是添加 Memoize 的版本 https://git.postgresql.org/pg/commitdiff/1050048a315790a505465bfcceb26eaf8dbc7e2e

  • 回滚“当非键参数更改时刷新 Memoize 缓存”。此操作回滚提交 1050048a315790a505465bfcceb26eaf8dbc7e2e。 https://git.postgresql.org/pg/commitdiff/dad20ad4709f602b4827a1ab2b0e715f36c548c3

  • 当非键参数更改时刷新 Memoize 缓存，第 2 次尝试。Memoize 节点下方的子计划可能包含来自 Memoize 节点上方的参数。如果此参数更改，则缓存条目可能会因新的参数值而过期。以前，Memoize 错误地没有意识到这一点。我们在此处通过在不是缓存键一部分的参数更改时刷新缓存来修复此问题。错误：#17213 由：Elvis Pranskevichus 报告 作者：David Rowley 讨论：https://postgr.es/m/17213-988ed34b225a2862@postgresql.org 向后移植到：14，Memoize 在此版本中添加 https://git.postgresql.org/pg/commitdiff/411137a429210e432f923264a8e313a9872910ca

Amit Kapila 推送了更改

Robert Haas 推送了更改

  • 修复未检测到不正确的时序线切换的极端情况。rescanLatestTimeLine() 包含一个保护机制，防止切换到在当前恢复点之前从当前时序线分叉的时序线，但是如果时序线切换发生在读取第一个 WAL 记录（必须是检查点记录）之前，则该保护机制不起作用。如果没有此补丁，在这种情况下可能会发生不正确的时序线切换。发生这种情况是因为 rescanLatestTimeLine() 依赖于全局变量 EndRecPtr 来了解 WAL 重放的当前位置。但是，此时代码中的 EndRecPtr 包含上次重放记录的终点，而不是现在正在重放的记录的起点或终点。因此，在重放任何记录之前，它是零，这会导致健全性检查始终通过。要修复此问题，请显式传递正确的时序线。我们想要的 EndRecPtr 值来自 xlogreader，它将是我们即将尝试读取的记录的起始位置，而不是全局变量，它是我们上次成功读取的记录的结束位置。它们通常是相同的，但在本文描述的极端情况下并非如此。没有向后移植，因为在 v14 和更早的版本中，我们也在这里使用了错误的 TLI 和错误的 LSN。在主分支中，这在提交 4a92a1c3d1c361ffb031ed05bf65b801241d7cdd 中已修复，但该补丁及其先决补丁过于侵入性，无法针对如此次要的问题进行向后移植。由我提供补丁，由 Amul Sul 审核。讨论：http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e7ea2fa342b008ae97e794b0fa2ee538ddcee3b7

  • xlog.c：删除全局变量 ReadRecPtr 和 EndRecPtr。在大多数情况下，这些变量必须存储与我们在 WAL 重放期间使用的 XLogReaderState 的同名成员相同的值，因为 ReadRecord() 在 XLogReadRecord() 返回后立即将结构成员的值分配给全局变量。但是，XLogBeginRead() 会调整结构成员，但不会调整全局变量，因此在 XLogBeginRead() 之后和 XLogReadRecord() 完成之前，这些值可能会有所不同。否则，它们必须相同。根据我的分析，唯一在可能与结构成员的值不相同的地方引用其中一个变量是 XLogPageRead 中对 EndRecPtr 的引用。因此，在其他所有使用全局变量的地方，我们只需切换为使用结构成员，并删除全局变量。但是，我们也可以，实际上应该在 XLogPageRead() 中执行此操作，因为此时代码中的全局变量实际上将存储我们要读取的记录的开头 - 或者是上一个 WAL 记录结束的位置，或者是自上次读取记录以来使用 XLogBeginRead 更改了读取位置。另一方面，结构成员已经更新为指向我们刚刚读取的记录的末尾。在其他地方，后者是我们用作 emode_for_corrupt_record() 参数的值，因此我们应该在这里执行相同的操作。此补丁的这一部分可能是一个错误修复，但我认为它没有任何重要的后果，因此不进行向后移植。这里的重点只是继续减少在 xlog.c 中过度使用全局变量的问题。讨论：http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d2ddfa681db27a138acb63c8defa8cc6fa588922

Heikki Linnakangas 推送了更改

Andres Freund 推送了更改

Daniel Gustafsson 推送了更改