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

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

发布于 2021-08-10，作者：PWN
PWN

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

PGConf NYC 将于 2021 年 12 月 3 日至 4 日举行。CfP 征稿开放，赞助机会也已开放。

PostgreSQL 产品新闻

Pgpool-II 4.2.4、4.1.8、4.0.15、3.7.20 和 3.6.27 发布，这是 PostgreSQL 的连接池和语句复制系统，已发布

pgmoneta 0.4.0 发布，这是 PostgreSQL 的备份和恢复系统，已发布

Buildfarm 13.1 软件发布，这是 PostgreSQL 项目的持续集成系统，已发布

适用于 PostgreSQL 的 dbForge Schema Compare 1.2 已发布

pg_timetable 4.0.0 发布，这是 PostgreSQL 的作业调度器。https://github.com/cybertec-postgresql/pg_timetable/releases

本周人物

8 月份的 PostgreSQL 工作

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

PostgreSQL 新闻

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

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

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

已应用补丁

Amit Kapila 推送

Etsuro Fujita 推送

  • 修复提交 1ec7fca8592178281cd5cdada0f27a340fb813fc 中的疏忽。我未能考虑到当 ExecAppendAsyncEventWait() 使用 postgres_fdw 通知多个支持异步的节点时，前面的节点可能会调用 process_pending_request() 来处理后续节点发出的挂起异步请求。在这种情况下，当收到通知时，后续节点应该从 process_pending_request() 获取的元组中生成一个元组返回给父 Append 节点。修复。根据 Michael Paquier 通过 buildfarm 提出的问题。与之前的提交一样，向后移植到 v14。感谢 Tom Lane 的测试。讨论：https://postgr.es/m/YQP0UPT8KmPiHTMs%40paquier.xyz https://git.postgresql.org/pg/commitdiff/a8ed9bd59d48c13da50ed2358911721b2baf1de3

  • postgres_fdw：修复外表中的生成列问题。postgres_fdw 将远程表中的生成列作为普通列导入，并在插入外表时导致诸如“错误：无法将非 DEFAULT 值插入列“foo””之类的失败，因为它试图将值插入到生成列中。为了修复此问题，我们执行以下操作，假设 postgres_fdw 外表中的生成列的定义使其表示底层远程表中的生成列：* 在插入或更新时，向外服务器发送生成列的 DEFAULT，而不是在本地服务器上计算的生成列值。

  • 向 postgresImportForeignSchema() 添加一个选项“import_generated”，以便将从外服务器导入的外表的定义中包含列生成表达式。默认情况下，此选项为 true。这种假设似乎是合理的，因为这样可以使 postgres_fdw 外表的查询返回与生成表达式一致的生成列的值。在此处，修复 postgresImportForeignSchema() 中的另一个问题：当启用 import_default 选项时，它试图将列生成表达式作为外表定义中的列默认表达式包含在内。根据 Daniel Cherniy 提出的错误 #16631。向后移植到添加生成列的 v12。讨论：https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org https://git.postgresql.org/pg/commitdiff/aa769f80ed80b7adfbdea9a6bc267ba4aeb80fd7

Andres Freund 推送

Thomas Munro 推送了

