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

PostgreSQL 每周新闻 - 2021 年 10 月 3 日

发布于 2021-10-04 by PWN
PWN

PostgreSQL 每周新闻 - 2021 年 10 月 3 日

PostgreSQL 14 发布！https://postgresql.ac.cn/about/news/postgresql-14-released-2318/

PostgreSQL 产品新闻

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

oracle_fdw 2.4.0 发布。https://laurenz.github.io/oracle_fdw

pgFormatter 5.1 发布，一个用于 SQL 代码的格式化/美化工具。https://github.com/darold/pgFormatter/blob/master/ChangeLog

10 月份的 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Thomas Munro 推送

Peter Geoghegan 提交

Michaël Paquier 提交

Tom Lane 提交

  • 重新启用 contrib/bloom 的 TAP 测试。这些测试早在 2018 年就已禁用（commit d3c09b9b1），原因是 buildfarm 中出现了故障。然而，我一直未能重现 longfin 主机上的任何故障，因此我很好奇问题在何种程度上得到了解决。让我们在 HEAD 中重新启用它，看看会发生什么。讨论：https://postgr.es/m/2769443.1632773967@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/7d1aa6bf1c27bf7438179db446f7d1e72ae093d0

  • 修复 contrib/bloom TAP 测试中的不稳定问题。事实证明，commit d3c09b9b1 中抱怨的不稳定性有一个令人尴尬的简单解释。测试脚本等待 standby 将传入的 WAL 刷新到磁盘，但它应该等待 WAL 被重放，因为我们正在测试重放效果的可见性。同时，使用 wait_for_catchup 而不是重新发明该逻辑，并调整 $Test::Builder::Level 以改进未来的错误报告。回溯到 v12，这是必要基础设施引入的版本（参见上述 commit）。同时回溯 7d1aa6bf1，以便实际运行测试。讨论：https://postgr.es/m/2854602.1632852664@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6bc6bd47cf715c8717a8af3f617957045772d38b

  • 将 ETIMEDOUT 视为不可恢复的连接失败。将 ETIMEDOUT 添加到 ALL_CONNECTION_FAILURE_ERRNOS 的列表中，该列表包含 "标识已建立网络连接的硬性失败的 errnos"。虽然有人可能认为这有时是可以恢复的，但对于 ENETDOWN 等其他条目也可以这么说。为了支持这一点，在相关基础设施（如 TranslateSocketError()）中将 ETIMEDOUT 与其他套接字错误同等处理。（我还对 TranslateSocketError() 进行了一些小的外观调整。）代码现在假设 ETIMEDOUT 在所有地方都已定义，鉴于 POSIX 自 SUSv2 以来就要求它，这应该是可以的。也许应该回溯打补丁，但我对这样做感到犹豫，因为缺乏先前的抱怨，而且在 Windows 上重新定义符号存在小的 ABI 风险。即使我们决定这样做，也应该先让它在 HEAD 中进行一段时间的烘焙。Jelte Fennema 讨论：https://postgr.es/m/AM5PR83MB01782BFF2978505F6D6C559AF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com https://git.postgresql.org/pg/commitdiff/b484ddf4d2eb81736512efa35ed3e5d2a72993d8

  • 移除 002_types.pl 测试中不必要的环境依赖。通过减去 "N 天" 来计算相关时间戳对当前时区很敏感，因为我们将其解释为 "前 N 天的同一本地时间"。尽管相关间隔只有两到四天，但由于非常糟糕的运气，它们正好跨越了 2014 年的斋月结束，导致测试输出在 timezone 设置为 Africa/Casablanca 时发生变化。（可能还在其他穆斯林地区也有；我没检查。）这个测试完全没有理由去测试区间减法，所以直接去掉它，使用普通的 timestamptz 常量来表示预期值。根据 Andres Freund 的报告。回溯到 v10，该测试脚本在此版本中引入。讨论：https://postgr.es/m/20210930183641.7lh4jhvpipvromca@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/20f8671ef69b864c25ffa59471814102c1260d78

  • 修复 Portal 快照跟踪以正确处理子事务。Commit 84f5c2908 忘记考虑 EnsurePortalSnapshotExists 可能在生命周期比 Portal 短的子事务中运行的可能性。在这种情况下，新的活动快照将在子事务结束时被弹出，在 Portal 中留下一个悬空指针，从而导致混乱。为修复此问题，请确保 ActiveSnapshot 堆栈条目与关联的 Portal 具有相同的子事务嵌套级别。由于我们只有在堆栈为空时才会进入此处，因此创建乱序堆栈是绝对安全的；因此，我们不会创建乱序堆栈。为了确保该路径不会导致类似问题，我们还在 PortalRunUtility 设置 portalSnapshot 的情况下应用了此逻辑。该路径不能产生乱序堆栈的可能性不太清楚，因此添加一个断言来保护它。报告和补丁由 Bertrand Drouvot 提供（我进行了审阅）。回溯到 v11，与之前的 commit 相同。讨论：https://postgr.es/m/ff82b8c5-77f4-3fe7-6028-fcf3303e82dd@amazon.com https://git.postgresql.org/pg/commitdiff/7b5d4c29ed0262e537026cb3a85161d6cf98abcc

  • 避免在 get_variable_range() 中相信不完整的仅 MCV 统计信息。get_variable_range() 会不加思索地认为仅包含 MCV 列表的统计信息足以推导出范围估计。对于仅包含 MCV 的枚举类列来说，这没问题，但否则估计可能相当糟糕。除非 MCV 和 nullfrac 占表的全部，否则它会报告范围不确定。我认为这不需要专门的测试用例，因为快速的代码覆盖率检查证实现有的回归测试遍历了所有备选方案。鉴于提交的示例在 v11 之前意外地没有失败，构建一个面向未来的测试用例也存在疑问。根据 bug #17207，来自 Simon Perepelitsa。回溯到 v10。原则上这从一开始就是错误的，但我犹豫是否要在 9.6 中进行此类更改，因为如果有人对 9.6.24 的行为不满意，将没有第二次机会来修复它。讨论：https://postgr.es/m/17207-5265aefa79e333b4@postgresql.org https://git.postgresql.org/pg/commitdiff/8c1144ba73478b818d9cebe8ecd64a14b7d45bde

  • 重新排序 win32_tzmap[] 数组。原始意图似乎是按 Windows 时区名称进行不区分大小写的排序，但多年来的各种更改并未遵循此规则。本次提交仅移动了一些条目以恢复精确的字母顺序，以便于与处理脚本的输出进行比较。按照我们更新时区数据的惯例，回溯到所有支持的分支。讨论：https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ad740067aea5b643ca2f79da086808573d35b5f4

  • 使用 CLDR 信息更新 Windows 时区名称的映射。这纠正了 win32_tzmap[] 中的许多条目，并根据 CLDR 项目的 windowsZones.xml 文件添加了一些新条目。非表面性更改主要分为四类：* 完全错误的条目：US/Aleutan 不存在 America/Salvador 不存在 Asia/Baku 对于叶里温是错误的 Asia/Dhaka (孟加拉国) 对于阿斯塔纳 (哈萨克斯坦) 是错误的 Europe/Bucharest 对于基希讷乌是错误的 America/Mexico_City 对于切图马尔是错误的 America/Buenos_Aires 对于卡宴是错误的 America/Caracas 有自己的时区，因此不适合拉巴斯 US/Eastern 对于海地是错误的 US/Eastern 对于印第安纳州（东部）是错误的 Asia/Karachi 对于塔什干是错误的 Etc/UTC+12 不存在 Etc/GMT 时区的符号是相反的* 判断性选择：（这些更改遵循 CLDR 的选择，但第一个除外）使用 Europe/London 代替 "Greenwich Standard Time"，因为这似乎比 Africa/Casablanca 更可能是人们对该时区名称的看法。CLDR 在这里是 Atlantic/Reykjavik，但这也好不到哪里去。Asia/Shanghai 似乎比 Hong Kong 更适合 "China Standard Time"。Europe/Sarajevo 现在链接到贝尔格莱德，即 "Central Europe Standard Time"；所以使用华沙代替 "Central European Standard Time"。America/Sao_Paulo 似乎比 Araguaina 更能代表 "E. South America Standard Time"。Africa/Johannesburg 似乎比哈拉雷更能代表 "South Africa Standard Time"。* 新的 Windows 时区名称："Israel Standard Time" "Kaliningrad Standard Time" "Russia Time Zone N"（适用于各种 N）"Singapore Standard Time" "South Sudan Standard Time" "W. Central Africa Standard Time" "West Bank Standard Time" "Yukon Standard Time" 其中一些取代了旧的拼写，但我保留了旧的拼写，以防我们的代码在具有旧数据的机器上运行。* 替换别名（tzdb 链接）为底层的城市命名时区：（这遵循 tzdb 长期以来的做法，并减少了与其他条目以及 CLDR 的不一致性）US/Alaska Asia/Kuwait Asia/Muscat Canada/Atlantic Australia/Canberra Canada/Saskatchewan US/Central US/Eastern US/Hawaii US/Mountain Canada/Newfoundland US/Pacific 按照我们更新时区数据的惯例，回溯到所有支持的分支。讨论：https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9b8d68cc6589814d121344f59e927a7e4506fb8c

  • 修复 plpgsql 中 RETURN QUERY 命令的查询类型检查。在 v14 之前，我们强制要求 RETURN QUERY 中的查询必须是返回元组的类型。（例如，允许 INSERT RETURNING，但不允许纯 INSERT。）这是间接发生的，因为我们为查询打开了一个游标，所以 spi.c 检查了 SPI_is_cursor_plan()。因此，错误消息并不太准确，但至少存在。Commit 2f48ede08 丢失了这个细节。相反，纯 RETURN QUERY 要求查询是 SELECT（通过检查 SPI_OK_SELECT），而 RETURN QUERY EXECUTE 则根本没有检查查询类型。这两个更改都不是故意的。在 EXECUTE 的情况下，唯一方便的检查点是在 _SPI_execute_plan 内部，因为直到那时我们才进行解析分析。因此，我们需要传递一个标志，说明是否强制查询返回元组。幸运的是，我们可以在 struct SPIExecuteOptions 中挤入另一个布尔值，而不会破坏 ABI，因为那里有填充空间。（不太可能有任何扩展已经在使用这个新结构，但保留 v14 的 ABI 似乎仍然是个好主意。）在 spi.c 中，似乎 _SPI_execute_plan 的参数列表已经长得离谱，我不想让它更长。因此，我想直接传递 SPIExecuteOptions，这样参数列表就可以变得短得多。这使得补丁比可能需要侵入性更大，但这一切都在 spi.c 内部，所以看起来没问题。根据 Marc Bachmann 的报告。回溯到 v14，错误的的代码在此版本引入。讨论：https://postgr.es/m/1F2F75F0-27DF-406F-848D-8B50C7EEF06A@gmail.com https://git.postgresql.org/pg/commitdiff/a0558cfa395b47adb245972f5eba7978461e7baa

