output_plugin_libraries

Definition PG 18 manual

Lists the libraries installed in dynamic_library_path that are also trusted for use as logical output plugins by replication clients. Any logical decoding or replication requests for other libraries will be refused. All users are subject to this restriction. The default is 'pgoutput, test_decoding', which are the two logical output plugins included in the standard PostgreSQL distribution.

The format is a comma-separated list of library names, where each name is interpreted as for the LOAD command (but logical decoding clients must specify a plugin name that exactly matches an entry in the list, without variations in case or path structure). Whitespace between entries is ignored; surround a library name with double quotes if you need to include whitespace or commas in the name.

It is the responsibility of the server administrator to ensure that libraries added to this list do not unintentionally give additional privileges to non-superusers when they are loaded into the server.

SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;

ERROR:  library "..." may not be used as an output plugin
DETAIL:  The configuration parameter "output_plugin_libraries" (currently 'pgoutput, test_decoding') does not name this library as a trusted output plugin.
HINT:  If it is safe for all REPLICATION users to use this library as an output plugin, add it to "output_plugin_libraries" and reload the server configuration.

How it works

Lists libraries that may be named as logical decoding output plugins. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

Logical decoding accepts only output-plugin library names on this server-side allowlist, using LOAD-style naming with an exact plugin-name match. Adding a library is a trust decision because plugin code executes inside the server process.

Monitor and change output_plugin_libraries together with wal_level, max_wal_senders, max_replication_slots. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

Workload guidance

OLAP: ETL decoding plugins are still in-process code; do not use broad paths for convenience. Test large-transaction memory, WAL retention, and plugin output.

OLTP: List only installed, audited output plugins with a real consumer. Test with a least-privilege replication role and include plugin upgrades in the server release process.

SMALL: Keep the small built-in allowlist without logical decoding. Before adding wal2json or another plugin, establish package provenance, version compatibility, and maintenance ownership.