PostgreSQL 18 preview - 新增GUC: extension_control_path 指定插件位置

PostgreSQL 18 preview - 新增GUC: extension_control_path 指定插件位置

如果我们使用容器来启动PG, 通常会把PG的软件安装在容器镜像内, 但是PG是扩展能力极强的数据库, 市面上可能有上千个PG的插件, 通常也会把常用的插件一同安装到容器镜像内.

那么问题来了, 如果将来插件升级了, 或者要使用新的插件, 就需要更新镜像, 比较麻烦.

为了解决这个问题, PG引入了extension_control_path 参数, 可以指定插件控制文件路径, 从其他地方(例如容器外面)加载插件. 把插件二进制和LIB作为一个有状态软件来看待, 确实方便一些.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4f7f7b0375854e2f89876473405a8f21c95012af

extension_control_path  

The new GUC extension_control_path specifies a path to look for
extension control files.  The default value is $system, which looks in
the compiled-in location, as before.  

The path search uses the same code and works in the same way as  
dynamic_library_path.  

Some use cases of this are: (1) testing extensions during package  
builds, (2) installing extensions outside security-restricted  
containers like Python.app (on macOS), (3) adding extensions to  
PostgreSQL running in a Kubernetes environment using operators such as  
CloudNativePG without having to rebuild the base image for each new  
extension.  

There is also a tweak in Makefile.global so that it is possible to  
install extensions using PGXS into an different directory than the  
default, using 'make install prefix=/else/where'.  This previously  
only worked when specifying the subdirectories, like 'make install  
datadir=/else/where/share pkglibdir=/else/where/lib', for purely  
implementation reasons.  (Of course, without the path feature,  
installing elsewhere was rarely useful.)  

Author: Peter Eisentraut <[email protected]>  
Co-authored-by: Matheus Alcantara <[email protected]>  
Reviewed-by: David E. Wheeler <[email protected]>  
Reviewed-by: Gabriele Bartolini <[email protected]>  
Reviewed-by: Marco Nenciarini <[email protected]>  
Reviewed-by: Niccolò Fei <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]  

AI 解读

好的，我来详细解读这个 PostgreSQL 的 patch，关于 extension_control_path。

核心内容：引入新的 GUC 参数 extension_control_path，允许指定扩展控制文件（extension control files）的查找路径。

详细解读：

• extension_control_path 是什么？

• 这是一个新的 GUC (Grand Unified Configuration) 参数，也就是 PostgreSQL 的配置参数。
• 它的作用是指定 PostgreSQL 在哪里查找扩展控制文件。
• 扩展控制文件（通常以 .control 结尾）包含了扩展的元数据，例如扩展的名称、版本、依赖关系等。PostgreSQL 使用这些文件来加载和管理扩展。

• 默认值：$system

• 默认情况下，extension_control_path 的值为 $system。
• $system 表示使用编译时指定的默认位置，也就是 PostgreSQL 源代码中硬编码的路径。  这意味着，在没有设置 extension_control_path 的情况下，PostgreSQL 的行为与之前完全相同。

• 查找路径机制：

• extension_control_path 的查找路径机制与 dynamic_library_path 类似。
• 这意味着你可以指定多个路径，PostgreSQL 会按照指定的顺序在这些路径中查找扩展控制文件。
• 路径之间通常使用冒号 (:) 分隔（类似于 Linux/Unix 环境变量 PATH）。

• 解决的问题和用例：

• 测试扩展： 在软件包构建过程中，可以方便地指定一个临时的路径来查找正在测试的扩展控制文件，而无需将扩展安装到系统默认位置。
• 安全限制环境： 在某些安全限制的环境中（例如 macOS 上的 Python.app），可能无法将扩展安装到系统默认位置。extension_control_path 允许将扩展安装到其他位置，并让 PostgreSQL 找到它们。
• Kubernetes 环境： 在 Kubernetes 环境中使用 CloudNativePG 等 operator 部署 PostgreSQL 时，通常不希望每次添加新的扩展都重新构建基础镜像。extension_control_path 允许将扩展安装到持久卷或其他共享位置，而无需修改镜像。

• Makefile.global 的修改：

• 该 patch 还修改了 Makefile.global 文件，使得使用 PGXS (PostgreSQL Extension Build System) 安装扩展时，可以使用 make install prefix=/else/where 来指定安装目录。
• 以前，这种方式只有在同时指定 datadir 和 pkglibdir 等子目录时才有效。
• 现在，即使只指定 prefix，也可以将扩展安装到非默认位置。
• 重要性： 即使有了 extension_control_path，也需要能够将扩展安装到非默认位置才能发挥作用。Makefile.global 的修改使得安装过程更加灵活。

• 作者和评审：

• 作者是 Peter Eisentraut。
• Co-authored-by: Matheus Alcantara
• 经过了多位 PostgreSQL 社区成员的评审，包括 David E. Wheeler, Gabriele Bartolini, Marco Nenciarini, 和 Niccolò Fei。

总结：

这个 patch 引入了一个重要的功能，允许 PostgreSQL 管理员更灵活地控制扩展控制文件的查找路径。  这解决了在各种部署场景中安装和管理扩展的难题，尤其是在容器化和安全限制的环境中。  extension_control_path 配合 Makefile.global 的修改，使得扩展的安装和部署更加方便和可配置。  这个 patch 增强了 PostgreSQL 的可扩展性和适应性。