The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 18.6, 17.11, 16.15, 15.19, and 14.24, as well as the third beta release of PostgreSQL 19. This release fixes 28 security vulnerabilities and over 110 bugs reported over the last several months.

This release skips PostgreSQL 18 versions from PostgreSQL 18.4 to 18.6. 18.5 was not shipped due to a regression.

There are three issues that may require you to take extra steps after updating, which are described in detail below. These issues are related to:

• Parallel GIN index builds
• btree_gist
• ltree

For the full list of changes, please review the release notes.

PostgreSQL 14 EOL Notice

PostgreSQL 14 will stop receiving fixes on November 12, 2026. If you are running PostgreSQL 14 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our versioning policy for more information.

Security Issues

The following security vulnerabilities are closed across in this update release. You can find more details about the vulnerabilities and their affected versions in the links below:

• CVE-2026-6464: psql COPY FROM STDIN early failure processes data lines as psql commands (CVSS v3.1: 8.1)
• CVE-2026-6469: ALTER TABLE ALTER TYPE resets extended statistics ownership (CVSS v3.1: 3.8)
• CVE-2026-6470: Fails to check type USAGE privilege (CVSS v3.1: 4.3)
• CVE-2026-6471: Logical decoding can dlopen arbitrary file (CVSS v3.1: 7.2)
• CVE-2026-14662: tsvector and tsquery undersize allocations, via integer wraparound (CVSS v3.1: 8.8)
• CVE-2026-14663: pgcrypto, for OpenSSL-disabled ciphers, silently encrypts to and decrypts from cleartext (CVSS v3.1: 6.5)
• CVE-2026-14664: Regexp heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14666: Row security caching disregards role modifications (CVSS v3.1: 4.2)
• CVE-2026-14668: ctid type confusion in selectivity estimator discloses derivative of arbitrary read (CVSS v3.1: 8.1)
• CVE-2026-14669: to_char heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14670: plperl tied object heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14671: refint plan cache type confusion executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14672: Observable response discrepancy with non-default scram_iterations provides user existence oracle (CVSS v3.1: 5.3)
• CVE-2026-14673: amcheck does not clear untrusted search path (CVSS v3.1: 3.8)
• CVE-2026-14676: pg_stat_statements heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14677: 32-bit pltcl and plperl undersize allocations, via integer wraparound (CVSS v3.1: 8.8)
• CVE-2026-14678: pg_trgm picksplit reads past end of buffer (CVSS v3.1: 4.3)
• CVE-2026-14679: Stack buffer overflow in argument match writes 0x0 and 0x1 to server memory (CVSS v3.1: 8.2)
• CVE-2026-14680: Type confusion via "internal" arguments (CVSS v3.1: 8.8)
• CVE-2026-14681: Improper enforcement of GSSAPI encryption when coupled with SSL (CVSS v3.1: 4.2)
• CVE-2026-15741: Expression deparse allows SQL injection via EXTRACT argument (CVSS v3.1: 8.8)
• CVE-2026-15742: fuzzystrmatch writes effectively-arbitrary addresses, via integer wraparound (CVSS v3.1: 8.8)
• CVE-2026-16238: Type confusion in pg_restore_attribute_stats() executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-16239: Type confusion in cursor CLOSE + DECLARE executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-16241: ECPG integer underflow can crash the client (CVSS v3.1: 3.8)
• CVE-2026-18024: ascii() function reads past end of buffer (CVSS v3.1: 4.3)
• CVE-2026-18408: psql \unrestrict lets superuser of pg_dump origin server execute arbitrary code in psql client (CVSS v3.1: 8.8)
• CVE-2026-19385: pg_dump heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)

Bug Fixes and Improvements

This update fixes over 110 bugs that were reported in the last several months.

This specific issue only affects PostgreSQL 14, 15, and 16, but we're highlighting it in the release announcement due to its severity:

