The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 18.7, 17.12, 16.16, 15.20, and 14.25, as well as the second release candidate of PostgreSQL 19. This release fixes 52 security vulnerabilities and over 140 bugs reported over the last several months.
There are several issues that may require you to take extra steps after updating, which are described in detail below. See the "Updating" section for more information on post-update steps you may need to take.
For the full list of changes, please review the release notes.
This is the final release of PostgreSQL 14. PostgreSQL 14 is now end-of-life and will no longer receive security and bug fixes. 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 in this update release. You can find more details about the vulnerabilities and their affected versions in the links below:
ALTER ... SET DATA TYPE executes arbitrary code (CVSS v3.1: 8.8)dblink and subscriptions can append to arbitrary files (CVSS v3.1: 8.1)INSERT ... ON CONFLICT can read or modify rows despite auto-updatable view WHERE condition (CVSS v3.1: 5.4)pg_basebackup can use backup manifest content as a format string (CVSS v3.1: 3.7)EXECUTE privilege on cast functions (CVSS v3.1: 3.1)RECORD typmod use-after-free executes arbitrary code (CVSS v3.1: 8.8)plperl prepared-query use-after-free executes arbitrary code (CVSS v3.1: 8.8)dict_int reads beyond zero-length tokens (CVSS v3.1: 4.3)plperl blessed-reference type confusion may execute arbitrary code (CVSS v3.1: 8.8)COPY error context uses freed field storage (CVSS v3.1: 4.3)DROP OWNED can remove restrictive row security policies from non-owned tables (CVSS v3.1: 5.4)MERGE can place the wrong row in a trigger transition table (CVSS v3.1: 5.4)vacuumdb --missing-stats-only lets a database owner execute code as the vacuumdb user (CVSS v3.1: 7.2)pg_restore executes arbitrary code due to missing non-plain archive validation (CVSS v3.1: 8.8)tsvector_delete() heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)ts_rank_cd() heap buffer overflow may execute arbitrary code (CVSS v3.1: 8.8)pg_dump not-null constraint name allows SQL injection (CVSS v3.1: 8.8)plperl reentrant return_next() use-after-free executes arbitrary code (CVSS v3.1: 8.8)plperl array and hash conversion use-after-free executes arbitrary code (CVSS v3.1: 8.8)pltcl reentrant result conversion use-after-free executes arbitrary code (CVSS v3.1: 8.8)reindexdb index name quoting allows SQL injection (CVSS v3.1: 8)plperl tied-object exceptions follow stale sigjmp_buf (CVSS v3.1: 8.8)security_barrier analysis can expose hidden values through indirect expressions (CVSS v3.1: 4.3)pg_dump tar restore.sql fails to block psql command injection (CVSS v3.1: 8.8)REINDEX CONCURRENTLY does not block DROP INDEX during index functions (CVSS v3.1: 8.8)REASSIGN OWNED bypasses role SET and CREATEDB checks (CVSS v3.1: 4.3)dblink reentrant disconnect use-after-free executes arbitrary code (CVSS v3.1: 8.8)plpgsql record-field type confusion executes arbitrary code (CVSS v3.1: 8.8)pg_show_all_settings() use-after-free discloses memory (CVSS v3.1: 4.3)INSERT ... ON CONFLICT can read rows despite row security policies (CVSS v3.1: 4.3)This update fixes over 140 bugs that were reported in the last several months. The issues listed below affect PostgreSQL 18. Many of these issues also affect other supported versions of PostgreSQL.
pg_dump against a
standby server, and could corrupt both the dump output and the standby server's
data. More generally, a transaction that imported a snapshot taken on a standby
server could return wrong results.pg_trgm GiST indexes
that could cause searches to miss matching rows. You need to reindex after
updating; see the "Updating" section.REINDEX CONCURRENTLY
rebuilt an index on a
TOAST table,
later index updates could be missed, leading to missing chunk number errors.
If you've encountered this issue, after updating, you'll need to reindex. See
the "Updating" section.NOT NULL NO INHERIT constraints on partitioned tables in all
cases, including CREATE TABLE ... LIKE. Previously, this could allow a
partition to contain NULL values when it should not. See the "Updating"
section for how to find and repair affected constraints.bpchar without a
length, which could cause index-only scans to return wrong results. If you have
B-tree indexes on bpchar columns, you should reindex them after updating. See
the "Updating" section.pg_control file, and avoiding
truncated or zero-padded copies of files such as postgresql.auto.conf that
are replaced while the backup is running.CLUSTER or
VACUUM FULL) when a row had been updated by a subtransaction that later
aborted.LATERAL references, outer joins, self-join elimination
on tables using inheritance, DISTINCT ON in a subquery with set-returning
functions, and queries using non-deterministic collations.RANGE-partitioned
tables when a query filters only on the leading columns, DEFAULT partitions
on tables using MINVALUE or MAXVALUE bounds, and concurrent updates that
could silently skip rows that should be updated.INSERT ... ON
CONFLICT
to acquire a predicate lock on the conflicting row under
SERIALIZABLE
isolation. Previously, concurrent updates that should have failed with a
serialization error could succeed.MERGE with
WHEN NOT MATCHED BY SOURCE when the target row is concurrently deleted.
Previously, a WHEN NOT MATCHED BY TARGET action could run instead, giving
incorrect results.JSON_TABLE and JSON_VALUE that could return incorrect
results.psql to accept
multiple COPY ... FROM STDIN
commands in a single command string. The fix for CVE-2026-6464 caused psql to reject these.AT TIME ZONE in a FROM clause or a target alias named set, tsvector
and tsquery values that could fail to reload.This release also updates time zone data files to tzdata release 2026f.
Beginning in November 2026, Canada's Northwest Territories (America/Inuvik)
are on year-round UTC-06 and Manitoba (America/Winnipeg) is on year-round
UTC-05. This release assumes their TZ abbreviations will be CST and EST
respectively (though this could change). It also reflects that Cuba will stay
on daylight saving time this winter, and that the EST5EDT, CST6CDT,
MST7MDT, and PST8PDT zone names now use their indicated UTC offsets for
old timestamps instead of the history of their associated city-named zones.
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 suspect that a GIN index is affected by one of the corruption issues fixed in this release, you should reindex it, for example:
REINDEX INDEX your_index_name;
If you use pg_trgm, you should reindex any GiST indexes that use the
gist_trgm_ops operator class.
If you see missing chunk number errors when reading a table, you should
reindex the table, which also reindexes its TOAST table, for example:
REINDEX TABLE your_table_name;
If you use incremental backups, we recommend taking a new full backup after updating and using it as the basis for subsequent incremental backups.
If you use partitioned tables, the following query finds NOT NULL NO INHERIT
constraints on partitioned tables:
SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');
You can remove unwanted constraints with ALTER TABLE ... DROP CONSTRAINT ....
Constraints you want to keep should be repaired with
ALTER TABLE ... ALTER CONSTRAINT ... INHERIT, which will fail if any of the
table's partitions contain NULL values in that column.
If you have B-tree indexes on bpchar columns (that is, columns declared as
bpchar without a length), you should reindex them after updating. Columns
declared as char(n) are not affected.
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 second release candidate of PostgreSQL 19. As a release candidate, PostgreSQL 19 RC 2 will be mostly identical to the initial release of PostgreSQL 19, though some more fixes may be applied prior to the general availability of PostgreSQL 19. PostgreSQL 19 RC 2 also includes the fixes in this update release that apply to PostgreSQL 19.
The planned date for the general availability of PostgreSQL 19 is November 19, 2026. Please see the "Release Schedule" section for more details.
To upgrade to PostgreSQL 19 RC 2 from earlier versions of PostgreSQL, you will
need to use a major version upgrade strategy, e.g. pg_upgrade or
pg_dump / pg_restore. For more information, please visit the documentation
section on upgrading:
https://www.postgresql.org/docs/19/upgrading.html
If you use pg_upgrade and have indexes that use
full text search,
pg_trgm, or
fuzzystrmatch, please
review the
"Migration to Version 19"
section of the release notes, as you may need to reindex them after upgrading.
Several bug fixes were applied to PostgreSQL 19 during the RC 1 period. These include:
JSON_ARRAY() and JSON_OBJECT()
expressions over arrays, composite types, and range types to be used in
expression indexes, generated columns, and partition keys, as these indexes
could become out-of-date. If you created any of these objects while testing
PostgreSQL 19, you need to drop or redefine them before upgrading, as
pg_dump / pg_restore and pg_upgrade will fail to recreate them.GROUPING SETS
queries, where a column not included in the current grouping set could show a
value instead of NULL.first_value() and nth_value() when using
IGNORE NULLS with
some EXCLUDE frame options.LISTEN /
NOTIFY queue becoming
stuck if a session is interrupted while reading notifications.work_mem
limit based on the planner's row estimate.For a detailed list of fixes, please visit the open items page.
This is the second release candidate for PostgreSQL 19. Unless an issue is discovered that requires a delay or an additional release candidate, PostgreSQL 19 should be made generally available on November 19, 2026.
For further information please see the Beta Testing page.
If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.