output_plugin_libraries
Fact — official short description: “Lists libraries that may be named as logical decoding output plugins.”
Identity
Lifecycle
| Fact | Value |
|---|---|
| First observed | PG14 |
| Present in | PG14–19 Beta 3 |
| Removed in | No |
| Introduction commit | bf3842a64f5d — Add an output_plugin_libraries GUC to bless trusted output plugins |
| Commit date | 2026-08-10 |
| Discussion | — |
Default history
| Versions | Raw boot_val |
Unit | Human value |
|---|---|---|---|
| PG14–19 Beta 3 | pgoutput, test_decoding |
— | pgoutput, test_decoding |
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.
Tuning advice
Advice. These are workload-specific starting points and must be validated with measurements.
| Workload | Guidance |
|---|---|
| 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. |
| 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. |
| Small nodes | Keep the small built-in allowlist without logical decoding. Before adding wal2json or another plugin, establish package provenance, version compatibility, and maintenance ownership. |
Pigsty
Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.
| Template | Effective value | Versus upstream boot | Source expression |
|---|---|---|---|
| OLTP | pgoutput, test_decoding, wal2json |
different | 'pgoutput, test_decoding, wal2json' |
| OLAP | pgoutput, test_decoding, wal2json |
different | 'pgoutput, test_decoding, wal2json' |
| CRIT | pgoutput, test_decoding, wal2json |
different | 'pgoutput, test_decoding, wal2json' |
| TINY | pgoutput, test_decoding, wal2json |
different | 'pgoutput, test_decoding, wal2json' |
Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs); OLAP: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs); CRIT: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs); TINY: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs). Advice, pending human review — Editorial interpretation, pending human maintainer review: the override appears intended to make wal2json available while preserving a narrow explicit output-plugin allowlist; confirm it against the current Pigsty templates, hardware fixture, and operational guarantees before publication.
Common pitfalls
- 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.
Related parameters
wal_level · max_wal_senders · max_replication_slots · archive_mode · wal_log_hints · shared_preload_libraries
References
- PostgreSQL 19 Beta 3 — output_plugin_libraries
- PostgreSQL 19 release notes
- Machine-readable GUC export