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

PostgreSQL 每周新闻 - 2021 年 9 月 19 日

由 PWN 发布于 2021-09-20
PWN

PostgreSQL 每周新闻 - 2021 年 9 月 19 日

Pgpool-II 4.2.5，PostgreSQL 的连接池和语句复制系统，已发布

Database Lab 2.5，用于快速克隆大型 PostgreSQL 数据库以构建非生产环境的工具，已发布。

pgexporter 0.1.0，一个用于 PostgreSQL 的 Prometheus 指标导出器，已发布

PostgreSQL 产品新闻

九月份 PostgreSQL 职位

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

PostgreSQL 新闻

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

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

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

已应用的补丁

Michaël Paquier 推送

  • 重构 syslogger 管道协议，使用位掩码来表示其选项。之前的协议需要一组匹配的字符来检查发送的消息是否是最后一条，这取决于所需的目标： - “t” 和 “f” 跟踪发送到 stderr 的日志的最后一条消息。 - “T” 和 “F” 跟踪发送到 csvlog 的日志的最后一条消息。当引入新的目标时，可以使用更多字符对其进行扩展，但是使用位掩码会更加优雅。此提交更改了协议，以便在发送到 syslogger 的日志块消息的标头中使用位掩码，其中目前可用的选项如下： - log_destination 为 stderr。 - log_destination 为 csvlog。 - 如果消息是消息的最后一个块。Sehrope 在一个引入 JSON 作为 log_destination 选项的补丁集中发现了这个问题，但是他的补丁使协议标头的大小变大了。此提交保持与原始大小相同，并按需调整了协议。还要感谢 Andrew Dunstan 和 Greg Stark 的讨论。作者：Michael Paquier，Sehrope Sarkuni 讨论：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2d77d835403a20b51e17e59f0343ddc17f431eec

  • 为带有日志收集器的 csvlog 添加回归测试。这些测试已添加到 pg_ctl 的现有日志轮换测试中，该测试已经测试了 stderr。为 csvlog 添加了相同的覆盖率： - 检查 pg_current_logfile()。 - 使用预期文件名的日志轮换。 - 生成的日志内容。此测试已重构，以最大程度地减少为新的日志格式添加测试所需的工作量，从而简化一些即将进行的工作。作者：Michael Paquier，Sehrope Sarkuni 讨论：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/72b76f76161c78dd1be42592c4e5b980beef5f26

  • 修复 ECPG 连接逻辑中线程在 OOM 时出现的错误处理。在分配结构以存储连接参数关键字和值时发生内存不足错误可能会弄乱已保存的连接集，因为在失败时，pthread 互斥锁仍然会持有，新连接对象已列出但已被 free()。与其仅仅解锁互斥锁（这将使静态连接列表处于不一致状态），不如在开始测试操作之前移动连接参数的结构分配。这样可以确保在此代码路径中，连接列表和连接互斥锁始终保持一致。此错误不太可能发生，但可能会以令人惊讶的方式严重破坏 ECPG 客户端，因此将其全部回溯。报告者：ryancaicse 讨论：https://postgr.es/m/17186-b4cfd8f0eb4d1dee@postgresql.org 回溯到：9.6 https://git.postgresql.org/pg/commitdiff/fa703b317e9d261ffd34bbf5651ea29aff3ff0f0

  • 删除用于复制槽的权限检查中的代码重复。两个名为 check_permissions() 的函数使用相同的检查来验证用户是否具有处理复制槽所需的权限。此提交删除了重复的代码，并将执行检查的函数移动到 slot.c 以进行集中管理。作者：Bharath Rupireddy 审核者：Nathan Bossart, Euler Taveira 讨论：https://postgr.es/m/CALj2ACUPpVw1u7sQocFVWrSs0n10pt_G_4NPZKSxXK6cW1dErw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/026ed8efd6b1d774924937baf3209b676df4531f

  • 更新资源所有者 README，以了解支持的资源类型。所有支持的类型都直接列在 README 中，但是它已经非常过时了。此提交并非在 README 中列出所有支持的类型，而是添加了一个参考，以查看 resowner.c 中的 ResourceOwnerData 来获取此信息。为了清楚起见，稍微修改了段落的顺序。作者：Amit Langote 讨论：https://postgr.es/m/CA+HiwqHtfT9z=4H5+F7DOy0OyNHAaVwuRcakt9b2t2uADOaiag@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cae6fc2bc27cdb072693076249ce688f048ca7b7

  • 支持使用运行时计算的 GUC 的“postgres -C”。到目前为止，postgres 的 -C 选项是在初始化运行时计算的一小部分 GUC 之前处理的，这会导致结果不正确，因为 GUC 机制会回退到此类参数的默认值。例如，数据校验和可能会报告群集为“关闭”，因为控制文件尚未加载。或者 wal_segment_size 会显示 16MB 的段大小，即使 initdb --wal-segsize 使用了其他值。更糟糕的是，该命令无法正确报告最近引入的 shared_memory，这需要加载 shared_preload_libraries，因为这些库可能会请求一块共享内存。对运行时 GUC 的支持有一些限制，因为现在允许在正在运行的服务器上进行操作。其中一个值得注意的原因是，可加载库的 _PG_init() 函数是在初始化所有运行时计算的 GUC 之前调用的，并且不能保证在正在运行的服务器上执行此操作是安全的。对于 shared_memory_size 而言，我们希望在不分配内存的情况下了解将使用多少内存，因此此限制是合适的。另一个有帮助的情况是大页面，引入了不同的 GUC 来评估服务器启动前所需的大页面数量，而无需分配大量的内存。此功能由新的 GUC 标志控制，并且在此更改时，有四个参数被归类为运行时计算： - data_checksums - shared_memory_size - data_directory_mode - wal_segment_size 添加了一些 TAP 测试以提供一些覆盖，并在 pg_checksums 的测试中使用 data_checksums。根据与 Andres Freund、Justin Pryzby、Magnus Hagander 等人的讨论。作者：Nathan Bossart 讨论：https://postgr.es/m/F2772387-CE0F-46BF-B5F1-CC55516EB885@amazon.com https://git.postgresql.org/pg/commitdiff/0c39c292077ef3ba987ced0dc6ea1c8f4f1e1f4b

  • 禁用 Msys 上 postgres -C 的测试。在 Msys 上生成的输出不正确，因为 IPC::Run 以不同的方式使用本机 Perl（将 \r\n 本机转换为 \n）和 Msys perl（\r\n 按原样保留）处理输出，导致此测试失败。目前，只需禁用测试即可使构建场恢复到绿色状态。我认为正确的长期解决方案是调整 PostgresNode.pm 中的所有例程 command_checks_*，以像 psql 在使用 Msys 时一样处理此输出，在比较之前自动丢弃 \r。根据来自 jacana 和 fairywren 的报告。感谢 Tom Lane 的 ping。讨论：https://postgr.es/m/1252480.1631829409@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5adb06732d7fac8171609392ea83f18bc8f285f4

  • 阐明 pg_receivewal 在关闭 WAL 段时的一些错误。在 pg_receivewal 的 WAL 流期间关闭的 WAL 段会根据上下文生成不正确的错误消息，因为在引用 WAL 段时使用的文件名忽略了部分文件或使用的压缩方法。在这种情况下，生成的错误消息（关闭、查找或重命名失败）与物理文件名不匹配。pg_basebackup 使用相同的代码路径，但是它不使用部分后缀，因此不受影响。7fbe0c8 在 walmethods.c 中引入了回调，以获取给定上下文的确切物理文件名，此提交利用它来改进这些错误消息。如果需要，将来可以将其扩展到 pg_basebackup/ 的更多代码路径。从同一作者的更大补丁中提取。作者：Georgios Kokolatos 讨论：https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/cddcf7842c31b4d07ca75439f6b4ddacaadbbd0d

  • 改进 pg_receivewal 中的一些检查逻辑。改进了以下内容

  • 在任何 WAL 流循环之前，从源服务器获取系统标识符。这将触发额外的检查，以确保 pg_receivewal 仍然连接到具有相同系统 ID 和正确时间轴的服务器。 - 在初始流尝试之前，稍后切换 umask()（用于文件创建模式掩码）和 RetrieveWalSegSize()（以获取 WAL 段的大小）。如果连接是使用数据库完成的，则 pg_receivewal 将会失败，但仍会执行这些命令，这是浪费。现在，在检索段大小之前完成槽的创建和删除。作者：Bharath Rupireddy 审核者：Ronan Dunklau, Michael Paquier 讨论：https://postgr.es/m/CALj2ACX00YYeyBfoi55Cy=NrP-FcfMgiYYx1qRUEib3yjCVoaA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/499c9b1266395c5e4c22bd7b2cbdb7f5a64ea4fa