Tom Lane 推送了

  • 文档：对逻辑复制协议文档进行小幅改进。在适当的地方，使用后端代码的数据类型名称（例如 XLogRecPtr 或 TimestampTz）注释消息字段数据类型。之前我们只说“Int64”，这没有提供足够的信息。此外，澄清了对对象 OID 的引用，并使用现有的约定来表示必须具有固定值的字段值。Vignesh C，由 Peter Smith 和 Euler Taveira 审阅。讨论：https://postgr.es/m/CALDaNm0+fatx57KFcBopUZWQpH_tz3WKKfm-_eiTwcXui5BnhQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a5cb4f9829fbfd68655543d2d371a18a8eb43b84

  • 添加各种新的 regexp_xxx SQL 函数。此补丁添加了新函数 regexp_count()、regexp_instr()、regexp_like() 和 regexp_substr()，并使用一些新的可选参数扩展了 regexp_replace()。所有这些函数都遵循 Oracle 中使用的定义，尽管由于使用我们自己的正则表达式引擎，正则表达式语言存在细微差异 - 最显著的是，默认的换行符匹配行为不同。类似的函数也出现在 DB2 和其他地方。除了方便移植之外，这些函数对于某些任务来说比我们现有的 regexp_match[es] 函数更容易使用。Gilles Darold，由我进行了大量修订 讨论：https://postgr.es/m/fc160ee0-c843-b024-29bb-97b5da61971f@darold.net https://git.postgresql.org/pg/commitdiff/6424337073589476303b10f6d7cc74f501b8d9d7

  • 不要省略到 typmod -1 的强制转换。将已具有特定 typmod 的类型的值强制转换为未指定的 typmod，就运行时行为而言，不会做任何事情。但是，它确实应该更改表达式的公开类型以匹配。到目前为止，coerce_type_typmod 没有理会这一点，这在递归联合等上下文中会造成陷阱。例如，如果联合的一侧是 numeric(18,3)，但它需要是普通的 numeric 才能与另一侧匹配，则没有直接的方法来表达这一点。这很容易修复，通过插入 RelabelType 来更新表达式的公开类型。但是，更改此行为会让人感到有点不安，因为它已经存在很长时间了。（我强烈怀疑它之所以如此，部分原因是该逻辑早于 7.0 中 RelabelType 的引入。57b30e8e2 的提交日志消息在这里很有趣。）作为一种妥协，我们将偷偷地将更改放入 14beta3 中，如果在接下来的三个月中没有出现投诉，则考虑回溯到稳定分支。讨论：https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5c056b0c2519e602c2e98bace5b16d2ecde6454b

  • 真正修复 REFRESH MATERIALIZED VIEW CONCURRENTLY 中的歧义。与其尝试选择不会与任何可能的用户定义物化视图列名冲突的表别名，不如调整查询的语法，使别名仅在不会被误认为是列名的地方使用。这主要包括编写 "alias.*" 而不仅仅是“alias”，这为人和机器都增加了清晰度。我们确实存在 "SELECT alias.*" 的行为与“SELECT alias”不同的问题，但是我们可以使用 ruleutils.c 用于 SELECT 列表中整行变量的相同技巧：编写 "alias.*::compositetype"。我们不妨在这样做之后恢复到原始别名；它们更容易阅读。像 75d66d10e 一样，回溯到所有受支持的分支。讨论：https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9179a82d7af38112cd0f6e84ab62d0b3592a6e0e

  • 使正则表达式引擎的回溯引用相关编译状态更加可靠。到目前为止，我们通过存储指向相关 subRE 节点的指针来记住捕获括号子表达式的定义。这在以前是可以的，因为在解析正则表达式的其余部分时，该 subRE 不再被修改。然而，在提交 ea1268f63 之后，情况不再如此：parseqatom() 的外部调用可以随意涂改该 subRE。这似乎仍然有效，因为我们在“准备一个通用的状态框架”节中塞入子原子中的状态与子原子的原始端点在语义上并没有真正的不同。但这很容易被破坏，而且这绝对不是之前的工作方式。考虑到这一点以及之前提交中修复的问题，最好完全消除对 subRE 节点的这种依赖。我们不需要整个子 subRE 用于未来的回溯引用，只需要它的开始和结束 NFA 状态；所以让我们只存储指向这些状态的指针。此外，在处理立即嵌套的捕获括号时，我们创建额外的 subRE 的情况下，让额外的 subRE 具有与原始子 subRE 相同的开始/结束状态（s/s2 而不是 lp/rp）似乎是明智的。我认为从 lp 到 rp 链接它实际上可能在语义上是错误的，尽管由于 Spencer 的原始代码就是那样做的，我并不是完全确定。无论如何，使用 s/s2 肯定不会错。根据 Mark Dilger 的报告。向引入问题的 v14 版本进行反向移植。讨论：https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com https://git.postgresql.org/pg/commitdiff/cb76fbd7ec87e44b3c53165d68dc2747f7e26a9a

  • 修复正则表达式引擎中的释放后使用问题。提交 cebc1d34e 教会了 parseqatom() 通过消除多余的 subRE 节点来优化分支仅包含一个“混乱”原子的情况。我们真正应该做的方式是保留为“混乱”子原子构建的 subRE；但是为了避免更改 parseqatom 的标称 API，我使其在将其字段复制到 parsebranch() 创建的外部 subRE 后删除该节点。当时这似乎确实有效；但在 ea1268f63 之后变得危险，因为后来的提交允许较低级别的 parse() 返回一个也由某些 v->subs[] 条目指向的 subRE。这意味着我们可能会在 v->subs[] 中最终得到一个悬空指针，允许稍后的回溯引用行为不当，但这只有在该 subRE 结构在中间被重用时才会发生。因此，损坏似乎仅限于 '((...))...(...\2' 之类的情况。为了修复，请执行我之前应该做的事情并修改 parseqatom 的 API，使其可以删除调用者的 subRE 而不是被调用者的 subRE。这更安全，因为我们知道该 subRE 尚未完成，因此其他地方不会有指向它的指针。根据 Mark Dilger 的报告。向引入问题的 v14 版本进行反向移植。讨论：https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com https://git.postgresql.org/pg/commitdiff/cc1868799c8311ed1cc3674df2c5e1374c914deb

  • 重新思考正则表达式引擎的回溯引用相关编译状态。在推送 cb76fbd7e 后我几乎立刻感到懊悔，发现从数据结构中删除捕获子表达式的 subREs 会破坏我提出的 REG_NOSUB 优化的补丁。恢复该数据结构更改。相反，通过不更改端点来解决有关不更改捕获 subRE 的端点的问题。我们不需要这样做，因为该位的目的是确保原子具有与我们将分支连接之间的外部状态对不同的端点。我们已经在带括号的子表达式的情况下创建了合适的状态，因此额外的状态只是无用的开销。这似乎比 Spencer 的原始编码更容易理解，而且通过节省一些状态创建和弧更改，它也应该更快一些。（我实际上在 Jacobson 的 Web 语料库上看到了几个百分点的改进，但这几乎高于噪音水平，所以我不会太相信该结果。）此外，修复 ea1268f63 添加的逻辑，以确保 v->subs[subno] 中记录的 subRE 正好是 capno == subno 的那个。Spencer 的原始编码记录了捕获节点的子 subRE，这在具有正确的端点状态方面是可以的，但从 cb76fbd7e 开始，捕获 subRE 本身始终也具有这些端点。我认为这种不一致对于 REG_NOSUB 优化来说令人困惑。与之前一样，反向移植到 v14。讨论：https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com https://git.postgresql.org/pg/commitdiff/00116dee5ad4c1964777c91e687bb98b1d9f7ea0

  • 文档：删除伪造的 <indexterm> 项目。显然是 665c5855e 中的复制粘贴。9.6 文档工具链抱怨重复的索引条目，尽管我们现代的工具链没有。无论如何，这些 GUC 肯定不是关于这些值的默认设置。https://git.postgresql.org/pg/commitdiff/cf5ce5aa70d33fc3048ab63c50585b8cc0f11dfd

