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

PostgreSQL 每周新闻 - 2021 年 8 月 29 日

由 PWN 发布于 2021-08-30
PWN

PostgreSQL 每周新闻 - 2021 年 8 月 29 日

PostgreSQL 产品新闻

pg_dbms_job 1.0.1，一个用于创建、管理和使用 Oracle 风格的 DBMS_JOB 计划作业的扩展，已发布。

dbMigration .NET v14.4，一个数据库迁移和同步工具，已发布。

WAL-G 1.1，一个用 Go 编写的 PostgreSQL 和其他数据库的备份管理系统，已发布。

pglogical 2.4.0，一个基于逻辑 WAL 的 PostgreSQL 复制系统，已发布。

Crunchy PostgreSQL Operator 5.0.0，一个用于在 Kubernetes 上部署和管理开源 PostgreSQL 集群的系统，已发布。

set_user 2.0.1，一个允许使用增强的日志记录和控制进行特权提升的扩展，已发布

AGE 0.5.0，一个提供图数据库功能的 PostgreSQL 扩展，已发布

pg_msvc_generator 1.0.0 beta，一个用于制作扩展的 Windows 版本的工具，已发布。

8 月份的 PostgreSQL 工作

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

PostgreSQL 新闻

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

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

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

应用的补丁

Michaël Paquier 推送了

Bruce Momjian 推送了

Álvaro Herrera 推送了

Tom Lane 推送了

  • 防止正则表达式反向引用有时在不应该匹配时匹配。cdissect() 中的递归在拒绝部分匹配后，对清除捕获括号的匹配数据不小心。这可能允许稍后的反向引用在按理应因缺乏定义的引用而失败时成功。要修复此问题，请更严格地考虑 cdissect 的不同递归级别之间的协定应该是什么。有了正确的规范，我们可以通过减少而不是更多次重置匹配数据来解决此问题；关键的决定是，失败的子匹配现在明确负责清除它可能设置的任何匹配。代码中存在足够多的其他交叉检查和优化，因此不容易展示此问题；通常，匹配将按预期失败。此外，即使是潜在易受攻击的正则表达式也最可能是用户错误，因为编写一个并非总是有引用的反向引用毫无意义。这些事实或许可以解释为什么没有检测到该问题，尽管它几乎可以肯定有几十年历史了。讨论：https://postgr.es/m/151435.1629733387@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9bbf6f7341f2b5a8ce41d838154380faa7346101

  • 修复正则表达式在 "{0}" 内使用捕获括号时的错误行为。像 "(.){0}...\1" 这样的正则表达式会引发“无效的后向引用编号”错误。从表面上看，这并非不合理，因为如果捕获组迭代零次，它将永远不会被匹配。然而，像 Perl 这样的其他引擎并不会对此报错，并且对于相关情况（例如 "(.)|\1"）我们也不会抛出错误，即使该后向引用也永远无法成功匹配。此外，如果零次迭代的情况发生在运行时而不是编译时 --- 例如，当没有找到 "x" 时的 "(x)*...\1" --- 这也不是一个错误，我们只是认为后向引用不匹配。更令人难以辩解的是，对于嵌套的情况（例如 "((.)){0}...\2"）没有抛出错误；更糟糕的是，这些情况可能会导致断言失败。（似乎在非断言构建中没有发生特别糟糕的情况。）让我们修复它，使其不抛出错误，而是认为后向引用永远不匹配，从而使编译时检测到的零次迭代行为与运行时检测到的行为相同。根据 Mark Dilger 的报告。这似乎是 Spencer 库中一个原始错误，因此需要向所有支持的版本进行回溯修复。对于 v14 之前的版本，事实证明还需要回溯修复提交 cb76fbd7e/00116dee5 的一个方面，即使用其子表达式的开始/结束状态创建捕获节点子正则表达式，而不是外部 parseqatom 调用的当前 lp/rp。否则 delsub 会抱怨我们试图将一个状态从自身断开。这有点可怕，但是代码检查表明它是安全的：在 v14 之前的代码中，如果我们想在子表达式周围包装迭代，我们做的第一件事是用新状态覆盖原子结构的开始/结束字段。因此，这些伪造的值没有存活足够长的时间来用于任何用途，除非不需要迭代，在这种情况下，它无关紧要。讨论：https://postgr.es/m/A099E4A8-4377-4C64-A98C-3DEDDC075502@enterprisedb.com https://git.postgresql.org/pg/commitdiff/65dc30ced64cd17f3800ff1b73ab1d358e92efd8

  • 移除冗余的测试。条件 “context_start < context_end” 严格弱于 “context_end - context_start >= 50”，因此我们不需要同时使用这两个条件。这是提交 ffd3944ab 中的疏忽，由 tanghy.fnst 指出。顺便说一下，对附近的测试进行换行以使其更具可读性。讨论：https://postgr.es/m/OS0PR01MB61137C4054774F44E3A9DC89FBC69@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/373e08a9f771e724efd3bd29f78c39515792dcf3

  • 更诚实地处理正则表达式的 makesearch 和 MATCHALL 之间的交互。对提交 824bf7190 的重新思考：在确定它是否为 MATCHALL 模式后，我们将 makesearch() 应用于 NFA。前置 ".*" 不会使其成为非 MATCHALL 模式，但它会更改最大可能的匹配长度，而 makesearch() 未能更新该长度。考虑到搜索 NFA 的程式化用法，这不会产生不良影响，但保持数据结构的一致性似乎更好。特别是，修复此问题可以更诚实地处理 matchuntil() 中的 MATCHALL 检查：我们现在可以断言 maxmatchall 是无穷大，而不是草率地假设它应该以这种方式工作。顺便说一下，改进 dump[c]nfa 中的代码，以便将无限的 maxmatchall 打印为 "inf" 而不是幻数。https://git.postgresql.org/pg/commitdiff/8f72becd6b9484fbb429651d8859faa36532a35a

  • 在 pg_stat 统计信息中计算 SP-GiST 索引扫描。不知何故，spgist 忽略了调用 pgstat_count_index_scan() 的需要。因此，pg_stat_all_indexes.idx_scan 和等效列对于 SP-GiST 索引永远不会变为非零值，尽管相关的每个元组计数器工作正常。此修复的工作方式与其他索引 AM 略有不同，即计数器增量发生在 spgrescan 而不是 spggettuple/spggetbitmap 中。看起来这不会使用户可见的语义产生明显的差异，因此我不会费力引入一个 is-this-the-first-call 标志来使计数器增长发生在相同的位置。根据 Christian Quest 的错误 #17163。回溯修复到所有支持的版本。讨论：https://postgr.es/m/17163-b8c5cc88322a5e92@postgresql.org https://git.postgresql.org/pg/commitdiff/3778bcb39a94a3b6a821fd60fcd9919a95725e78

  • 文档：在 src/backend/regex/README 中添加一些关于 LACON 执行的内容。我在考虑可能的优化时编写了此内容，但无论是否最终进行优化，它都是对现有代码的有用描述。因此单独推送它。https://git.postgresql.org/pg/commitdiff/10d58228bb1c824c5124ecd1b6c5e46a3c157a39