• Fix a self-deadlock that could occur while replaying WAL generated by an older minor version. This regression, introduced in the previous set of minor releases, could cause a standby server following a primary running an older minor version to become stuck.

The remainder of issues listed below affect PostgreSQL 18. Many of these issues also affect other supported versions of PostgreSQL.

• Fix parallel GIN index builds to correctly update the table's reltuples value in pg_class. Previously, a parallel worker could report an uninitialized row count, leaving reltuples set to a bogus value (including Infinity or NaN). Such a value can cause autovacuum and autoanalyze to not process the table, and this situation will not self-correct. If you have any tables with GIN indexes, we recommend checking that their reltuples values look reasonable after updating. See the "Updating" section for how to identify and repair affected tables.
• Several fixes to btree_gist, including for NaN handling for float4/float8 that could give wrong answers for columns containing NaN and correct sorting of bit/bit varying values during index building. You may need to reindex btree_gist indexes on float or bit columns after updating. See the "Updating" section.
• Fix an integer overflow in ltree comparisons. ltree values containing more than about 14,653 labels could compare incorrectly, which could present as a corrupt B-tree index. If you use ltree, you may need to reindex affected indexes after updating. See the "Updating" section.
• Fix partition pruning for RANGE-partitioned tables so the DEFAULT partition is no longer skipped in cases where it should be scanned. Previously this could cause rows to be missing from query results.
• Several fixes for partitioned tables that have foreign-table partitions, including when run-time partition pruning determined that some partitions don't need to be scanned, in-flight requests to foreign servers were not always handled correctly, leading to failures.
• Several fixes to RETURNING with OLD and NEW.
• Improve hash join performance when there are multiple join keys and many NULL values.
• Several fixes to the planner that could produce wrong query results, including value IN (array) tests where the array might be empty, and COUNT() window functions that use an EXCLUDE clause or lack ORDER BY.
• Add missing checks for the hashability of equality comparisons on container types (arrays, composite types, and ranges). Without these checks, the planner could choose a hash-based plan that then failed at execution with a "could not identify a hash function" error.
• Fix attaching partitions of indexes that are exclusion constraints, which also fixes dump/restore of partitioned exclusion constraints.
• Fix REINDEX CONCURRENTLY on an index backing a deferred uniqueness constraint, which could cause false constraint-violation reports.
• Restore an index-scan optimization that converts a LIKE or regular-expression exact-match pattern into an equality index condition when the index and expression collations differ.
• Several fixes to jsonpath, including that the @? and @@ operators now correctly raise an error for an undefined variable in the path expression. Previously, because these operators cannot supply variable values, an undefined variable was treated as a JSON null rather than an error, which could also lead to unbounded memory consumption.
• Ensure access is blocked to other sessions' temporary tables, which could lead to silently incorrect results.
• Fix "no empty local buffer available" errors during temporary table access when a large effective_io_concurrency setting could allow a single read stream to consume all local buffers.
• Prevent autovacuum from processing databases in the wrong order (lowest-priority first instead of highest).
• Restore VACUUM's wraparound failsafe mode to use the full shared buffer pool as intended, which had slowed down emergency vacuuming.
• Fix possible incorrect decoding of index tuples during GiST and SP-GiST index-only scans, which could emit corrupted data.
• Fix a race condition in conflict detection under SERIALIZABLE isolation. A conflict could be missed when examining an initially-empty btree index, allowing conflicting transactions to commit and breaking serializability.
• Fix WAL logging of operations that clear bits in table visibility maps. This could lead to producing incorrect incremental backups or potentially leaving torn-page writes uncorrected.
• Fix logical decoding of empty prepared transactions. A prepared transaction with no decodable changes could send COMMIT PREPARED or ROLLBACK PREPARED to the output plugin with no preceding PREPARE, which breaks replication for the built-in subscriber.
• Several fixes to libpq, including ensuring it drains all pending bytes from the SSL or GSS decryption buffer when reading data, avoiding cases where a client waits for data that has already arrived.
• Fix pg_createsubscriber to clean up objects left on a publisher after failure, including a replication slot.
• Fix pg_restore with --statistics or --statistics-only so that, when combined with other selective-restore options such as --schema, it restores the expected items, matching the behavior of pg_dump.