Amit Kapila 推送

Tom Lane 推送

  • 修复 plpgsql 中最外层块的 EXIT 语句。通常，以这种方式使用 EXIT 会导致“控制在没有 RETURN 的情况下到达函数末尾”。然而，如果该函数是不需要显式 RETURN 的函数（例如 DO 块），则不应该发生这种情况。但实际发生了，因为 add_dummy_return() 忽略了这种情况。根据 Herwig Goemans 的报告。向所有支持的分支进行反向移植。讨论：https://postgr.es/m/868ae948-e3ca-c7ec-95a6-83cfc08ef750@gmail.com https://git.postgresql.org/pg/commitdiff/1bf2518dd67be58b207979a66db7bb7c94b93a62

  • 文档：改进 CREATE/ALTER SUBSCRIPTION 的文档。改进了一些选项的描述。修复了马虎的语法和标记。Peter Smith 和 Tom Lane 讨论：https://postgr.es/m/CAHut+PtPJDSOxtuMGpO2yDrRPKxcYGL4n7HqJP9HernZE=Cj+g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1882d6cca161dcf9fa05ecab5abeb1a027a5cfd2

  • 在 PQconnectdb() 成功完成后清除 conn->errorMessage。提交 ffa2e4670 和 52a10224e 导致 libpq 的连接建立函数通常在成功连接后，连接的 errorMessage 缓冲区中留下一个非空字符串。虽然这是我故意的，但更冷静的思考表明这不是一个好主意：该字符串会有点令人困惑。此外，这破坏了至少一个通过检查 errorMessage 而不是按照文档使用 PQstatus() 来检查连接是否成功的应用程序。让我们在成功退出时清除缓冲区，恢复 v14 之前的行为。讨论：https://postgr.es/m/4170264.1620321747@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/138531f1bbc333745bd8422371c07e7e108d5528

  • 修复具有多个 AlternativeSubPlan 副本的规划器错误。我们有可能将 AlternativeSubPlan 表达式节点复制到多个位置，例如多个分区子节点的扫描限定词。然后，我们有可能在每个位置选择不同的替代方案作为最优方案。提交 41efb8340 未能考虑这种情况，因此它删除“未使用的”子计划的尝试可能会删除在其他地方仍然使用的子计划。通过延迟删除逻辑直到我们检查完给定查询级别中的所有 AlternativeSubPlan 来修复。（这确实假设 AlternativeSubPlan 不会被复制到其他查询级别，但在可预见的未来，这没有问题；参见 qual_is_pushdown_safe。）根据 Rajkumar Raghuwanshi 的报告。反向移植到出现故障逻辑的 v14。讨论：https://postgr.es/m/CAKcux6==O3NNZC3bZ2prRYv3cjm3_Zw1GfzmOjEVqYN4jub2+Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e8638d78a2cb94efba11a5dfbf3e7cd746d0af3e

  • 在 CommitTransaction 期间发送 NOTIFY 信号。以前，我们在 ProcessCompletedNotifies 中发送传出的 NOTIFY 消息的信号，该函数还负责将这些消息的相关部分发送到我们连接的客户端。因此，它必须在进入空闲状态之前的主循环处理期间运行。这种安排有两个很大的缺点：* 现在过程允许命令内部的 COMMIT，在 COMMIT 时立即向其他会话发送 NOTIFY 会很有用（尽管出于线路协议稳定性的原因，我们仍然不应该在命令结束之前将它们转发给我们的客户端）。* 诸如复制工作程序之类的后台进程根本不会发送 NOTIFY，因为它们永远不会执行客户端通信循环。我们已经收到允许在复制工作程序中运行的触发器发送 NOTIFY 的请求，所以这是一个问题。为了解决这些问题，将传出 NOTIFY 信号的传输移动到 AtCommit_Notify 中，它将在 CommitTransaction 期间发生。还将 asyncQueueAdvanceTail 的可能调用移动到那里，以确保如果后台工作程序发送大量 NOTIFY 但没有人监听，我们不会膨胀异步 SLRU。我们还可以删除 asyncQueueReadAllNotifications 的调用，从而允许 ProcessCompletedNotifies 完全消失。这是因为提交 790026972 在 PostgresMain 调用 ProcessCompletedNotifies 的旁边添加了对 ProcessNotifyInterrupt 的调用，并且它自己调用了 asyncQueueReadAllNotifications，这意味着每当传入的通知信号与传出的通知信号同时发生时，我们都会无用地执行两个这样的调用（在两个单独的事务中）。我们只需要设置 notifyInterruptPending 以确保 ProcessNotifyInterrupt 运行，我们就完成了。现有文档建议，如果自定义后台工作程序想要发送 NOTIFY 消息，应该调用 ProcessCompletedNotifies。为了避免向后分支中的 ABI 中断，将其减少为一个空例程，而不是完全删除。删除将在 v15 中进行。尽管上述问题已经存在一段时间了，但我不认为将其反向移植到 v13 之外是安全的。在 12 和 13 之间的相邻代码中发生了很多改动。至少我们还必须反向移植 51004c717，并且还需要进行大量的其他调整，因此收益风险比看起来没有吸引力。根据 Michael Powers 的错误 #15293（以及其他人的类似抱怨）。Artur Zakirov 和 Tom Lane 讨论：https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/2e4eae87d02fef51c42c2028b65d85b9e051f9eb

  • 改进 pg_import_system_collations() 的日志消息。pg_import_system_collations() 对于它没有为其创建 pg_collation 条目的区域设置（“locale -a”输出的名称）的报告有点不一致。我认为我们应该为我们拒绝的每个区域设置打印一些合适的消息，除非它与预先存在的 pg_collation 条目匹配。（不过，这都是在 DEBUG1 日志级别，所以不会在 initdb 期间产生噪音。）为以前未记录的两种情况添加消息，即无法识别的编码和仅客户端编码。重新措辞现有消息，使其具有一致的风格。Anton Voloshin 和 Tom Lane 讨论：https://postgr.es/m/429d64ee-188d-3ce1-106a-53a8b45c4fce@postgrespro.ru https://git.postgresql.org/pg/commitdiff/69e31d05b0a33f55aa5d9540917540f5fccb93a7

  • 禁止在后台工作程序中使用 LISTEN。可以在某些后台进程中执行用户定义的 SQL；例如，逻辑复制工作程序可以触发触发器。这打开了有人尝试在此类上下文中执行 LISTEN 的可能性。但是由于只有常规后端才会调用 ProcessNotifyInterrupt，因此实际上不会收到任何消息，因此注册的监听器只会阻止消息队列被清理。最终，NOTIFY 将停止工作，这很糟糕。也许有一天有人会发明基础设施来使在后台工作程序中侦听实际上有用。在此期间，禁止它。反向移植到 v13，我们在其中引入了 MyBackendType 变量。如果没有它，实现检查会困难得多，而且看起来不值得费力。讨论：https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/1316be28664f1834ac091113217537101331bdf3

  • 移除对 rangetable 大小的任意 64K 左右的限制。到目前为止，查询的 rangetable 的大小受到常量 INNER_VAR 等的限制，这些常量不能等于任何实际的 rangetable 索引。65000 无疑对于任何人来说都足够了，而且它仍然比我们可以实际处理的连接数大几个数量级。但是，我们需要为查询处理的每个子分区（或可能处理的）设置 rangetable 条目。具有几千个分区的查询正变得越来越现实，因此，即使它还没有到来，该限制成为问题的日子也指日可待。因此，让我们提高限制。此补丁没有仅仅增加 INNER_VAR 等的值，而是采用使它们成为小的负值的方法，以便 rangetable 理论上可以变得和 INT_MAX 一样长。该补丁的大部分内容都与将 Var.varno 和一些相关变量从“Index”（无符号 int）更改为普通的“int”有关。这基本上是表面上的，除了帮助调试器很好地打印它们的值之外，几乎没有实际效果。因此，我只费心更改了实际可以看到 INNER_VAR 等的地方，即解析器和大多数规划器看不到的地方。我们必须小心地在对 varno 执行小于/大于比较的地方，但是除了 IS_SPECIAL_VARNO 宏本身之外，这样的地方很少。此补丁的一个显着副作用是，虽然以前可以将 INNER_VAR 等添加到 Bitmapset 中，但现在会引发错误。我看不出将这些伪 varno 包括在真实 varno 的位图集中不会是一个错误的任何可能性，所以我认为这都是好事。尽管这涉及 outfuncs/readfuncs，但我认为不需要 catversion 的提升，因为存储的规则永远不会包含具有这些伪 varno 的 Var。Andrey Lepikhov 和 Tom Lane，在 Peter Eisentraut 的建议之后。讨论：https://postgr.es/m/43c7f2f5-1e27-27aa-8c65-c91859d15190@postgrespro.ru https://git.postgresql.org/pg/commitdiff/e3ec3c00d85bd2844ffddee83df2bd67c4f8297f

  • 修复 EXPLAIN 以处理 SEARCH BREADTH FIRST 查询。SEARCH BREADTH FIRST 的重写器转换会在类型为 RECORD 的 Var 上生成 FieldSelect，其中 Var 引用递归联合的工作表输出。EXPLAIN VERBOSE 未能处理这种情况，因为它只期望此类 Var 出现在 CteScans 而不是 WorkTableScans 中。修复此问题，并添加一些测试用例，在 SEARCH 和 CYCLE 查询上练习 EXPLAIN。原则上，这种疏忽是一个旧的错误，但似乎在没有 SEARCH BREADTH FIRST 的情况下是无法到达的，因为当尝试手动创建此类引用时，解析器会失败。所以今天我只会修补 HEAD/v14。总有一天我们可能会发现这个补丁的代码部分需要进一步向后移植。根据 Atsushi Torikoshi 的报告。讨论：https://postgr.es/m/5bafa66ad529e11860339565c9e7c166@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/3f50b82639637c9908afa2087de7588450aa866b

  • 修复 pull_varnos 以处理转换后的 PlaceHolderVars。提交 55dc86eca 更改了 pull_varnos 以使用（如果可能）PlaceHolderVar 的关联 ph_eval_at。但我错过了一个细微的点：我们可能正在查看子附加关系的限定词或 tlist 中的 PHV，在这种情况下，我们需要计算一个 ph_eval_at 值，该值已以与 PHV 本身相同的方式进行了转换（参见 adjust_appendrel_attrs）。幸运的是，PlaceHolderInfo 中提供了足够的信息，可以在没有其他外部数据的情况下进行此类转换，因此我们不需要对规划器 API 进行另一轮丑化。这有点复杂，但由于这是一个难以命中的角落案例，所以我不太担心在这里添加循环。根据 Jaime Casanova 的报告。与之前的提交一样，反向移植到 v12。讨论：https://postgr.es/m/20210915230959.GB17635@ahch-to https://git.postgresql.org/pg/commitdiff/a21049fd3f64518c8a7227cf07c56f2543241db2

  • 文档：修复拼写错误。“PGcon”应为“PGconn”。D. Frey 指出。讨论：https://postgr.es/m/163191739352.4680.16994248583642672629@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/d5eeb51bc053d75f647136026de522d6ee3bf725

Andres Freund 推送了

Peter Eisentraut 推送

Daniel Gustafsson 推送

Fujii Masao 推送

Peter Geoghegan 推送

  • pageinspect：减少页面删除 elog 的冗余。提交 e5d8a999 添加了一个 elog，该 elog 报告存储在已删除 nbtree 页面上的事务 ID 值，该提交教会页面删除存储完整的 64 位 XID。进一步思考，它似乎非常冗余，因此将其 elevel 从 NOTICE 降低到 DEBUG2。作者：Peter Geoghegan pg@bowt.ie 向后移植：14-，就像 nbtree XID 增强一样。https://git.postgresql.org/pg/commitdiff/d7897abf9e0071946e9e4e8efd2d4463607c04de