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

发布于 2021-11-08,作者:PWN
PWN

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

PG Build 2021 将于 2021 年 11 月 30 日和 12 月 1 日格林威治标准时间 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 为您带来

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

已应用的补丁

Tom Lane 推送了

Michaël Paquier 推送了

  • 在 REINDEX CONCURRENTLY 中保留操作符类参数。旧索引的操作符类参数 Datums 通过直接从系统目录中获取的方式,与谓词和表达式相同。然后将它们复制到新 IndexInfo 中,该新 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 的情况变得模糊,因此我们选择在使用“none”和非零压缩级别时使 pg_receivewal 返回错误,这意味着 --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、Robert Haas 讨论: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 压缩的支持。当使用 --with-lz4 编译代码时,pg_receivewal 会获得一个新选项 --compression-method=lz4。与 gzip 类似,这提供了使用 LZ4 压缩存档 WAL 段的可能性。此选项与 --compress 不兼容。该实现使用 LZ4 帧,并且与简单的 lz4 命令兼容。与 gzip 类似,使用 --synchronous 可确保将任何数据刷新到当前 .partial 段内的磁盘,以便即使从未完成的段中也可以检索尽可能多的 WAL 数据(这需要在解压缩后使用零填充部分文件,直到后端支持的 WAL 段大小,但这与 gzip 相同)。流式启动 LSN 的计算能够透明地查找和检查 LZ4 压缩段。与 gzip 不同,gzip 的未压缩大小直接存储在读取的对象中,而 LZ4 块协议默认情况下不存储未压缩的数据。可以使用带有 LZ4 帧的 contentSize,但这对于使用包含使用“lz4”命令默认值压缩的段的存档没有帮助,因为此处没有存储。因此,此提交采用了最可扩展的方法,通过分块解压缩已存档的段,以 64kB 的空白输出缓冲区来检查其未压缩的大小(在 8kB、16kB 或 32kB 中没有注意到实际的性能差异,并且操作本身实际上很快)。已添加测试来验证生成的 LZ4 文件的创建和正确性。后者是通过使用环境中的命令“lz4”(如果找到)来实现的。walmethods.c 中基于 tar 的 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 对 COMMENT 的制表符补全。为更多对象类型添加了补全,例如域约束、文本搜索对象或策略。此外,该区域被重新组织,将 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 推送

藤井雅雄推送

Peter Geoghegan 推送

Peter Eisentraut 推送

Heikki Linnakangas 推送

Robert Haas 推送

  • amcheck:添加额外的 TOAST 指针检查。扩展对 toasted 属性的检查,如果 rawsize 过大则发出警告。对于压缩属性,如果压缩似乎扩大了属性或压缩方法无效,也发出警告。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 标头,使用新构建的标头,这些标头对于修改后的文件是正确的,以及使用 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() 的新 out 参数。第三,有时它在恢复期间用于存储当前的重放时间线。这可能会发生变化,因此此类代码通常必须在每次使用前更新该值。它仍然可以这样做,但现在必须使用局部变量代替。这些更改的净效应是减少了直接访问此全局变量的代码量。这很好,因为历史表明,我们并不总是清楚地了解它在任何给定时间点应该包含哪个时间线 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 中的其余代码现在需要通过其他方式获取相关的时间线 ID。大多数情况下,这意味着我们现在将其作为函数参数传递给之前没有传递的一些函数。但是,少数情况需要特殊处理:- 对于可能被外部调用者调用的函数,这些调用者不一定知道要指定哪个时间线,我们从共享内存中获取时间线 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 添加的测试。构建场不高兴。目前还不清楚它为什么不喜欢这些测试,但在我们弄清楚之前,我们先删除它们。讨论:http://postgr.es/m/462618.1636171009@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ccf289745d3e50360653181dce6a277a1fc79730

Tomáš Vondra 推送

Alexander Korotkov 推送了

Andres Freund 推送了