Peter Eisentraut 提交

Magnus Hagander 已推送

Fujii Masao 提交

Álvaro Herrera 提交

  • 在不完整记录存在时修复 WAL 重放。物理复制总是将 WAL 段文件在完成时发送给副本。如果一个 WAL 记录跨越段边界，并且主服务器在写入包含 WAL 记录下一部分的段之前崩溃，这就会成为一个问题：崩溃恢复后的 WAL 写入会从损坏记录的起点愉快地继续，覆盖该记录……但任何 standby 或备份可能已经收到了该段的副本，并且它们不会回溯。这会导致 standby 在 primary 崩溃后停止跟随 primary：LOG：invalid contrecord length 7262 at A8/D9FFFBC8，因为 standby 仍在尝试读取原始长 WAL 记录的连续记录（contrecord），但它不存在，并且永远不会存在。一种变通方法是停止 replica，删除 WAL 文件，然后重新启动它——此时会从 primary 带来一个新的副本。但这非常劳动密集，我敢打赌许多用户会放弃并重新克隆 standby。此问题的修复已在 commit 515e3d84a0b5 中尝试过，但它只解决了 WAL 归档的情况，因此流式复制仍然会是一个问题（以及其他问题，例如在服务器因崩溃而关闭时进行文件系统级别的备份），并且它还存在性能可扩展性问题；因此它必须被回滚。本次提交使用 Andres Freund 提出的方法解决了该问题，即保留被分割的 WAL 记录的初始部分，并在 contrecord 丢失的地方写入特殊类型的 WAL 记录，以便 replica 中的 WAL 重放知道要跳过损坏的部分。使用此方法，我们可以在段文件完成后立即继续流式传输/归档它们，并且在崩溃点之后对损坏记录的重放将顺利进行。因为添加了一种新的 WAL 记录类型，用户应该小心先升级 standby，然后升级 primary。否则，如果 primary 碰巧写入了此类记录，他们将面临 standby 无法启动的风险。添加了一个练习此问题的新的 TAP 测试，但其可移植性仍有待观察。自引入物理复制以来，这一直存在问题，因此回溯到所有早期版本。在稳定分支中，将新的 XLogReaderState 成员保留在结构体的末尾，以避免 ABI break。作者：Álvaro Herrera alvherre@alvh.no-ip.org 评审者：Kyotaro Horiguchi horikyota.ntt@gmail.com 评审者：Nathan Bossart bossartn@amazon.com 讨论：https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/ff9f111bce24fd9bbca7a20315586de877d74923

  • 修复新测试的两个移植性疏忽。首先，正如 Tom Lane 和 Michael Paquier 所指出的，我未能意识到 Windows 的 PostgresNode 需要额外的 pg_hba.conf 行（由 PostgresNode->set_replication_conf 添加，该函数在 'allows_streaming=>1' 被给出时由 ->init() 内部调用——但我故意省略了它）。我认为一个好的修复应该是让仅设置了 'has_archiving=>1' 的节点也进行复制，但这是一个更大的讨论。通过调用 ->set_replication_conf 来修复它，这并非史无前例，正如 Andrew Dunstan 所指出的。我还忘记了取消注释一个 IPC::Run 文件描述符的 ->finish() 调用。显然，这在几乎所有平台上都是无害的。回溯到 14。旧分支也添加了这个文件，但不是测试的这一特定部分。讨论：https://postgr.es/m/3000074.1632947632@sss.pgh.pa.us 讨论：https://postgr.es/m/YVT7qwhR8JmC2kfz@paquier.xyz https://git.postgresql.org/pg/commitdiff/d03bca4d70c29cca4f09e3a0e78a56cf97e237f3

  • 移除不稳定的、不必要的测试；修复拼写错误。Commit ff9f111bce24 添加了一些不可移植且没有有意义覆盖的测试代码。删除它，而不是尝试让它在所有地方都能工作。同时，修复了上述 commit 添加的日志消息中的拼写错误。回溯到 14。讨论：https://postgr.es/m/3000074.1632947632@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d186d233dfde4afb9dff346e13c8adaf4deec6b3

  • 当同时指定 SKIP LOCKED 和 WITH TIES 时报错。Bug #16676[1] 和 #17141[2] 都说明了 SKIP LOCKED 和 FETCH FIRST WITH TIES 的组合在返回给访问同一行的其他会话的行方面打破了预期。由于这种情况可以从语法上检测到，并且很难以其他方式修复，因此暂时禁止它，未来可能会修复。[1] https://postgr.es/m/16676-fd62c3c835880da6@postgresql.org [2] https://postgr.es/m/17141-913d78b9675aac8e@postgresql.org Backpatch-through: 13，WITH TIES 在此版本引入 作者：David Christensen david.christensen@crunchydata.com 讨论：https://postgr.es/m/CAOxo6XLPccCKru3xPMaYDpa+AXyPeWFs+SskrrL+HKwDjJnLhg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c6bc655ee2ef09449da7ff688a8be19a13db5c4a

David Rowley 提交

Amit Kapila 提交

Daniel Gustafsson 提交

Andres Freund 提交