DocumentationVersion comparison
POSTGRESQL · VERSION COMPARE
PostgreSQL 16.14 release changes
All features, fixes, and compatibility notes in this release, with related records from other versions.
Includes changes after the source version through the target. A major version name means its initial release.
Detect the source version from your database
Complete release changes
16.14
2026-05-14
16.14stableSupport ends 2028-11-09
Security changes
| CVE / issue | Severity | Fixed version | Selection status |
|---|---|---|---|
| CVE-2026-6637 Prevent SQL injection and buffer overruns in contrib/spi | 16.14 | Recorded fix | |
| CVE-2026-6477 Mark PQfn() as unsafe, and avoid using it within libpq | 16.14 | Recorded fix | |
| CVE-2026-6475 Prevent path traversal in pg_basebackup and pg_rewind | 16.14 | Recorded fix | |
| CVE-2026-6473 Fix assorted integer overflows in memory-allocation calculations | 16.14 | Recorded fix | |
| CVE-2026-6479 Prevent unbounded recursion while processing startup packets | 16.14 | Recorded fix | |
| CVE-2026-6478 Use timing-safe string comparisons in authentication code | 16.14 | Recorded fix | |
| CVE-2026-6472 When creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type | 16.14 | Recorded fix | |
| CVE-2026-6474 Guard against malicious time zone names in timeofday() and pg_strftime() | 16.14 | Recorded fix | |
| CVE-2026-6638 Properly quote object names in logical replication origin checks | 16.14 | Recorded fix |
PostgreSQL 16.14
Migration and compatibility
A dump/restore is not required for those running 16.X.
However, if you are upgrading from a version earlier than 16.10, see Section E.6.
SecurityPrevent unbounded recursion while processing startup packets
Changes
Prevent unbounded recursion while processing startup packets (Michael Paquier) § §
A malicious client could crash the connected backend by alternating rejected SSL and GSS encryption requests indefinitely.
The PostgreSQL Project thanks Calif.io (in collaboration with Claude and Anthropic Research) for reporting this problem. (CVE-2026-6479)
Related records (4)
- Same changePostgreSQL 18.4 · Prevent unbounded recursion while processing startup packets
- Same changePostgreSQL 17.10 · Prevent unbounded recursion while processing startup packets
- Same changePostgreSQL 15.18 · Prevent unbounded recursion while processing startup packets
- Same changePostgreSQL 14.23 · Prevent unbounded recursion while processing startup packets
SecurityFix assorted integer overflows in memory-allocation calculations
Changes
Fix assorted integer overflows in memory-allocation calculations (Tom Lane, Nathan Bossart, Heikki Linnakangas) § § § § § § § § § §
Various places were incautious about the possibility of integer overflow in calculations of how much memory to allocate. Overflow would lead to allocating a too-small buffer which the caller would then write past the end of. This would at least trigger server crashes, and probably could be exploited for arbitrary code execution. In many but by no means all cases, the hazard exists only in 32-bit builds.
The PostgreSQL Project thanks Xint Code, Bruce Dang, Sven Klemm, and Pavel Kohout for reporting these problems. (CVE-2026-6473)
Related records (4)
- Same changePostgreSQL 18.4 · Fix assorted integer overflows in memory-allocation calculations
- Same changePostgreSQL 17.10 · Fix assorted integer overflows in memory-allocation calculations
- Same changePostgreSQL 15.18 · Fix assorted integer overflows in memory-allocation calculations
- Same changePostgreSQL 14.23 · Fix assorted integer overflows in memory-allocation calculations
SecurityProperly quote object names in logical replication origin checks
Changes
Properly quote object names in logical replication origin checks (Pavel Kohout) §
ALTER SUBSCRIPTION ... REFRESH PUBLICATION interpolated schema and relation names into SQL commands without quoting them, allowing execution of arbitrary SQL on the publisher.
The PostgreSQL Project thanks Pavel Kohout for reporting this problem. (CVE-2026-6638)
SecurityReject over-length options in ts_headline()
Changes
Reject over-length options in ts_headline() (Michael Paquier) §
The StartSel, StopSel and FragmentDelimiter strings must not exceed 32Kb in length, but this was not checked for. An over-length value would typically crash the server.
The PostgreSQL Project thanks Xint Code for reporting this problem. (CVE-2026-6473)
Related records (4)
SecurityGuard against malicious time zone names in timeofday() and pg_strftime()
Changes
Guard against malicious time zone names in timeofday() and pg_strftime() (Tom Lane) § §
A crafted time zone setting could pass % sequences to snprintf(), potentially causing crashes or disclosure of server memory. Another path to similar results was to overflow the limited-size output buffer used by pg_strftime().
The PostgreSQL Project thanks Xint Code for reporting this problem. (CVE-2026-6474)
Related records (4)
- Same changePostgreSQL 18.4 · Guard against malicious time zone names in timeofday() and pg_strftime()
- Same changePostgreSQL 17.10 · Guard against malicious time zone names in timeofday() and pg_strftime()
- Same changePostgreSQL 15.18 · Guard against malicious time zone names in timeofday() and pg_strftime()
- Same changePostgreSQL 14.23 · Guard against malicious time zone names in timeofday() and pg_strftime()
SecurityWhen creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type
Changes
When creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type (Jelte Fennema-Nio) §
The multirange type can be put into a different schema than its parent range type, but we neglected to apply the required privilege check when doing so.
The PostgreSQL Project thanks Jelte Fennema-Nio for reporting this problem. (CVE-2026-6472)
Related records (4)
- Same changePostgreSQL 18.4 · When creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type
- Same changePostgreSQL 17.10 · When creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type
- Same changePostgreSQL 15.18 · When creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type
- Same changePostgreSQL 14.23 · When creating a multirange type, ensure the user has CREATE privilege on the schema specified for the multirange type
SecurityUse timing-safe string comparisons in authentication code
Changes
Use timing-safe string comparisons in authentication code (Michael Paquier) § §
Use timingsafe_bcmp() instead of memcmp() or strcmp() when checking passwords, hashes, etc. It is not known whether the data dependency of those functions is usefully exploitable in any of these places, but in the interests of safety, replace them.
The PostgreSQL Project thanks Joe Conway for reporting this problem. (CVE-2026-6478)
Related records (4)
- Same changePostgreSQL 18.4 · Use timing-safe string comparisons in authentication code
- Same changePostgreSQL 17.10 · Use timing-safe string comparisons in authentication code
- Same changePostgreSQL 15.18 · Use timing-safe string comparisons in authentication code
- Same changePostgreSQL 14.23 · Use timing-safe string comparisons in authentication code
SecurityMark PQfn() as unsafe, and avoid using it within libpq
Changes
Mark PQfn() as unsafe, and avoid using it within libpq (Nathan Bossart) §
For a non-integral result type, PQfn() is not passed the size of the output buffer, so it cannot check that the data returned by the server will fit. A malicious server could therefore overwrite client memory. This is unfixable without an API change, so mark the function as deprecated. Internally to libpq, use a variant version that can apply the missing check.
The PostgreSQL Project thanks Yu Kunpeng and Martin Heistermann for reporting this problem. (CVE-2026-6477)
Related records (4)
- Same changePostgreSQL 18.4 · Mark PQfn() as unsafe, and avoid using it within libpq
- Same changePostgreSQL 17.10 · Mark PQfn() as unsafe, and avoid using it within libpq
- Same changePostgreSQL 15.18 · Mark PQfn() as unsafe, and avoid using it within libpq
- Same changePostgreSQL 14.23 · Mark PQfn() as unsafe, and avoid using it within libpq
SecurityPrevent path traversal in pg_basebackup and pg_rewind
Changes
Prevent path traversal in pg_basebackup and pg_rewind (Michael Paquier) §
These applications failed to validate output file paths read from their input, so that a malicious source could overwrite any file writable by these applications. Constrain where data can be written by rejecting paths that are absolute or contain parent-directory references.
The PostgreSQL Project thanks XlabAI Team of Tencent Xuanwu Lab and Valery Gubanov for reporting this problem. (CVE-2026-6475)
Related records (4)
- Same changePostgreSQL 18.4 · Prevent path traversal in pg_basebackup and pg_rewind
- Same changePostgreSQL 17.10 · Prevent path traversal in pg_basebackup and pg_rewind
- Same changePostgreSQL 15.18 · Prevent path traversal in pg_basebackup and pg_rewind
- Same changePostgreSQL 14.23 · Prevent path traversal in pg_basebackup and pg_rewind
SecurityGuard against field overflow within contrib/intarray's query_int type and contrib/ltree's ltxtquery type
Changes
Guard against field overflow within contrib/intarray's query_int type and contrib/ltree's ltxtquery type (Tom Lane) § §
Parsing of these query structures did not check for overflow of 16-bit fields, so that construction of an invalid query tree was possible. This can crash the server when executing the query.
The PostgreSQL Project thanks Xint Code for reporting this problem. (CVE-2026-6473)
Related records (4)
- Same changePostgreSQL 18.4 · Guard against field overflow within contrib/intarray's query_int type and contrib/ltree's ltxtquery type
- Same changePostgreSQL 17.10 · Guard against field overflow within contrib/intarray's query_int type and contrib/ltree's ltxtquery type
- Same changePostgreSQL 15.18 · Guard against field overflow within contrib/intarray's query_int type and contrib/ltree's ltxtquery type
- Same changePostgreSQL 14.23 · Guard against field overflow within contrib/intarray's query_int type and contrib/ltree's ltxtquery type
SecurityGuard against overly long values of contrib/ltree's lquery type
Changes
Guard against overly long values of contrib/ltree's lquery type (Michael Paquier) §
Values with more than 64K items caused internal overflows, potentially resulting in stack smashes or wrong answers.
The PostgreSQL Project thanks Vergissmeinnicht, A1ex, and Jihe Wang for reporting this problem. (CVE-2026-6473)
Related records (4)
- Same changePostgreSQL 18.4 · Guard against overly long values of contrib/ltree's lquery type
- Same changePostgreSQL 17.10 · Guard against overly long values of contrib/ltree's lquery type
- Same changePostgreSQL 15.18 · Guard against overly long values of contrib/ltree's lquery type
- Same changePostgreSQL 14.23 · Guard against overly long values of contrib/ltree's lquery type
SecurityPrevent SQL injection and buffer overruns in contrib/spi
Changes
Prevent SQL injection and buffer overruns in contrib/spi (Nathan Bossart) §
check_foreign_key() was insufficiently careful about quoting key values, and also used fixed-length buffers for constructing queries. While this module is only meant as example code, it still shouldn't contain such dangerous errors.
The PostgreSQL Project thanks Nikolay Samokhvalov for reporting this problem. (CVE-2026-6637)
Related records (4)
- Same changePostgreSQL 18.4 · Prevent SQL injection and buffer overruns in contrib/spi
- Same changePostgreSQL 17.10 · Prevent SQL injection and buffer overruns in contrib/spi
- Same changePostgreSQL 15.18 · Prevent SQL injection and buffer overruns in contrib/spi
- Same changePostgreSQL 14.23 · Prevent SQL injection and buffer overruns in contrib/spi
ImprovementsCheck for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness
Changes
Check for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness (Richard Guo) § §
Numerous planner optimizations assume that, for example, at most one table row can satisfy WHERE x = 'abc' if there is a unique index on x. However this conclusion is unsafe in general if the index and the WHERE clause have different collations attached. It is safe when both collations are deterministic, because that property essentially requires that equality of two strings means bitwise equality. But nondeterministic collations don't act that way, so that optimizing on the assumption of unique matches can give wrong query answers if either the WHERE clause or the index has a nondeterministic collation.
Related records (4)
- Same changePostgreSQL 18.4 · Check for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness
- Same changePostgreSQL 17.10 · Check for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness
- Same changePostgreSQL 15.18 · Check for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness
- Same changePostgreSQL 14.23 · Check for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness
Bug fixesFix incomplete removal of relation references in RestrictInfo structs during join removal
Changes
Fix incomplete removal of relation references in RestrictInfo structs during join removal (Tom Lane) § §
This oversight has been shown to result in planner failures such as unexpected “FULL JOIN is only supported with merge-joinable or hash-joinable join conditions” errors. It may also have caused failure to consider valid plans in other cases.
Bug fixesFix incorrect handling of NEW generated columns in rule actions and rule qualifications
Changes
Fix incorrect handling of NEW generated columns in rule actions and rule qualifications (Richard Guo, Dean Rasheed) §
Previously, such column references would produce NULL in INSERT cases, or be equivalent to the OLD value in UPDATE cases.
Related records (4)
- Same changePostgreSQL 18.4 · Fix incorrect handling of NEW generated columns in rule actions and rule qualifications
- Same changePostgreSQL 17.10 · Fix incorrect handling of NEW generated columns in rule actions and rule qualifications
- Same changePostgreSQL 15.18 · Fix incorrect handling of NEW generated columns in rule actions and rule qualifications
- Same changePostgreSQL 14.23 · Fix incorrect handling of NEW generated columns in rule actions and rule qualifications
Bug fixesFix spurious “generated columns are not supported in COPY FROM WHERE conditions” errors
Changes
Fix spurious “generated columns are not supported in COPY FROM WHERE conditions” errors (Tom Lane) §
Use of a system column in a COPY FROM WHERE condition could sometimes incorrectly report this error.
Related records (4)
- Same changePostgreSQL 18.4 · Fix spurious “generated columns are not supported in COPY FROM WHERE conditions” errors
- Same changePostgreSQL 17.10 · Fix spurious “generated columns are not supported in COPY FROM WHERE conditions” errors
- Same changePostgreSQL 15.18 · Fix spurious “generated columns are not supported in COPY FROM WHERE conditions” errors
- Same changePostgreSQL 14.23 · Fix spurious “generated columns are not supported in COPY FROM WHERE conditions” errors
ImprovementsCorrectly report a serialization failure when MERGE encounters a concurrently-updated tuple in repeatable-read or serializable mode
Changes
Correctly report a serialization failure when MERGE encounters a concurrently-updated tuple in repeatable-read or serializable mode (Tender Wang) §
Previously, such cases behaved the same as in lower isolation levels.
Related records (3)
- Same changePostgreSQL 18.4 · Correctly report a serialization failure when MERGE encounters a concurrently-updated tuple in repeatable-read or serializable mode
- Same changePostgreSQL 17.10 · Correctly report a serialization failure when MERGE encounters a concurrently-updated tuple in repeatable-read or serializable mode
- Same changePostgreSQL 15.18 · Correctly report a serialization failure when MERGE encounters a concurrently-updated tuple in repeatable-read or serializable mode
Bug fixesFix CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the source table has dropped column(s)
Changes
Fix CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the source table has dropped column(s) (Julien Tachoires) §
In such cases, extended statistics objects could be copied incorrectly, or the command could give an incorrect error.
Related records (4)
- Same changePostgreSQL 18.4 · Fix CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the source table has dropped column(s)
- Same changePostgreSQL 17.10 · Fix CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the source table has dropped column(s)
- Same changePostgreSQL 15.18 · Fix CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the source table has dropped column(s)
- Same changePostgreSQL 14.23 · Fix CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the source table has dropped column(s)
ImprovementsAllow ALTER INDEX ... ATTACH PARTITION to mark the parent index valid if appropriate
Changes
Allow ALTER INDEX ... ATTACH PARTITION to mark the parent index valid if appropriate (Sami Imseih) §
There are edge cases in which a partitioned index might remain marked as invalid even when all its leaf indexes are valid. This change provides a mechanism whereby a user can correct such a situation without resorting to manual catalog updates.
Related records (4)
- Same changePostgreSQL 18.4 · Allow ALTER INDEX ... ATTACH PARTITION to mark the parent index valid if appropriate
- Same changePostgreSQL 17.10 · Allow ALTER INDEX ... ATTACH PARTITION to mark the parent index valid if appropriate
- Same changePostgreSQL 15.18 · Allow ALTER INDEX ... ATTACH PARTITION to mark the parent index valid if appropriate
- Same changePostgreSQL 14.23 · Allow ALTER INDEX ... ATTACH PARTITION to mark the parent index valid if appropriate
Bug fixesFix ALTER FOREIGN DATA WRAPPER to not drop the wrapper object's dependency on its handler function
Changes
Fix ALTER FOREIGN DATA WRAPPER to not drop the wrapper object's dependency on its handler function (Jeff Davis) §
Related records (4)
- Same changePostgreSQL 18.4 · Fix ALTER FOREIGN DATA WRAPPER to not drop the wrapper object's dependency on its handler function
- Same changePostgreSQL 17.10 · Fix ALTER FOREIGN DATA WRAPPER to not drop the wrapper object's dependency on its handler function
- Same changePostgreSQL 15.18 · Fix ALTER FOREIGN DATA WRAPPER to not drop the wrapper object's dependency on its handler function
- Same changePostgreSQL 14.23 · Fix ALTER FOREIGN DATA WRAPPER to not drop the wrapper object's dependency on its handler function
ImprovementsDisallow making a composite type be a member of itself via a multirange
Changes
Disallow making a composite type be a member of itself via a multirange (Heikki Linnakangas) §
We already forbade such cases when the intermediate type is a domain, array, composite type, or range; but multiranges were overlooked.
Related records (4)
- Same changePostgreSQL 18.4 · Disallow making a composite type be a member of itself via a multirange
- Same changePostgreSQL 17.10 · Disallow making a composite type be a member of itself via a multirange
- Same changePostgreSQL 15.18 · Disallow making a composite type be a member of itself via a multirange
- Same changePostgreSQL 14.23 · Disallow making a composite type be a member of itself via a multirange
Bug fixesFix datum-image comparisons to be insensitive to sign-extension variations
Changes
Fix datum-image comparisons to be insensitive to sign-extension variations (David Rowley) §
This fixes some situations that previously led to “could not find memoization table entry” errors or wrong query results.
Related records (4)
- Same changePostgreSQL 18.4 · Fix datum-image comparisons to be insensitive to sign-extension variations
- Same changePostgreSQL 17.10 · Fix datum-image comparisons to be insensitive to sign-extension variations
- Same changePostgreSQL 15.18 · Fix datum-image comparisons to be insensitive to sign-extension variations
- Same changePostgreSQL 14.23 · Fix datum-image comparisons to be insensitive to sign-extension variations
Bug fixesFix incorrect logic for hashed IN/NOT IN with non-strict equality operator
Changes
Fix incorrect logic for hashed IN/NOT IN with non-strict equality operator (Chengpeng Yan) §
The previous coding could crash or give wrong answers. All built-in data types have strict equality operators, so that this issue could only arise with an extension data type.
Related records (4)
- Same changePostgreSQL 18.4 · Fix incorrect logic for hashed IN/NOT IN with non-strict equality operator
- Same changePostgreSQL 17.10 · Fix incorrect logic for hashed IN/NOT IN with non-strict equality operator
- Same changePostgreSQL 15.18 · Fix incorrect logic for hashed IN/NOT IN with non-strict equality operator
- Same changePostgreSQL 14.23 · Fix incorrect logic for hashed IN/NOT IN with non-strict equality operator
ImprovementsTruncate overly-long locale-specific numeric symbols in to_char()
Changes
Truncate overly-long locale-specific numeric symbols in to_char() (Tom Lane) §
If a locale specified a currency symbol, thousands separator, or decimal or sign symbol more than 8 bytes long, a buffer overrun was possible. No such locales exist in the real world, and it's impractical for an unprivileged attacker to install a malicious locale definition underneath a Postgres server; but for safety's sake check for overlength symbols and truncate if needed.
Related records (4)
- Same changePostgreSQL 18.4 · Truncate overly-long locale-specific numeric symbols in to_char()
- Same changePostgreSQL 17.10 · Truncate overly-long locale-specific numeric symbols in to_char()
- Same changePostgreSQL 15.18 · Truncate overly-long locale-specific numeric symbols in to_char()
- Same changePostgreSQL 14.23 · Truncate overly-long locale-specific numeric symbols in to_char()
ImprovementsPrevent buffer overruns when parsing an affix file for an Ispell dictionary
Changes
Prevent buffer overruns when parsing an affix file for an Ispell dictionary (Tom Lane) § §
A corrupt or malicious affix file could crash the server. This is not considered a security issue because text search configuration files are presumed trustworthy, but it still seems worth fixing.
Related records (4)
- Same changePostgreSQL 18.4 · Prevent buffer overruns when parsing an affix file for an Ispell dictionary
- Same changePostgreSQL 17.10 · Prevent buffer overruns when parsing an affix file for an Ispell dictionary
- Same changePostgreSQL 15.18 · Prevent buffer overruns when parsing an affix file for an Ispell dictionary
- Same changePostgreSQL 14.23 · Prevent buffer overruns when parsing an affix file for an Ispell dictionary
ImprovementsGuard against integer overflow in calculations of frame start and end positions for window aggregates
Changes
Guard against integer overflow in calculations of frame start and end positions for window aggregates (Richard Guo) §
Very large user-specified offsets (close to INT64_MAX) could result in errors or incorrect query results.
Related records (4)
- Same changePostgreSQL 18.4 · Guard against integer overflow in calculations of frame start and end positions for window aggregates
- Same changePostgreSQL 17.10 · Guard against integer overflow in calculations of frame start and end positions for window aggregates
- Same changePostgreSQL 15.18 · Guard against integer overflow in calculations of frame start and end positions for window aggregates
- Same changePostgreSQL 14.23 · Guard against integer overflow in calculations of frame start and end positions for window aggregates
Bug fixesFix array_agg_array_combine() to combine the arrays' null bitmaps correctly
Changes
Fix array_agg_array_combine() to combine the arrays' null bitmaps correctly (Dmytro Astapov) §
This mistake resulted in sometimes-incorrect output from parallelized array_agg(anyarray) calculations.
ImprovementsRetry sync_file_range() if it returns error code EINTR
Bug fixesFix incorrect behavior of pg_stat_reset_single_table_counters() on a shared catalog
Changes
Fix incorrect behavior of pg_stat_reset_single_table_counters() on a shared catalog (Chao Li) §
Such cases had a side-effect of resetting the current database's stat_reset_timestamp, which was unintended.
Related records (3)
- Same changePostgreSQL 18.4 · Fix incorrect behavior of pg_stat_reset_single_table_counters() on a shared catalog
- Same changePostgreSQL 17.10 · Fix incorrect behavior of pg_stat_reset_single_table_counters() on a shared catalog
- Same changePostgreSQL 15.18 · Fix incorrect behavior of pg_stat_reset_single_table_counters() on a shared catalog
ImprovementsUpdate activity statistics when a parallel apply worker is idle
Changes
Update activity statistics when a parallel apply worker is idle (Zhijie Hou) §
Previously, statistics from a recently-completed transaction might go unreported for long intervals, particularly if the workload is light.
Related records (2)
Bug fixesFix buffer overread when pglz_decompress() receives corrupt input
Changes
Fix buffer overread when pglz_decompress() receives corrupt input (Andrew Dunstan) §
It was possible to read a few bytes past the end of the input, which in very unlucky cases might cause a crash.
Related records (4)
- Same changePostgreSQL 18.4 · Fix buffer overread when pglz_decompress() receives corrupt input
- Same changePostgreSQL 17.10 · Fix buffer overread when pglz_decompress() receives corrupt input
- Same changePostgreSQL 15.18 · Fix buffer overread when pglz_decompress() receives corrupt input
- Same changePostgreSQL 14.23 · Fix buffer overread when pglz_decompress() receives corrupt input
ImprovementsEnsure that tuplestore data structures are internally consistent even after an error
Changes
Ensure that tuplestore data structures are internally consistent even after an error (Tom Lane) §
The code was previously careless about this, which is fine most of the time but is problematic for the tuplestore backing a WITH HOLD cursor. In v15 and before this leads to easily-reproducible crashes; later branches are not known to be vulnerable, but it seems best to preserve consistency in all.
Related records (4)
- Same changePostgreSQL 18.4 · Ensure that tuplestore data structures are internally consistent even after an error
- Same changePostgreSQL 17.10 · Ensure that tuplestore data structures are internally consistent even after an error
- Same changePostgreSQL 15.18 · Ensure that tuplestore data structures are internally consistent even after an error
- Same changePostgreSQL 14.23 · Ensure that tuplestore data structures are internally consistent even after an error
Bug fixesFix premature NULL lag reporting in pg_stat_replication
Changes
Fix premature NULL lag reporting in pg_stat_replication (Shinya Kato) §
The lag columns frequently read as NULL even while replication activity was happening.
Related records (4)
- Same changePostgreSQL 18.4 · Fix premature NULL lag reporting in pg_stat_replication
- Same changePostgreSQL 17.10 · Fix premature NULL lag reporting in pg_stat_replication
- Same changePostgreSQL 15.18 · Fix premature NULL lag reporting in pg_stat_replication
- Same changePostgreSQL 14.23 · Fix premature NULL lag reporting in pg_stat_replication
ImprovementsAvoid rare flush failure when working with non-WAL-logged GiST indexes
Changes
Avoid rare flush failure when working with non-WAL-logged GiST indexes (Tomas Vondra) §
A non-logged GiST index could nonetheless sometimes produce “xlog flush request n/nnnn is not satisfied” errors, due to incorrect selection of a “fake LSN” to represent an insertion point.
Related records (4)
- Same changePostgreSQL 18.4 · Avoid rare flush failure when working with non-WAL-logged GiST indexes
- Same changePostgreSQL 17.10 · Avoid rare flush failure when working with non-WAL-logged GiST indexes
- Same changePostgreSQL 15.18 · Avoid rare flush failure when working with non-WAL-logged GiST indexes
- Same changePostgreSQL 14.23 · Avoid rare flush failure when working with non-WAL-logged GiST indexes
Bug fixesFix underestimate of required size of DSA page maps for odd-size segments
Changes
Fix underestimate of required size of DSA page maps for odd-size segments (Paul Bunn) §
This miscalculation led to out-of-bounds accesses and hence server crashes.
Related records (4)
- Same changePostgreSQL 18.4 · Fix underestimate of required size of DSA page maps for odd-size segments
- Same changePostgreSQL 17.10 · Fix underestimate of required size of DSA page maps for odd-size segments
- Same changePostgreSQL 15.18 · Fix underestimate of required size of DSA page maps for odd-size segments
- Same changePostgreSQL 14.23 · Fix underestimate of required size of DSA page maps for odd-size segments
Bug fixesFix possible server crash when processing extended statistics on expressions of extension data types
Changes
Fix possible server crash when processing extended statistics on expressions of extension data types (Michael Paquier) §
NULL pointer dereferences were possible if the data type's typanalyze function does not compute any useful statistics. No in-core typanalyze function behaves that way, but extensions could.
Related records (4)
- Same changePostgreSQL 18.4 · Fix possible server crash when processing extended statistics on expressions of extension data types
- Same changePostgreSQL 17.10 · Fix possible server crash when processing extended statistics on expressions of extension data types
- Same changePostgreSQL 15.18 · Fix possible server crash when processing extended statistics on expressions of extension data types
- Same changePostgreSQL 14.23 · Fix possible server crash when processing extended statistics on expressions of extension data types
Bug fixesFix minor memory leaks in ICU-based string processing
ImprovementsIf the startup process fails, properly shut down other child processes before exiting the postmaster
Changes
If the startup process fails, properly shut down other child processes before exiting the postmaster (Ayush Tiwari) §
The handling of this situation relied on a long-obsolete assumption that no other postmaster children exist while the startup process is running, so that immediate postmaster exit is acceptable. Orphaned children would eventually notice the postmaster's death and exit on their own, but a cleaner shutdown procedure is desirable.
Related records (3)
- Same changePostgreSQL 18.4 · If the startup process fails, properly shut down other child processes before exiting the postmaster
- Same changePostgreSQL 17.10 · If the startup process fails, properly shut down other child processes before exiting the postmaster
- Same changePostgreSQL 15.18 · If the startup process fails, properly shut down other child processes before exiting the postmaster
Bug fixesFix race condition between WAL replay of checkpoints and multixact ID creations
Changes
Fix race condition between WAL replay of checkpoints and multixact ID creations (Heikki Linnakangas) §
A standby server following WAL from a primary of an older minor version could get into a crash-and-restart loop complaining about “could not access status of transaction”.
Related records (4)
- Same changePostgreSQL 18.4 · Fix race condition between WAL replay of checkpoints and multixact ID creations
- Same changePostgreSQL 17.10 · Fix race condition between WAL replay of checkpoints and multixact ID creations
- Same changePostgreSQL 15.18 · Fix race condition between WAL replay of checkpoints and multixact ID creations
- Same changePostgreSQL 14.23 · Fix race condition between WAL replay of checkpoints and multixact ID creations
ImprovementsPrevent indefinite wait in shutdown of a walsender process
Changes
Prevent indefinite wait in shutdown of a walsender process (Anthonin Bonnefoy) § §
At shutdown of a cluster that is publishing logical replication data, the walsender waits for all pending WAL to be written out. But it did not correctly request that to happen, so that in some cases this could become an indefinite wait.
Related records (4)
- Same changePostgreSQL 18.4 · Prevent indefinite wait in shutdown of a walsender process
- Same changePostgreSQL 17.10 · Prevent indefinite wait in shutdown of a walsender process
- Same changePostgreSQL 15.18 · Prevent indefinite wait in shutdown of a walsender process
- Same changePostgreSQL 14.23 · Prevent indefinite wait in shutdown of a walsender process
ImprovementsEnsure that changes to tables' free space maps are persisted during recovery
Changes
Ensure that changes to tables' free space maps are persisted during recovery (Alexey Makhmutov) §
Previously, while WAL replay did update the free space map while replaying operations that should change it, the map page buffer did not get marked dirty if checksums are enabled, so that the changes might never get written out. On a standby server, over time this would result in a map wildly at variance with the table's actual contents. While the map is only used as a hint, this condition could cause significant performance degradation for some period of time after the standby server is promoted to be active, until most of the map has been repaired by updates.
Related records (4)
- Same changePostgreSQL 18.4 · Ensure that changes to tables' free space maps are persisted during recovery
- Same changePostgreSQL 17.10 · Ensure that changes to tables' free space maps are persisted during recovery
- Same changePostgreSQL 15.18 · Ensure that changes to tables' free space maps are persisted during recovery
- Same changePostgreSQL 14.23 · Ensure that changes to tables' free space maps are persisted during recovery
Bug fixesFix crashes in some ecpg functions when called without any established connection
Changes
Fix crashes in some ecpg functions when called without any established connection (Shruthi Gowda) §
Related records (4)
- Same changePostgreSQL 18.4 · Fix crashes in some ecpg functions when called without any established connection
- Same changePostgreSQL 17.10 · Fix crashes in some ecpg functions when called without any established connection
- Same changePostgreSQL 15.18 · Fix crashes in some ecpg functions when called without any established connection
- Same changePostgreSQL 14.23 · Fix crashes in some ecpg functions when called without any established connection
Bug fixesFix assorted bugs in backup decompression and tar-parsing code
Changes
Fix assorted bugs in backup decompression and tar-parsing code (Andrew Dunstan, Tom Lane, Chao Li) § § §
The decompression and tar-file reading code used in pg_basebackup and pg_verifybackup mishandled tar-file padding data, could corrupt LZ4-compressed data in edge cases, failed to check for some unusual error conditions, failed to exit after compression/decompression errors (leading to cascading error reports), and leaked memory.
ImprovementsIn pg_dumpall, don't skip role GRANTs with dangling grantor OIDs
Changes
In pg_dumpall, don't skip role GRANTs with dangling grantor OIDs (Tom Lane) §
Instead, handle such cases by emitting GRANT without any GRANTED BY clause, as we did before v16. This avoids losing the grant in foreseeable cases, since pre-v16 servers didn't prevent dropping the grantor role. Continue to emit a warning about the missing grantor, but only if the source server is v16 or later.
Bug fixesIn pg_upgrade, take care to use the correct protocol version when connecting to older source servers
Changes
In pg_upgrade, take care to use the correct protocol version when connecting to older source servers (Jacob Champion) §
This could be problematic when attempting to upgrade from a pre-2018 server.
Related records (4)
- Same changePostgreSQL 18.4 · In pg_upgrade, take care to use the correct protocol version when connecting to older source servers
- Same changePostgreSQL 17.10 · In pg_upgrade, take care to use the correct protocol version when connecting to older source servers
- Same changePostgreSQL 15.18 · In pg_upgrade, take care to use the correct protocol version when connecting to older source servers
- Same changePostgreSQL 14.23 · In pg_upgrade, take care to use the correct protocol version when connecting to older source servers
ImprovementsIn contrib/basic_archive, allow the archive directory to be missing at startup
Changes
In contrib/basic_archive, allow the archive directory to be missing at startup (Nathan Bossart) §
Previously, the setting of basic_archive.archive_directory was rejected if it didn't point to an existing directory. This is undesirable because archiving will be stuck indefinitely, even if the directory appears later.
Related records (3)
- Same changePostgreSQL 18.4 · In contrib/basic_archive, allow the archive directory to be missing at startup
- Same changePostgreSQL 17.10 · In contrib/basic_archive, allow the archive directory to be missing at startup
- Same changePostgreSQL 15.18 · In contrib/basic_archive, allow the archive directory to be missing at startup
Bug fixesFix contrib/ltree to cope when case-folding changes a string's byte length
Changes
Fix contrib/ltree to cope when case-folding changes a string's byte length (Jeff Davis) §
Previously, lquery patterns specifying case-insensitive matching might fail to match labels they should match.
Related records (4)
- Same changePostgreSQL 18.4 · Fix contrib/ltree to cope when case-folding changes a string's byte length
- Same changePostgreSQL 17.10 · Fix contrib/ltree to cope when case-folding changes a string's byte length
- Same changePostgreSQL 15.18 · Fix contrib/ltree to cope when case-folding changes a string's byte length
- Same changePostgreSQL 14.23 · Fix contrib/ltree to cope when case-folding changes a string's byte length
ImprovementsIn contrib/pg_stat_statements, don't leak memory if an error occurs while parsing the pgss_query_texts.stat file
Changes
In contrib/pg_stat_statements, don't leak memory if an error occurs while parsing the pgss_query_texts.stat file (Heikki Linnakangas) §
Related records (4)
- Same changePostgreSQL 18.4 · In contrib/pg_stat_statements, don't leak memory if an error occurs while parsing the pgss_query_texts.stat file
- Same changePostgreSQL 17.10 · In contrib/pg_stat_statements, don't leak memory if an error occurs while parsing the pgss_query_texts.stat file
- Same changePostgreSQL 15.18 · In contrib/pg_stat_statements, don't leak memory if an error occurs while parsing the pgss_query_texts.stat file
- Same changePostgreSQL 14.23 · In contrib/pg_stat_statements, don't leak memory if an error occurs while parsing the pgss_query_texts.stat file
Bug fixesIn contrib/postgres_fdw, avoid crash due to premature cleanup of a failed connection
Changes
In contrib/postgres_fdw, avoid crash due to premature cleanup of a failed connection (Etsuro Fujita) §
If a remote connection fails abort cleanup, we can't use it any longer. But delay closing the connection object until end of transaction, because there might still be references to it within data structures such as open cursors.
Related records (4)
- Same changePostgreSQL 18.4 · In contrib/postgres_fdw, avoid crash due to premature cleanup of a failed connection
- Same changePostgreSQL 17.10 · In contrib/postgres_fdw, avoid crash due to premature cleanup of a failed connection
- Same changePostgreSQL 15.18 · In contrib/postgres_fdw, avoid crash due to premature cleanup of a failed connection
- Same changePostgreSQL 14.23 · In contrib/postgres_fdw, avoid crash due to premature cleanup of a failed connection
ImprovementsUpdate time zone data files to tzdata release 2026b
Changes
Update time zone data files to tzdata release 2026b (Tom Lane) §
British Columbia (America/Vancouver) will be on year-round UTC-07 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be MST from that time forward. That seems likely to change, but it's unclear what new abbreviation will be used. Also a historical correction for Moldova: they have followed EU DST transition times since 2022.
Related records (4)
- Same changePostgreSQL 18.4 · Update time zone data files to tzdata release 2026b
- Same changePostgreSQL 17.10 · Update time zone data files to tzdata release 2026b
- Same changePostgreSQL 15.18 · Update time zone data files to tzdata release 2026b
- Same changePostgreSQL 14.23 · Update time zone data files to tzdata release 2026b
No matching changes
Try another search, or .
How is this comparison generated?
The comparison follows PostgreSQL release notes from just after the source through the target version. Confirmed backport duplicates are merged conservatively, with every original explanation retained. Related commits can represent independent changes; they remain separate records.
Release snapshot: 2026-09-26 · Security snapshot: 2026-09-26
Content comes from PostgreSQL release notes. Interaction inspired by pgversions.com and pgversionreport.