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

PostgreSQL 每周新闻 - 2021 年 11 月 7 日

发布于 2021-11-08，作者 PWN
PWN

PostgreSQL 每周新闻 - 2021 年 11 月 7 日

PG Build 2021 将于 2021 年 11 月 30 日和 12 月 1 日 GMT 时间 09:00-17:00 在线举行。 详情。

PostgreSQL 产品新闻

PostgresDAC 3.11 发布，这是一个用于 PostgreSQL 的直接访问组件套件。 http://microolap.com/products/connectivity/postgresdac/download/

JDBC 42.3.1 已发布。

ODB C++ ORM 版本 2.5.0-b.21 已发布。

DynamoDB FDW 1.0.0 已发布。

Babelfish，一个用于 PostgreSQL 的 MS SQL Server 兼容层，已发布。

11月 PostgreSQL 工作机会

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

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

已应用补丁

Tom Lane 提交

Michaël Paquier 提交

  • 在 REINDEX CONCURRENTLY 期间保留操作符类参数。旧索引的操作符类参数 Datums 的获取方式与谓词和表达式相同，直接从系统目录中获取。然后将它们复制到将用于创建新副本的新的 IndexInfo 中。这导致新索引以默认参数重建，而不是用户预定义的参数。获得具有正确操作符类参数的新索引的唯一方法是重新从头开始创建新索引。此问题由 911e702 引入。作者：Michael Paquier 审阅者：Zhihong Yu 讨论：https://postgr.es/m/YX0CG/QpLXcPr8HJ@paquier.xyz 回溯到：13 https://git.postgresql.org/pg/commitdiff/add5cf28d48149459466b9aff374d78aebf17482

  • 为 pg_receivewal 添加时间线切换的 TAP 测试。pg_receivewal 能够跟踪时间线切换，但这并未经过测试。此测试使用空的归档位置，并从槽进行重启，使其实现比重用现有归档目录稍简单一些。作者：Ronan Dunklau 审阅者：Kyotaro Horiguchi, Michael Paquier 讨论：https://postgr.es/m/18708360.4lzOvYHigE@aivenronan https://git.postgresql.org/pg/commitdiff/0f9b9938a0367313fcf6a32fcb7fb5be9e281198

  • 重构 pg_receivewal 的压缩选项。自 cada1af 起，pg_receivewal 包含了 --compress 选项，允许使用 gzip 压缩 WAL 段，值为 0（默认）表示不压缩。此提交引入了一个新选项 --compression-method，其值可以为“none”（默认）和“gzip”，以使事情更具扩展性。--compress=0 的情况与此选项层变得模糊，因此我们选择使 pg_receivewal 在使用“none”且压缩级别非零时返回错误，这意味着 --compress 的授权值现在是 [1,9] 而不是 [0,9]。未指定 --compress 和“gzip”作为压缩方法，pg_receivewal 会使用 zlib 的默认值（Z_DEFAULT_COMPRESSION）。负责在扫描现有归档时查找流式启动 LSN 的代码被重构并使其更具扩展性。同时，在 walmethods.c 中将“compression”重命名为“compression_level”，以减少与引入压缩方法混淆，即使 pg_basebackup 使用的 tar 方法不依赖于压缩方法（至少目前还不是），而仅仅依赖于压缩级别（实际上，这个区域可以进一步改进）。这是为即将发布的添加 LZ4 支持到 pg_receivewal 的补丁做准备。作者：Georgios Kokolatos 审阅者：Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar 讨论：https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/d62bcc8b07f921bad105c7a826702c117ea7be58

  • 修复 pg_receivewal --compression-method 的一些错误。选项名称在一个错误消息中不正确，并且代码中使用了短选项 'I'，但我们不打算这样。同时，修复文档以引用“方法”，而不是“级别”。提交 d62bcc8 中的疏忽，我在进一步审查 pg_receivewal 的 LZ4 补丁后检测到。 https://git.postgresql.org/pg/commitdiff/9588622945754305836555273a6a3be814db315c

  • 为 pg_receivewal 添加 LZ4 压缩支持。pg_receivewal 获得了一个新选项 --compression-method=lz4，当代码使用 --with-lz4 编译时可用。与 gzip 类似，这提供了使用 LZ4 压缩归档 WAL 段的可能性。此选项与 --compress 不兼容。实现使用 LZ4 帧，并兼容简单的 lz4 命令。与 gzip 类似，使用 --synchronous 可以确保任何数据在当前 .partial 段内刷新到磁盘，从而尽可能多地检索 WAL 数据，即使是从未完成的段（这需要将部分文件填充零直到后端解压后支持的 WAL 段大小，但这与 gzip 相同）。计算流式启动 LSN 的代码能够透明地查找和检查 LZ4 压缩的段。与 gzip 不同，gzip 直接将未压缩的大小存储在读取的对象中，LZ4 块协议默认不存储未压缩的数据。there is contentSize，它可以通过 LZ4 帧使用，但这无助于使用包含默认压缩的“lz4”命令压缩的段的归档，其中此信息未存储。因此，此提交采取了最可扩展的方法，通过以 64kB 的块（没有注意到 8kB、16kB 或 32kB 的实际性能差异，并且操作本身实际上很快）为空输出缓冲区来解压缩已归档的段以检查其未压缩大小。已添加测试以验证生成的 LZ4 文件的创建和正确性。后者通过使用环境变量中的“lz4”命令来实现。walmethods.c 中的 tar-based WAL 方法（目前仅由 pg_basebackup 使用）尚不了解 LZ4。其代码可以扩展用于此目的。作者：Georgios Kokolatos 审阅者：Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar 讨论：https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/babbbb595d2322da095a1e6703171b3f1f2815cb

  • 改进 psql 的 tab 补全功能 for COMMENT。为更多对象类型添加了补全，例如 domain constraints、text search 相关对象或 policies。此外，该区域进行了重组，将 COMMENT 支持的对象列表的顺序更改为与文档一致，以便于将来的添加。作者：Ken Kato 审阅者：Fujii Masao, Shinya Kato, Suraj Khamkar, Michael Paquier 讨论：https://postgr.es/m/6e0c2f3f657b229bea32d098d118f307@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/a5b336b8b9e04a93e7c8526302504d2e5201eb80