This release also updates time zone data files to tzdata release 2026c, in which Alberta (America/Edmonton) will be on year-round UTC-06 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be CST from that time forward (though this could change). It also reflects that Morocco (Africa/Casablanca) will move to permanent UTC+00, without daylight saving transitions, on September 20, 2026.

Updating

All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply stop PostgreSQL and update its binaries.

If you have any tables with GIN indexes, we recommend checking their reltuples values after updating. A prior bug in parallel GIN index builds could have left reltuples set to a bogus value (including Infinity or NaN) that prevents autovacuum and autoanalyze from ever processing the table. The following query lists the tables that have a GIN index, along with their current reltuples:

SELECT DISTINCT t.oid::regclass, t.reltuples FROM pg_class t JOIN pg_index i ON t.oid = i.indrelid JOIN pg_class ic ON i.indexrelid = ic.oid WHERE t.relhasindex AND ic.relam = 2742;

For any table whose reltuples value looks incorrect, run ANALYZE on it (or create another index) to reset the value.

If you use btree_gist, you should reindex btree_gist indexes on float4 or float8 columns that might contain NaN values, as well as btree_gist indexes on bit or bit varying columns, for example:

REINDEX INDEX your_index_name;

If you use ltree and have btree indexes over ltree values with very many labels (more than about 14,653), you should reindex those indexes, since they may be corrupt, for example:

REINDEX INDEX your_index_name;

Users who have skipped one or more update releases may need to run additional post-update steps; please see the release notes from earlier versions for details.

For more details, please see the release notes.

A Note on the PostgreSQL 19 Beta

This release marks the third beta release of PostgreSQL 19.

In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 19 on your systems to help us eliminate bugs and other issues. While we do not advise you to run PostgreSQL 19 Beta 3 in production environments, we encourage you to find ways to run your typical application workloads against this beta release.

Your testing and feedback helps the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our beta testing process and how you can contribute:

https://www.postgresql.org/developer/beta/

Upgrading to PostgreSQL 19 Beta 3

To upgrade to PostgreSQL 19 Beta 3 from an earlier version of PostgreSQL, you will need to use a strategy similar to upgrading between major versions of PostgreSQL (e.g. pg_upgrade or pg_dump / pg_restore). For more information, please visit the documentation section on upgrading.

Changes Since Beta 2

Fixes and changes in PostgreSQL 19 Beta 3 include:

• Revert GROUP BY ALL.
• Several fixes for the new FOR PORTION OF temporal table syntax.
• Several fixes for the new logical replication sequence synchronization feature, including a race involving REFRESH SEQUENCES.
• Fix an "unexpected logical decoding status change" error that could occur when logical decoding is activated concurrently.
• Fix issues around ownership changes for subscriptions.
• Fix wrong query results from postgres_fdw when pushing down an array comparison such as field = ANY($1) that involves an implicit type coercion.
• Fix a crash during foreign-key checks involving a nullable UNIQUE constraint.
• Fix pg_plan_advice parsing of underscores in numeric literals.
• Fix a missing FORMAT clause when deparsing JSON_ARRAY(query).

Please see the release notes for a complete list of new and changed features:

https://www.postgresql.org/docs/19/release-19.html

Testing for Bugs & Compatibility

The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release.

A list of open issues is publicly available in the PostgreSQL wiki. You can report bugs using this form on the PostgreSQL website:

https://www.postgresql.org/account/submitbug/

Links

• Download
• Release Notes
• Security
• Versioning Policy
• Beta Testing Information
• PostgreSQL 19 Beta Release Notes
• PostgreSQL 19 Open Issues
• Submit a Bug
• Donate

If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.