Amit Kapila 推送

  • 修复 Alter Subscription 的 Add/Drop Publication 行为。当前的刷新行为尝试仅刷新添加/删除的发布，但这会导致从订阅中删除错误的表。我们不能仅刷新已删除的发布，因为很可能此时某些表已从发布中删除，而这些表现在仍将作为订阅的一部分保留。此外，属于正在删除的发布的表也有可能属于另一个发布，因此我们不能删除这些表。因此，我们决定默认情况下，添加/删除命令也将像 REFRESH PUBLICATION 一样工作，这意味着它们将刷新所有发布。我们可以保留 “添加发布” 的旧行为，但最好与 “删除发布” 保持一致。作者：Hou Zhijie 审阅人：Masahiko Sawada, Amit Kapila 回溯修复到：14，该行为是在 14 版本中引入的。讨论：https://postgr.es/m/OS0PR01MB5716935D4C2CC85A6143073F94EF9@OS0PR01MB5716.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/1046a69b3087a6417e85cae9b6bc76caa22f913b

  • 修复逻辑解码中的 TOAST 重写。提交 325f2ec555 引入了 pg_class.relwrite，以跳过在 DDL 期间作为堆重写一部分创建的表上的操作。它通过 pg_class 中的这个新字段将这种瞬态堆链接到原始关系 OID，但忘记对 TOAST 表进行任何处理。因此，逻辑解码无法跳过在内部创建的 TOAST 表上的操作。当我们尝试解码下一个操作的 WAL 时，这会导致错误，因为该操作似乎有一个 TOAST 数据，而实际上它没有任何 TOAST 数据。为了解决这个问题，我们还为内部创建的 TOAST 表设置了 pg_class.relwrite，这允许在逻辑解码期间跳过对它们的操作。作者：Bertrand Drouvot 审阅人：David Zhang, Amit Kapila 回溯修复到：11，该行为是在 11 版本中引入的。讨论：https://postgr.es/m/b5146fb1-ad9e-7d6e-f980-98ed68744a7c@amazon.com https://git.postgresql.org/pg/commitdiff/29b5905470285bf730f6fe7cc5ddb3513d0e6945

  • 向逻辑复制工作器的错误上下文添加逻辑更改详细信息。之前，在订阅端，我们为元组数据转换失败设置了错误上下文回调。此提交将现有的错误上下文回调替换为全面的回调，以便它不仅显示数据转换失败的详细信息，还显示应用工作器或表同步工作器正在应用的逻辑更改的详细信息。显示的附加信息将是命令、事务 ID 和时间戳。只有在应用更改时才会将错误上下文添加到错误中，而不会在执行接收数据等其他工作时添加。这将帮助用户诊断逻辑复制期间出现的问题。它还可以用于将来允许在订阅端跳过特定事务的工作。作者：Masahiko Sawada 审阅人：Hou Zhijie, Greg Nancarrow, Haiying Tang, Amit Kapila 测试人：Haiying Tang 讨论：https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/abc0910e2e0adfc5a17e035465ee31242e32c4fc