Álvaro Herrera 提交

Daniel Gustafsson 提交

Amit Kapila 提交

Fujii Masao 提交

Peter Geoghegan 提交

Peter Eisentraut 提交

Heikki Linnakangas 提交

Robert Haas 提交

  • amcheck：添加额外的 TOAST 指针检查。扩展对 TOAST 属性的检查，以在原始大小过大时发出警告。对于压缩属性，如果压缩似乎扩大了属性或压缩方法无效，也应发出警告。Mark Dilger，审阅者 Justin Pryzby, Alexander Alekseev, Heikki Linnakangas, Greg Stark 和我。讨论：http://postgr.es/m/8E42250D-586A-4A27-B317-8B062C3816A8@enterprisedb.com https://git.postgresql.org/pg/commitdiff/bd807be6935929bdefe74d1258ca08048f0aafa3

  • 引入 'bbsink' 抽象以模块化基础备份代码。基础备份代码多年来积累了大量新功能，但由于没有真正分离关注点，维护和进一步增强这些代码变得越来越困难。例如，了解如何使用 libpq 协议将数据发送到客户端的代码分散在 basebackup.c 的各个部分，而不是集中在一个地方。为了试图改善这种情况，引入了一个新的 'bbsink' 对象，它充当基础备份过程中生成的归档的接收者，也充当备份清单的接收者。此提交引入了三种类型的 bbsink：'copytblspc' bbsink 通过每个表空间一次 COPY OUT 操作将备份转发到客户端，以及一个用于清单的；'progress' bbsink 执行命令进度报告；'throttle' bbsink 执行速率限制。'progress' 和 'throttle' bbsink 类型还将数据转发到后继的 bbsink；目前，链中的最后一个 bbsink 始终是 'copytblspc' 类型。计划在未来的提交中添加更多类型的 'bbsink'。此抽象在进度报告的情况下有点泄漏，但仍然比我们以前的更好。补丁由我编写，由 Andres Freund, Sumanta Mukherjee, Dilip Kumar, Suraj Kharage, Dipesh Pandit, Tushar Ahuja, Mark Dilger 和 Jeevan Ladhe 审阅和测试。讨论：https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com 讨论：https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/bef47ff85df18bf4a3a9b13bd2a54820e27f3614

  • 引入 'bbstreamer' 抽象以模块化 pg_basebackup。pg_basebackup 知道如何处理从服务器获取的备份的许多事情，例如直接写出文件，或先压缩它们，甚至解析 tar 格式并将修改后的 postgresql.auto.conf 文件注入服务器生成的归档中。不幸的是，这使得 pg_basebackup.c 成为一个非常大的源文件，并且也难以进行增强，因为例如，关于服务器正在向我们发送“tar”文件而不是其他类型归档的知识分布在各个地方，而不是集中在一个地方。为了改善这种情况，此提交发明了一个新的“bbstreamer”抽象。从服务器接收的每个归档都馈送给一个 bbstreamer，该 bbstreamer 可以选择处理它或将其传递给另一个 bbstreamer。数据块也可以根据它们是归档文件中文件的数据负载部分还是归档元数据部分被“标记”。因此，例如，如果我们想获取一个 tar 文件，修改其中包含的 postgresql.auto.conf 文件，然后将其 gzip 并写出，我们可以使用 bbstreamer_tar_parser 来解析从服务器接收到的 tar 文件，bbstreamer_recovery_injector 来修改 postgresql.auto.conf 的内容，bbstreamer_tar_archiver 来用新构建的、对于已修改文件正确的 tar 头替换前一步修改文件的 tar 头，以及 bbstreamer_gzip_writer 来 gzip 并写出结果数据。只有名称中包含“tar”的对象才知道 tar 归档格式，并且理论上如果我们想使用除“tar”以外的其他格式进行重新归档，我们可以这样做。这些更改确实增加了大量代码，但我认为结果更易于维护和扩展。pg_basebackup.c 本身缩小了大约三分之一，其中许多以前包含的复杂性都转移到了新添加的文件中。补丁由我编写。作为此部分的大型补丁系列，已由 Andres Freund, Sumanta Mukherjee, Dilip Kumar, Suraj Kharage, Dipesh Pandit, Tushar Ahuja, Mark Dilger, Sergei Kornilov 和 Jeevan Ladhe 在不同时间进行过审阅和测试。讨论：https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com 讨论：https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/23a1c6578c87fca0e361c4f5f9a07df5ae1f9858

  • 在不需要时不要设置 ThisTimeLineID。在 slotfuncs.c 中，pg_replication_slot_advance() 需要确定槽应推进到的 LSN，但这不需要更新 ThisTimeLineID，因为从这里调用的任何代码都不依赖于它。如果复制槽是逻辑的，pg_logical_replication_slot_advance 将调用 read_local_xlog_page，它确实会使用 ThisTimeLineID，但也会确保其是最新的。如果是物理复制槽，时间线根本不会被使用。在 logicalfuncs.c 中，pg_logical_slot_get_changes_guts() 存在同样的问题：我们唯一要运行的代码是 read_local_xlog_page 或其下游代码，后者已经确保设置了正确的值。因此，不要在这里执行。补丁由我编写，由 Michael Paquier, Amul Sul 和 Álvaro Herrera 审阅和测试。讨论：https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/caf1f675b88d1aa67ea3fb642e8f38b470cc911e

  • 移除 xlog.c 之外对 ThisTimeLineID 全局变量的所有使用。所有此类代码都以三种方式之一处理此全局变量。有时，同一函数在同一时间以多种方式使用它。首先，有时它是 xlog.c 或其他地方调用的一个或多个函数的隐式参数，并且必须在调用这些函数之前设置为适当的值，以免它们出错。在那些情况下，现在将它显式传递作为参数。其次，有时在恢复结束后用于获取当前时间线，即正在写入和刷新 WAL 的时间线。此类代码现在调用 GetWALInsertionTimeLine() 或依赖于添加到 GetFlushRecPtr() 的新的输出参数。第三，有时在恢复期间用于存储当前重放时间线。这可能会发生变化，因此此类代码通常必须在每次使用之前更新该值。它们仍然可以这样做，但现在必须使用局部变量。这些更改的净效应是直接访问此全局变量的代码量大幅减少。这是好事，因为历史表明，我们并不总是清楚在任何给定时间点它应该包含哪个时间线 ID，甚至在代码的任何给定点是否已经或需要初始化它。补丁由我编写，由 Michael Paquier, Amul Sul 和 Álvaro Herrera 审阅和测试。讨论：https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e997a0c642860a96df0151cbeccfecbdf0450d08

  • 将 ThisTimeLineID 从全局变量更改为局部变量。StartupXLOG() 仍然将 ThisTimeLineID 作为局部变量，但 xlog.c 中剩余的代码现在需要通过其他方式获取相关 TimeLineID。大多数情况下，这意味着现在将它作为函数参数传递给许多以前没有的函数。然而，少数情况需要特殊处理：- 在可能被外部调用者调用而不知道要指定哪个时间线的函数中，我们从共享内存中获取时间线 ID。在大多数情况下可以使用 XLogCtl->ThisTimeLineID，因为可以假定在调用这些函数之前恢复已经完成。在 xlog_redo() 中，我们可以使用 XLogCtl->replayEndTLI。- XLogFileClose() 需要知道打开的日志文件的 TLI。通过一个新的全局变量 openLogTLI 来实现。虽然有人可能认为这只是用另一个全局变量替换了一个全局变量，但新的变量的用途要窄得多，并且只在少数几个地方被引用。- read_backup_label() 现在返回通过解析 backup_label 文件获得的 TLI。以前，可以调用 ReadRecord() 来解析检查点记录，而 ThisTimeLineID 尚未初始化。现在，时间线会传递下去，而我不想传递未初始化的变量；这个更改可以避免这种情况。旧代码似乎没有任何实际后果需要我们担心，但这样更清晰。- 在 BootstrapXLOG() 中，它只是一个常量。补丁由我编写，由 Michael Paquier, Amul Sul 和 Álvaro Herrera 审阅和测试。讨论：https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4a92a1c3d1c361ffb031ed05bf65b801241d7cdd

  • 删除由 bd807be6935929bdefe74d1258ca08048f0aafa3 添加的测试。Buildfarm 对此不满意。不清楚它为什么不喜欢这些测试，但让我们在弄清楚之前删除它们。讨论：http://postgr.es/m/462618.1636171009@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ccf289745d3e50360653181dce6a277a1fc79730

Tomáš Vondra 提交了

Alexander Korotkov 提交了

Andres Freund 提交