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

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

由 PWN 发布于 2021-10-04
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

PostgreSQL 10 月份的招聘信息

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

PostgreSQL 新闻

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

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

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

已应用的补丁

Thomas Munro 推送了

Peter Geoghegan 推送了

Michaël Paquier 推送了

Tom Lane 推送了

  • 重新启用 contrib/bloom 的 TAP 测试。这些测试在 2018 年被禁用（提交 d3c09b9b1），因为在构建场中观察到了故障。但是我无法在 longfin 的主机上重现任何故障，所以我很好奇我们是否以及在多大程度上修复了该问题。让我们重新启用它（仅在 HEAD 中），看看会发生什么。讨论：https://postgr.es/m/2769443.1632773967@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/7d1aa6bf1c27bf7438179db446f7d1e72ae093d0

  • 修复 contrib/bloom TAP 测试中的不稳定问题。事实证明，提交 d3c09b9b1 中抱怨的不稳定性有一个非常简单的解释。测试脚本等待备用服务器将传入的 WAL 刷新到磁盘，但它应该等待 WAL 被重放，因为我们正在测试其可见的影响。同时，使用 wait_for_catchup 而不是重新发明该逻辑，并调整 $Test::Builder::Level 以改进未来的错误报告。向后移植到 v12，其中必要的结构已引入（参见上述提交）。也向后移植 7d1aa6bf1，以便测试能够实际运行。讨论：https://postgr.es/m/2854602.1632852664@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6bc6bd47cf715c8717a8af3f617957045772d38b

  • 将 ETIMEDOUT 视为表示不可恢复的连接故障。将 ETIMEDOUT 添加到 ALL_CONNECTION_FAILURE_ERRNOS 的“标识先前建立的网络连接的硬故障的错误代码”列表中。虽然可以想象有时可以恢复这种情况，但也可以对其他条目（例如 ENETDOWN）这样说。为了支持这一点，在相关基础设施（例如 TranslateSocketError()）中，将 ETIMEDOUT 与其他套接字错误同等处理。（我也在 TranslateSocketError() 中进行了一些表面上的调整。）代码现在假设 ETIMEDOUT 在所有地方都已定义，这是应该的，因为自 SUSv2 以来，POSIX 就要求这样做。也许应该向后移植此更改，但是考虑到之前没有投诉，以及由于重新定义符号而在 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 年跨越了斋月结束，如果将时区设置为 Africa/Casablanca，则会导致测试的输出发生变化。（可能在其他穆斯林地区也是如此；我没有检查。）此测试绝对没有理由进行时间间隔减法，因此只需删除它并使用表示预期值的纯 timestamptz 常量即可。根据 Andres Freund 的报告。向后移植到 v10，其中引入了此测试脚本。讨论：https://postgr.es/m/20210930183641.7lh4jhvpipvromca@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/20f8671ef69b864c25ffa59471814102c1260d78

  • 修复 Portal 快照跟踪以正确处理子事务。提交 84f5c2908 忘记考虑 EnsurePortalSnapshotExists 可能会在生命周期短于 Portal 的子事务内运行的可能性。在这种情况下，新的活动快照会在子事务结束时被弹出，从而在 Portal 中留下一个悬空的指针，导致混乱。为了修复这个问题，请确保 ActiveSnapshot 堆栈条目标记了与关联的 Portal 相同的子事务嵌套级别。这样做肯定是安全的，因为除非堆栈为空，否则我们根本不会来到这里；因此，我们无法创建无序堆栈。我们还在 PortalRunUtility 设置 portalSnapshot 的情况下应用此逻辑，以确保该路径不会导致类似的问题。该路径不能创建无序堆栈的情况稍微不太明确，因此添加一个断言来保护它。由 Bertrand Drouvot 报告和修补（我进行了 kibitzing）。像之前的提交一样，向后移植到 v11。讨论：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 之前意外地没有失败，因此无论如何都无法构建一个面向未来的测试用例。根据 Simon Perepelitsa 提出的错误 #17207。向后移植到 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 时区名称的映射。这根据 CLDR 项目的 windowsZones.xml 文件，修正了 win32_tzmap[] 中的许多条目，并添加了一些新条目。非表面更改分为四个主要类别：* 明显的错误：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 作为“格林威治标准时间”，因为对于人们认为该时区名称的含义而言，这似乎比 Africa/Casablanca 更有可能。CLDR 在这里使用 Atlantic/Reykjavik，但它也好不到哪去。对于“中国标准时间”，Asia/Shanghai 似乎比香港更合适。Europe/Sarajevo 现在是贝尔格莱德的链接，即“中欧标准时间”；因此，请使用华沙作为“中欧标准时间”。America/Sao_Paulo 似乎比 Araguaina 更能代表“东南美洲标准时间”。Africa/Johannesburg 似乎比哈拉雷更能代表“南非标准时间”。* 新的 Windows 时区名称：“以色列标准时间” “加里宁格勒标准时间” 针对各种 N 的 “俄罗斯时区 N” “新加坡标准时间” “南苏丹标准时间” “西中非标准时间” “约旦河西岸标准时间” “育空标准时间” 其中一些取代了旧的拼写，但我保留了旧的拼写，以防我们的代码在具有旧数据的机器上运行。* 将别名（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()。因此，错误消息不是特别中肯，但至少它在那里。提交 2f48ede08 丢失了这个细节。相反，普通的 RETURN QUERY 坚持要求查询必须是 SELECT（通过检查 SPI_OK_SELECT），而 RETURN QUERY EXECUTE 根本没有检查查询类型。这些更改都不是故意的。在 EXECUTE 情况下的唯一方便的检查位置是在 _SPI_execute_plan 中，因为我们直到那时才进行解析分析。因此，我们需要传递一个标志，说明是否要强制要求查询返回元组。幸运的是，我们可以在不中断 ABI 的情况下将另一个布尔值挤入 struct SPIExecuteOptions 中，因为那里有填充空间。（任何扩展都不太可能已经在使用这个新的结构，但在 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 写入会很愉快地从断裂记录的起始位置恢复，覆盖该记录 ... 但是任何备用服务器或备份可能已经接收了该段的副本，而且它们不会回退。这会导致备用服务器在主服务器崩溃后停止跟随主服务器：LOG：在 A8/D9FFFBC8 处的无效 contrecord 长度 7262，因为备用服务器仍然尝试读取原始长 WAL 记录的延续记录 (contrecord)，但它不在那里，而且永远不会在那里。一种解决方法是停止副本，删除 WAL 文件，然后重新启动它 —— 此时会从主服务器获取一个全新的副本。但这非常费力，我敢打赌很多用户会直接放弃并重新克隆备用服务器。在提交 515e3d84a0b5 中已经尝试修复这个问题，但它只解决了 WAL 归档的情况，因此流复制仍然是一个问题（以及其他问题，例如在服务器崩溃后关闭时进行文件系统级别的备份），并且它也存在性能可扩展性问题；因此必须撤消。此提交使用 Andres Freund 建议的方法修复了此问题，其中保留了分割的 WAL 记录的初始部分，并在丢失 contrecord 的地方写入一种特殊类型的 WAL 记录，以便副本中的 WAL 回放知道跳过损坏的部分。使用这种方法，我们可以继续在段文件完成后立即流式传输/归档它们，并且损坏记录的回放将在崩溃点顺利进行。由于添加了一种新的 WAL 记录类型，用户应注意先升级备用服务器，然后再升级主服务器。否则，如果主服务器碰巧写入这样的记录，他们可能会面临备用服务器无法启动的风险。添加了一个新的 TAP 测试来验证这一点，但其可移植性尚待观察。自从引入物理复制以来，这个问题就一直存在，因此回溯所有版本。在稳定分支中，将新的 XLogReaderState 成员保留在结构的末尾，以避免 ABI 中断。作者：Á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

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

  • 如果同时指定了 SKIP LOCKED 和 WITH TIES，则报错。错误 #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 回溯到：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 推送