David Rowley 推送了

  • 在 RelOptInfo 中跟踪未修剪分区的 Bitmapset。对于具有大量分区的分区表，如果查询能够修剪除极少数分区之外的所有分区，那么在计划器中循环遍历 RelOptInfo.part_rels 检查非 NULL RelOptInfo 所花费的时间可能占总计划时间的很大一部分。这里我们添加一个 Bitmapset 来记录未修剪的分区。这使我们能够通过循环遍历 Bitmapset 来更有效地跳过修剪的分区。在无法修剪或无法修剪很多分区的情况下，这会导致非常轻微的减速，但是，这些情况的计划本来就比较慢，并且与创建大量分区的路径等其他任务相比，循环遍历 Bitmapset 的开销是无法衡量的。由 Amit Langote 和 Zhihong Yu 审核。讨论：https://postgr.es/m/CAApHDvqnPx6JnUuPwaf5ao38zczrAb9mxt9gj4U1EKFfd4AqLA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/475dbd0b718de8ac44da144f934651b959e3b705

  • 允许在更多情况下进行有序分区扫描。当我们要执行分区表的扫描，并且所需的排序顺序与分区键相同，并且分区表的定义方式保证较早的分区仅包含比以后的分区更低的值时，959d00e9d 添加了使用 Append 节点而不是 MergeAppend 的功能。但是，以前当有任何允许多个 Datums 的分区时，我们不允许对 LIST 分区表进行这些有序分区扫描。这是一个非常廉价的检查，如果存在交错的分区，我们可能会做得更好，但是在当时我们无法看到哪些分区被修剪，因此我们仍然可能不允许所有交错分区都被修剪的情况。自 475dbd0b7 以来，我们现在了解了修剪的分区，因此我们可以在 partitions_are_ordered() 中做得更好。在这里，我们将哪些分区在分区修剪后幸存下来传递给 partitions_are_ordered()，并且对于 LIST 分区，检查是否存在也存在于 PartitionBoundInfo 中定义的新 “interleaved_parts” 字段中的任何活动分区。对于 RANGE 分区，我们可以放松代码，如果存在 DEFAULT 分区，该代码会导致分区无序。由于我们现在知道哪些分区被修剪，因此当 DEFAULT 分区被修剪时，partitions_are_ordered() 现在返回 true。由 Amit Langote 和 Zhihong Yu 审核。讨论：https://postgr.es/m/CAApHDvrdoN_sXU52i=QDXe2k3WAo=EVry29r2+Tq2WYcn2xhEA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/db632fbca392389807ffb9d9b2207157e8e9b3e8

  • 删除未使用的函数声明。似乎声明了 check_track_commit_timestamp，但从未在我们的代码库中定义。这很可能只是添加提交时间戳的原始补丁的开发版本的遗留物。让我们删除这个无用的声明。包含 guc.h 也似乎是多余的。作者：Andrey Lepikhov。讨论：https://postgr.es/m/f49aefb5-edbb-633a-af07-3e777023a94d@postgrespro.ru https://git.postgresql.org/pg/commitdiff/75a2d132eaef7d951db894cf3201f85e9a524774

