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:
btree_gistltreeFor the full list of changes, please review the release notes.
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.
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:
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:
The remainder of issues listed below affect PostgreSQL 18. Many of these issues also affect other supported versions of PostgreSQL.
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.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.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.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.RETURNING with
OLD and NEW.NULL values.value IN (array) tests where the array might be empty, and COUNT() window
functions that use an EXCLUDE clause or lack ORDER BY.REINDEX
CONCURRENTLY on an
index backing a deferred uniqueness constraint, which could cause false
constraint-violation reports.LIKE or
regular-expression exact-match pattern into an equality index condition when the
index and expression collations differ.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."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.VACUUM's
wraparound failsafe mode to use the full shared buffer pool as intended, which
had slowed down emergency vacuuming.SERIALIZABLE
isolation. A conflict could be missed when examining an initially-empty btree
index, allowing conflicting transactions to commit and breaking serializability.COMMIT PREPARED or ROLLBACK PREPARED to the output plugin with no
preceding PREPARE, which breaks replication for the built-in subscriber.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.pg_createsubscriber
to clean up objects left on a publisher after failure, including a replication
slot.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.
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.
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/
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.
Fixes and changes in PostgreSQL 19 Beta 3 include:
GROUP BY ALL.FOR PORTION OF temporal table syntax.REFRESH SEQUENCES.postgres_fdw when pushing down an array
comparison such as field = ANY($1) that involves an implicit type coercion.UNIQUE constraint.pg_plan_advice parsing of underscores in numeric literals.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
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/
If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.