On August 13, 2026 the PostgreSQL Global Development Group released 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3. If you run logical replication, manage pg_upgrade plans, or operate in FIPS-enforced environments, this is not a routine minor release — two of the security fixes change runtime behavior in ways that can break production after the upgrade. Here is the ops checklist you need before you patch.

What changed in the August security releases

The headline for architects and DBAs is output_plugin_libraries, a new server parameter that locks down logical decoding output plugins (CVE-2026-6471). Previously any replication user could request any loadable library during logical decoding, which opened the door to exploits. The fix whitelists the plugins a server will honor. The default is now only the two plugins shipped with PostgreSQL:

output_plugin_libraries = 'pgoutput, test_decoding'

If you rely on third-party logical decoding plugins — wal2json, decoderbufs, or a custom plugin — they will be refused after upgrade until you add them to the list. This is a configuration adjustment, not a dump/restore event, but it will surface as replication failures if you miss it.

Before you patch: audit your logical slots

The official documentation includes a query that builds the exact list your persistent slots need. Run it on each source cluster before upgrading:

SELECT DISTINCT plugin
FROM pg_replication_slots
WHERE plugin IS NOT NULL;

Review the output carefully, then set the parameter via ALTER SYSTEM or directly in postgresql.conf:

ALTER SYSTEM SET output_plugin_libraries =
  'pgoutput, test_decoding, wal2json';
-- restart or reload, then confirm:
SHOW output_plugin_libraries;

One more trap: pg_upgrade --check will now fail when migrating from 17 or later if the new cluster’s output_plugin_libraries does not permit the plugins referenced by existing logical slots on the old cluster. Add the setting to the new cluster before running pg_upgrade, or your upgrade check stops cold with a misleading error.

pgcrypto in FIPS mode: decrypt calls may now fail

The second behavior change (CVE-2026-14663) fixes contrib/pgcrypto silently failing to detect unsupported ciphers. When OpenSSL rejected a cipher — common under FIPS mode or when the legacy provider is not loaded — pgcrypto previously XOR'd the unencrypted block with the plaintext, producing "encryption" that was trivially breakable. Affected algorithms are the deprecated non-FIPS set: Blowfish, Twofish, CAST5, and 3DES.

After this patch, pgp_pub_decrypt() and pgp_sym_decrypt() will by default fail on messages encrypted with those ciphers. That is correct security behavior — but it means legitimate reads break until you remediate. To recover data written before the fix, the new ignore-cipher-failure option strips the faulty wrapper so you can re-encrypt with a modern algorithm:

SELECT pgp_sym_decrypt(encrypted_column, key,
       'ignore-cipher-failure=1')
FROM legacy_pgp_table;

Plan a two-step migration: use the option to extract and re-encrypt affected rows with AES, then remove the option so future decrypts fail loudly instead of silently producing garbage.

Reindex GIN, btree_gist, and ltree indexes

Two additional maintenance notes apply to 18.6 specifically. First, a changelog entry warns of possibly-corrupt reltuples values for tables with GIN indexes — plan a REINDEX pass on GIN indexes after patching. Second, if you use contrib/btree_gist or contrib/ltree, indexes built with those extensions may need reindexing. A targeted maintenance window beats discovering planner misbehavior at 2 a.m.:

REINDEX INDEX CONCURRENTLY idx_documents_gin;
REINDEX INDEX CONCURRENTLY idx_path_ltree;

Note that 18.5 was never released — a regression discovered post-wrap skipped that minor version — so 18.4 to 18.6 is a bigger jump in fixes than usual. If you are still on 18.1 or earlier, review the migration notes in the 18.6 release notes before jumping.

Fresh for ops: official RPMs on Amazon Linux 2023

For Houston shops running self-managed PostgreSQL on AWS, the PostgreSQL RPM repository now supports Amazon Linux 2023 — no more building from source or depending on third-party rebuilds when you want the official packages on EC2. Combine that with the 18.6 rollout and you have a clean path: standardize on AL2023 images, pull 18.6 from the official repo, run the logical-slot audit above, and reindex GIN/btree_gist/ltree indexes in the same change window.

Ops checklist summary

Before you patch any 18.x or 17.x cluster to the August releases:

1. Query pg_replication_slots and set output_plugin_libraries to include every plugin in use.
2. For 17+ to 18.6 upgrades, configure the parameter on the new cluster before pg_upgrade --check.
3. If you use pgcrypto PGP with Blowfish/Twofish/CAST5/3DES, test decrypt paths; add ignore-cipher-failure only for remediation, then re-encrypt.
4. Schedule REINDEX CONCURRENTLY for GIN, btree_gist, and ltree indexes.
5. Validate logical replication slots and consumer lag after restart, not just server uptime.

The August release wave is a reminder that "minor version" can still mean operational change. Patch deliberately: audit first, configure the new parameter, then roll. Your replicas — and your auditors — will thank you.