pg_extension_updater

Overview

Optional packaged component. It runs installed extension updates at database start through pg_extension_base; it is not part of CREATE EXTENSION pg_lake CASCADE dependency closure. Extension SQL/control version is 3.4; source and DEB/RPM package version is 3.4.0.

Version

Build

You can build the RPM / DEB packages for pg_lake using pig build:

pig build pkg pg_lake         # build RPM / DEB packages

Install

You can install pg_lake directly. First, make sure the PGDG and PIGSTY repositories are added and enabled:

pig repo add pgsql -u          # Add repo and update cache

Install the extension using pig or apt/yum/dnf:

• Install
• pig
• dnf
• apt

pig install pg_lake;          # Install for current active PG version

pig ext install -y pg_lake -v 18  # PG 18
pig ext install -y pg_lake -v 17  # PG 17
pig ext install -y pg_lake -v 16  # PG 16

dnf install -y pg_lake_18       # PG 18
dnf install -y pg_lake_17       # PG 17
dnf install -y pg_lake_16       # PG 16

apt install -y postgresql-18-pg-lake   # PG 18
apt install -y postgresql-17-pg-lake   # PG 17
apt install -y postgresql-16-pg-lake   # PG 16

Preload:

shared_preload_libraries = 'pg_extension_base';

Create Extension:

CREATE EXTENSION pg_extension_updater CASCADE;  -- requires: pg_extension_base

Usage

Sources:

• Official pg_extension_updater README
• Version 3.4 control file
• Worker registration SQL
• Updater implementation and configuration
• pg_extension_base preload documentation

pg_extension_updater runs ALTER EXTENSION ... UPDATE for each extension whose installed version differs from its available default version when the database lifecycle worker starts. It is intended to reduce SQL/binary version mismatches after new extension files are deployed; it does not install missing extensions or replace release testing.

Enable Automatic Updates

The updater depends on pg_extension_base, which must be preloaded cluster-wide:

shared_preload_libraries = 'pg_extension_base'

After restarting PostgreSQL, create the updater in every database where automatic updates are desired:

CREATE EXTENSION pg_extension_updater CASCADE;

Creating it in template1 causes new databases cloned from that template to contain the updater. The worker does not update extensions inside the template database itself, but starts in a newly cloned database.

Runtime Behavior

• The #!shared_preload_libraries directive in the updater’s control file lets pg_extension_base load its library.
• Installation registers the internal extension_updater.main(internal) lifecycle worker.
• At worker startup, it reads pg_available_extensions and updates entries whose installed_version differs from default_version.
• A failed ALTER EXTENSION is logged as a warning and is attempted only once during that worker run.
• pg_extension_updater.enable is a postmaster setting, defaults to on, and disables the worker’s updates when set to off; changing it requires a restart.

Caveats

• Automatic migration can execute arbitrary upgrade SQL supplied by every installed extension. Validate packages and upgrade paths before enabling it on production databases.
• Review extension dependency changes and take application-specific backups independently; a warning does not roll back unrelated successful extension updates.
• There is no user-facing force-update function or per-extension allowlist in version 3.4.
• Version 3.4 changes no updater SQL API relative to 3.3.