Muhammad Aqeel：PostgreSQL 18的extension_control_path：将扩展与服务器镜像解耦
内容提要
PostgreSQL 18新增`extension_control_path`，允许扩展文件存放于服务器目录外，配合Kubernetes ImageVolume或Docker挂载，可将扩展打包为独立OCI镜像。此模式对按需加载的扩展（如pgvector、PostGIS）效果最佳，支持热挂载和独立版本管理；但对钩子、后台进程或深度集成扩展（如pgaudit、spock），仍需重启或受限于服务器配置，收益有限。
延伸解读
适用场景：按需加载的扩展收益最大
文章指出，extension_control_path 与容器镜像结合，最适合像 pgvector、PostGIS 这类按需加载的扩展。它们仅在客户端执行 CREATE EXTENSION 时才被加载，不参与服务器启动过程，因此可以热挂载、热卸载，无需重启。这种模式能实现扩展的独立版本管理，更新扩展镜像不影响服务器镜像，尤其适合多集群场景。
限制：钩子与后台进程扩展仍需重启
对于依赖 shared_preload_libraries 的扩展（如 pgaudit、pg_cron），虽然文件可以放在容器中，但添加或移除扩展仍需重启服务器。容器模式仅带来版本管理的独立性，无法实现热附加。因此，这类扩展的收益有限，需要权衡额外镜像管理的复杂度。
深度集成扩展：文件位置并非关键
像 spock、Citus 这类深度集成扩展，其耦合点在于共享内存、WAL 级别、后台进程等服务器级配置，而非文件位置。即使使用 extension_control_path，也无法避免重启或配置变更。容器模式的价值仅限于独立版本升级和保持服务器镜像精简，不能解决核心的耦合问题。
Q&A
PostgreSQL 18 新增的 extension_control_path 有什么作用？
extension_control_path 是 PostgreSQL 18 新增的 GUC，它允许扩展的控制文件（.control）和 SQL 脚本存放在服务器目录之外，与 dynamic_library_path 配合，可以将整个扩展（包括共享库、控制文件、SQL 脚本）打包成独立的 OCI 镜像，并在运行时挂载到 PostgreSQL 容器中，无需重建服务器镜像。
extension_control_path 和 dynamic_library_path 有什么区别？
dynamic_library_path 用于指定共享库（.so 文件）的搜索路径，而 extension_control_path 用于指定扩展控制文件（.control）和 SQL 脚本的搜索路径。在 PostgreSQL 18 之前，控制文件必须放在 $sharedir/extension/ 目录下，无法覆盖；extension_control_path 填补了这一空白，使得扩展可以完全独立于服务器安装目录。
使用 extension_control_path 时，为什么必须包含 $system 占位符？
$system 占位符解析为编译时的 sharedir 路径（由 pg_config --sharedir 返回）。如果 extension_control_path 中不包含 $system，服务器将无法找到内置扩展（如 plpgsql）的控制文件，导致这些扩展不可用。
哪些类型的扩展最适合使用容器镜像方式部署？
按需加载的扩展最适合，例如 pgvector、PostGIS 和 pg_partman（SQL-only 模式）。这些扩展在客户端执行 CREATE EXTENSION 时才被加载，不涉及 shared_preload_libraries、后台进程或服务器级 GUC 更改，因此可以热挂载和卸载，无需重启服务器。
对于钩子类扩展（如 pgaudit），使用容器镜像部署有什么优缺点？
优点是可以独立版本管理，无需重建服务器镜像；缺点是必须通过 shared_preload_libraries 在服务器启动时加载，因此添加或移除扩展需要重启服务器，无法实现热挂载。
系统集成类扩展（如 spock）为什么即使使用 extension_control_path 也无法热挂载？
因为这类扩展与服务器的耦合很深，需要共享内存分配、特定的 WAL 级别（如 wal_level=logical）、track_commit_timestamp 等服务器级配置，这些配置必须在启动时确定，无法动态更改。此外，它们还涉及后台进程和复制槽等，这些都不是文件位置能解决的。
如何在 Kubernetes 中使用 ImageVolume 挂载扩展镜像？
在 Kubernetes 1.33 及更高版本中，ImageVolume 功能（1.36 起 GA）允许将 OCI 镜像直接挂载到 Pod 中。配置扩展的 metadata.hcl 描述符，CloudNativePG 会自动注入 LD_LIBRARY_PATH 等环境变量，并将镜像挂载到指定路径，从而无需重建服务器镜像即可使用扩展。