Bruce Momjian 推送了

Peter Geoghegan 推送

Dean Rasheed 推送

  • 修复使用 'EEEE' 格式的 to_char() 中的除零错误。这修复了一个长期存在的错误，当使用 to_char() 格式化科学计数法中的数值时，如果值的指数小于 -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001)，它会产生除零错误。此错误的原因是 get_str_from_var_sci() 将其输入除以 10^exp，而 10^exp 是使用 power_var_int() 生成的。然而，power_var_int() 中的下溢测试会导致如果结果比例太小则返回零。对于 power_var_int() 的唯一其他调用者 power_var() 来说，这不是问题，因为它将 rscale 限制为 1000，但在 get_str_from_var_sci() 中，指数可以小得多，需要更大的 rscale。通过引入一个直接计算 10^exp 的新函数来修复，没有 rscale 限制。这也允许更有效地计算 10^exp，而无需任何数值乘法、除法或舍入。讨论：https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/226ec49ffd78c0f246da8fceb3094991dd2302ff

  • 调整数值代码中的整数溢出测试。以前，数值代码通过将较大类型的整数值强制转换为较小类型，然后测试反向转换是否产生原始值来测试该值是否适合较小类型。这完全没问题，只是它在 buildfarm 动物 castoroides 上引起了测试失败，这很可能是由于编译器错误造成的。相反，通过与 PG_INT16/32_MIN/MAX 进行比较来执行这些测试。这与 int84() 等其他地方的现有代码相匹配，后者经过了更广泛的测试，因此不太可能出错。同时，添加涵盖数值到 int8/4/2 转换的回归测试，并将最近添加的测试调整为 434ddfb79a（在 v11 分支上）的样式，以便更容易诊断失败。通过 Tom Lane 的 buildfarm，由 Tom Lane 审核。讨论：https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2642df9fac09540c761441edd9bdd0a72c62f39c

Fujii Masao 推送

Peter Eisentraut 推送