2025年9月25日: PostgreSQL 18 发布！

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 项目的持续集成系统。已发布

dbForge Schema Compare 1.2 for PostgreSQL 发布。已发布

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

本周人物

2021 年 8 月 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

Planet 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 节点。通过 process_pending_request() 检索元组来修复。根据 buildfarm，来自 Michael Paquier。回溯到 v14，与前一个提交相同。感谢 Tom Lane 的测试。讨论：https://postgr.es/m/YQP0UPT8KmPiHTMs%40paquier.xyz https://git.postgresql.org/pg/commitdiff/a8ed9bd59d48c13da50ed2358911721b2baf1de3

  • postgres_fdw: 修复外表中的生成列问题。postgres_fdw 将远程表中的生成列导入为普通列，在插入外表时导致“ERROR: cannot insert a non-DEFAULT value into column "foo””之类的失败，因为它试图将值插入到生成列中。为了修复，我们假定 postgres_fdw 外表中的生成列定义为代表底层远程表中的生成列，并执行以下操作：* 在插入或更新时，将 DEFAULT 发送到远程服务器，而不是本地服务器计算的生成列值。

  • 向 postgresImportForeignSchema() 添加“import_generated”选项，以便在从远程服务器导入外表定义时包含列生成表达式。该选项默认值为 true。这个假设似乎是合理的，因为这将使 postgres_fdw 外表的查询返回与生成表达式一致的生成列值。在此期间，修复了 postgresImportForeignSchema() 中的另一个问题：当启用了 import_default 选项时，它试图将列生成表达式包含在外表定义的列默认表达式中。根据 Daniel Cherniy 的 bug #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)，但需要 plain 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 中的歧义。不是试图选择不会与任何用户定义的 matview 列名冲突的表别名，而是调整查询的语法，使别名仅用于不能被误认为是列名的地方。这主要包括编写"alias.*"而不是简单的“alias”，这增加了人类和机器的可读性。我们确实遇到了"SELECT alias.*"的行为与“SELECT alias”不同的问题，但我们可以使用 hack 规则 utils.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 尚未完成，因此没有其他地方会指向它。根据 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 优化提出的补丁。撤销该数据结构更改。相反，通过不更改捕获子表达式的端点来解决不更改捕获子表达式的端点的问题。我们不需要这样做，因为那一点的目的是确保原子具有与我们将分支连接的外部状态对不同的端点。在括号子表达式的情况下，我们已经创建了合适的端点，因此额外的端点只是无用的开销。这似乎比 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 RelOptInfos 时花费的时间可能占总规划时间的很大一部分。在这里，我们添加了一个 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 的能力，当我们想要执行分区表的扫描并且所需的排序顺序与分区键相同，并且分区表的定义方式使得较早的分区保证只包含比后续分区小的值时。然而，以前对于 LIST 分区表，当存在允许多个 Datums 的分区时，我们不允许这些有序分区扫描。这是一个非常容易的检查，我们可能还可以通过检查是否存在交错分区来做得更好，但当时我们无法了解哪些分区被剪枝了，因此我们仍然可能不允许所有交错分区被剪枝的情况。自从 475dbd0b7 以来，我们现在了解了被剪枝的分区，我们可以在 partitions_are_ordered() 中做得更好。在这里，我们将通过分区修剪的分区传递给 partitions_are_ordered()，对于 LIST 分区，让它检查是否存在与 PartitionBoundInfo 中定义的新的“interleaved_parts”字段相同的活动分区。对于 RANGE 分区，我们可以放宽导致分区无序的代码（如果存在 DEFAULT 分区）。由于我们现在知道哪些分区被剪枝了，partitions_are_ordered() 在 DEFAULT 分区被剪枝时返回 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 已推送

  • 修复 to_char() 使用 'EEEE' 格式时的除零错误。这修复了一个长期存在的 bug，当使用 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() 来说不是问题，因为 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

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

Fujii Masao 提交

Peter Eisentraut 提交