藤井正雄推送

Etsuro Fujita 推送

Peter Eisentraut 推送

Robert Haas 推送了

  • 修复并行工作进程中损坏的快照处理。Pengchengliu 报告了在使用溢出的快照执行并行扫描时，并行工作进程中出现断言失败。最直接的原因是 TransactionXmin 设置为不正确的值。根本原因是 parallel.c 中不正确的快照处理。特别是，InitializeParallelDSM() 无条件地调用 GetTransactionSnapshot()，因为我（rhaas）错误地认为它总是检索现有的快照，而在隔离级别低于可重复读的情况下，它实际上是获取一个新的快照。因此，只有在整个事务实际只有一个快照的较高隔离级别才这样做。仅此本身不足以解决问题，因为我们仍然需要保证在工作进程中正确设置 TransactionXmin。最简单的方法似乎是将领导者的活动快照安装为事务快照，如果领导者没有序列化事务快照。这不会影响未来 GetTrasnactionSnapshot() 调用的结果，因为那些调用无论如何都必须获取新的快照；我们关心的是设置 TransactionXmin 的副作用。报告人：Pengchengliu。补丁作者：Greg Nancarrow，除了我提供的一些注释文本。讨论：https://postgr.es/m/002f01d748ac$eaa781a0$bff684e0$@tju.edu.cn https://git.postgresql.org/pg/commitdiff/a780b2fcce6cf45462946fffcd84021a4d1429c8

John Naylor 推送了

Peter Geoghegan 推送了

Daniel Gustafsson 推送了

Stephen Frost 推送了

Noah Misch 推送了

  • 修复在 wal_level=minimal 模式下，`CREATE TABLESPACE` 崩溃恢复时的数据丢失问题。如果在 `CREATE TABLESPACE` 和下一个检查点之间系统崩溃，可能会导致表空间中的某些文件意外地不包含任何行。受影响的文件是那些系统没有写入 WAL 的文件；请参阅 `wal_skip_threshold` 文档。在 v13 之前，另一组条件控制着 WAL 的写入；请参阅 v12 的 <sect2 id="populate-pitr">。（v12 的条件在某些方面更广泛，而在另一些方面更狭窄。）用户可能需要审计非默认表空间，以查找意外的短文件。该错误可能会截断索引，而不会影响关联的表，重建索引可以修复该特定问题。此修复通过使 `create_tablespace_directories()` 更像 `TablespaceCreateDbspace()` 来解决此错误。`create_tablespace_directories()` 递归地删除表空间内容，原因是 WAL 重做会重新创建所有被删除的内容。该假设适用于其他 `wal_level` 值。在 `wal_level=minimal` 下，旧方法可能会删除没有其他副本的文件。回溯到 9.6（所有受支持的版本）。由 Robert Haas 和 Prabhat Sahu 审核。由 Robert Haas 报告。讨论：https://postgr.es/m/CA+TgmoaLO9ncuwvr2nN-J4VEP5XyAcy=zKiHxQzBbFRxxGxm0w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/97ddda8a82ac470ae581d0eb485b6577707678bc