DocumentationVersion comparison
POSTGRESQL · VERSION COMPARE
PostgreSQL 15.16 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
15.16
2026-02-12
15.16stableSupport ends 2027-11-11
Security changes
| CVE / issue | Severity | Fixed version | Selection status |
|---|---|---|---|
| CVE-2026-2006 Fix inadequate validation of multibyte character lengths | 15.16 | Recorded fix | |
| CVE-2026-2005 Fix buffer overrun in contrib/pgcrypto's PGP decryption functions | 15.16 | Recorded fix | |
| CVE-2026-2004 Harden selectivity estimators against being attached to operators that accept unexpected data types | 15.16 | Recorded fix | |
| CVE-2026-2003 Guard against unexpected dimensions of oidvector/int2vector | 15.16 | Recorded fix |
PostgreSQL 15.16
Migration and compatibility
A dump/restore is not required for those running 15.X.
However, if you are upgrading from a version earlier than 15.14, see Section E.6.
SecurityGuard against unexpected dimensions of oidvector/int2vector
Changes
Guard against unexpected dimensions of oidvector/int2vector (Tom Lane) §
These data types are expected to be 1-dimensional arrays containing no nulls, but there are cast pathways that permit violating those expectations. Add checks to some functions that were depending on those expectations without verifying them, and could misbehave in consequence.
The PostgreSQL Project thanks Altan Birler for reporting this problem. (CVE-2026-2003)
Related records (4)
- Same changePostgreSQL 18.2 · Guard against unexpected dimensions of oidvector/int2vector
- Same changePostgreSQL 17.8 · Guard against unexpected dimensions of oidvector/int2vector
- Same changePostgreSQL 16.12 · Guard against unexpected dimensions of oidvector/int2vector
- Same changePostgreSQL 14.21 · Guard against unexpected dimensions of oidvector/int2vector
SecurityHarden selectivity estimators against being attached to operators that accept unexpected data types
Changes
Harden selectivity estimators against being attached to operators that accept unexpected data types (Tom Lane) § § §
contrib/intarray contained a selectivity estimation function that could be abused for arbitrary code execution, because it did not check that its input was of the expected data type. Third-party extensions should check for similar hazards and add defenses using the technique intarray now uses. Since such extension fixes will take time, we now require superuser privilege to attach a non-built-in selectivity estimator to an operator.
The PostgreSQL Project thanks Daniel Firer, as part of zeroday.cloud, for reporting this problem. (CVE-2026-2004)
Related records (4)
- Same changePostgreSQL 18.2 · Harden selectivity estimators against being attached to operators that accept unexpected data types
- Same changePostgreSQL 17.8 · Harden selectivity estimators against being attached to operators that accept unexpected data types
- Same changePostgreSQL 16.12 · Harden selectivity estimators against being attached to operators that accept unexpected data types
- Same changePostgreSQL 14.21 · Harden selectivity estimators against being attached to operators that accept unexpected data types
SecurityFix buffer overrun in contrib/pgcrypto's PGP decryption functions
Changes
Fix buffer overrun in contrib/pgcrypto's PGP decryption functions (Michael Paquier) §
Decrypting a crafted message with an overlength session key caused a buffer overrun, with consequences as bad as arbitrary code execution.
The PostgreSQL Project thanks Team Xint Code, as part of zeroday.cloud, for reporting this problem. (CVE-2026-2005)
Related records (4)
- Same changePostgreSQL 18.2 · Fix buffer overrun in contrib/pgcrypto's PGP decryption functions
- Same changePostgreSQL 17.8 · Fix buffer overrun in contrib/pgcrypto's PGP decryption functions
- Same changePostgreSQL 16.12 · Fix buffer overrun in contrib/pgcrypto's PGP decryption functions
- Same changePostgreSQL 14.21 · Fix buffer overrun in contrib/pgcrypto's PGP decryption functions
SecurityFix inadequate validation of multibyte character lengths
Changes
Fix inadequate validation of multibyte character lengths (Thomas Munro, Noah Misch) § § § § § §
Assorted bugs allowed an attacker able to issue crafted SQL to overrun string buffers, with consequences as bad as arbitrary code execution. After these fixes, applications may observe “invalid byte sequence for encoding” errors when string functions process invalid text that has been stored in the database.
The PostgreSQL Project thanks Paul Gerste and Moritz Sanft, as part of zeroday.cloud, for reporting this problem. (CVE-2026-2006)
Related records (4)
- Same changePostgreSQL 18.2 · Fix inadequate validation of multibyte character lengths
- Same changePostgreSQL 17.8 · Fix inadequate validation of multibyte character lengths
- Same changePostgreSQL 16.12 · Fix inadequate validation of multibyte character lengths
- Same changePostgreSQL 14.21 · Fix inadequate validation of multibyte character lengths
ImprovementsDon't allow CTE references in sub-selects to determine semantic levels of aggregate functions
Changes
Don't allow CTE references in sub-selects to determine semantic levels of aggregate functions (Tom Lane) §
This change undoes a change made two minor releases ago, instead throwing an error if a sub-select references a CTE that's below the semantic level that standard SQL rules would assign to the aggregate based on contained column references and aggregates. The attempted fix turned out to cause problems of its own, and it's unclear what to do instead. Since sub-selects within aggregates are disallowed altogether by the SQL standard, treating such cases as errors seems sufficient.
Related records (4)
- Same changePostgreSQL 18.2 · Don't allow CTE references in sub-selects to determine semantic levels of aggregate functions
- Same changePostgreSQL 17.8 · Don't allow CTE references in sub-selects to determine semantic levels of aggregate functions
- Same changePostgreSQL 16.12 · Don't allow CTE references in sub-selects to determine semantic levels of aggregate functions
- Same changePostgreSQL 14.21 · Don't allow CTE references in sub-selects to determine semantic levels of aggregate functions
Bug fixesFix trigger transition table capture for MERGE in CTE queries
Changes
Fix trigger transition table capture for MERGE in CTE queries (Dean Rasheed) §
When executing a data-modifying CTE query containing both a MERGE and another DML operation on a table with statement-level AFTER triggers, the transition tables passed to the triggers would not include the rows affected by the MERGE, only those affected by the other operation(s).
Bug fixesFix failure when all children of a partitioned target table of an update or delete have been pruned
Changes
Fix failure when all children of a partitioned target table of an update or delete have been pruned (Amit Langote) §
In such cases, the executor could report “could not find junk ctid column” errors, even though nothing needs to be done.
Related records (4)
- Same changePostgreSQL 18.2 · Fix failure when all children of a partitioned target table of an update or delete have been pruned
- Same changePostgreSQL 17.8 · Fix failure when all children of a partitioned target table of an update or delete have been pruned
- Same changePostgreSQL 16.12 · Fix failure when all children of a partitioned target table of an update or delete have been pruned
- Same changePostgreSQL 14.21 · Fix failure when all children of a partitioned target table of an update or delete have been pruned
ImprovementsAllow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause
Changes
Allow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause (Tom Lane) §
Normally we drop a WHERE clause that is implied by the predicate, since it's pointless to test it; it must hold for every index entry. However that can prevent creation of an indexscan plan if the index is one that requires a WHERE clause on the leading index key, as hash indexes do. Don't drop implied clauses when considering such an index.
Related records (4)
- Same changePostgreSQL 18.2 · Allow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause
- Same changePostgreSQL 17.8 · Allow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause
- Same changePostgreSQL 16.12 · Allow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause
- Same changePostgreSQL 14.21 · Allow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause
ImprovementsDo not emit WAL for unlogged BRIN indexes
Changes
Do not emit WAL for unlogged BRIN indexes (Kirill Reshke) §
One seldom-taken code path incorrectly emitted a WAL record relating to a BRIN index even if the index was marked unlogged. Crash recovery would then fail to replay that record, complaining that the file already exists.
Related records (4)
ImprovementsPrevent truncation of CLOG that is still needed by unread NOTIFY messages
Changes
Prevent truncation of CLOG that is still needed by unread NOTIFY messages (Joel Jacobson, Heikki Linnakangas) § § §
This fix prevents “could not access status of transaction” errors when a backend is slow to absorb NOTIFY messages.
Related records (4)
- Same changePostgreSQL 18.2 · Prevent truncation of CLOG that is still needed by unread NOTIFY messages
- Same changePostgreSQL 17.8 · Prevent truncation of CLOG that is still needed by unread NOTIFY messages
- Same changePostgreSQL 16.12 · Prevent truncation of CLOG that is still needed by unread NOTIFY messages
- Same changePostgreSQL 14.21 · Prevent truncation of CLOG that is still needed by unread NOTIFY messages
ImprovementsEscalate errors occurring during NOTIFY message processing to FATAL, i.e. close the connection
Changes
Escalate errors occurring during NOTIFY message processing to FATAL, i.e. close the connection (Heikki Linnakangas) §
Formerly, if a backend got an error while absorbing a NOTIFY message, it would advance past that message, report the error to the client, and move on. That behavior was fraught with problems though. One big concern is that the client has no good way to know that a notification was lost, and certainly no way to know what was in it. Depending on the application logic, missing a notification could cause the application to get stuck waiting, for example. Also, any remaining messages would not get processed until someone sent a new NOTIFY.
Also, if the connection is idle at the time of receiving a NOTIFY signal, any ERROR would be escalated to FATAL anyway, due to unrelated concerns. Therefore, we've chosen to make that happen in all cases, for consistency and to provide a clear signal to the application that it might have missed some notifications.
Related records (4)
- Same changePostgreSQL 18.2 · Escalate errors occurring during NOTIFY message processing to FATAL, i.e. close the connection
- Same changePostgreSQL 17.8 · Escalate errors occurring during NOTIFY message processing to FATAL, i.e. close the connection
- Same changePostgreSQL 16.12 · Escalate errors occurring during NOTIFY message processing to FATAL, i.e. close the connection
- Same changePostgreSQL 14.21 · Escalate errors occurring during NOTIFY message processing to FATAL, i.e. close the connection
Bug fixesFix bug in following update chain when locking a tuple
Changes
Fix bug in following update chain when locking a tuple (Jasper Smit) §
This code path neglected to check the xmin of the first new tuple in the update chain, making it possible to lock an unrelated tuple if the original updater aborted and the space was immediately reclaimed by VACUUM and then re-used. That could cause unexpected transaction delays or deadlocks. Errors associated with having identified the wrong tuple have also been observed.
Related records (4)
- Same changePostgreSQL 18.2 · Fix bug in following update chain when locking a tuple
- Same changePostgreSQL 17.8 · Fix bug in following update chain when locking a tuple
- Same changePostgreSQL 16.12 · Fix bug in following update chain when locking a tuple
- Same changePostgreSQL 14.21 · Fix bug in following update chain when locking a tuple
Bug fixesFix issues around in-place catalog updates
Changes
Fix issues around in-place catalog updates (Noah Misch) § § §
Send a nontransactional invalidation message for an in-place update, since such an update will survive transaction rollback. Also ensure that the update is WAL-logged before other sessions can see it. These fixes primarily prevent scenarios in which relations' frozen-XID attributes become inconsistent, possibly allowing premature CLOG truncation and subsequent “could not access status of transaction” errors.
Related records (3)
Bug fixesFix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment
Changes
Fix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment (Rahila Syed) §
Related records (4)
- Same changePostgreSQL 18.2 · Fix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment
- Same changePostgreSQL 17.8 · Fix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment
- Same changePostgreSQL 16.12 · Fix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment
- Same changePostgreSQL 14.21 · Fix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment
ImprovementsGuard against incorrect truncation of the multixact log after a crash
Changes
Guard against incorrect truncation of the multixact log after a crash (Heikki Linnakangas) §
Related records (4)
- Same changePostgreSQL 18.2 · Guard against incorrect truncation of the multixact log after a crash
- Same changePostgreSQL 17.8 · Guard against incorrect truncation of the multixact log after a crash
- Same changePostgreSQL 16.12 · Guard against incorrect truncation of the multixact log after a crash
- Same changePostgreSQL 14.21 · Guard against incorrect truncation of the multixact log after a crash
Bug fixesFix possibly mis-encoded result of pg_stat_get_backend_activity()
Changes
Fix possibly mis-encoded result of pg_stat_get_backend_activity() (Chao Li) §
The shared-memory buffer holding a session's activity string can end with an incomplete multibyte character. Readers are supposed to truncate off any such incomplete character, but this function failed to do so.
Related records (4)
- Same changePostgreSQL 18.2 · Fix possibly mis-encoded result of pg_stat_get_backend_activity()
- Same changePostgreSQL 17.8 · Fix possibly mis-encoded result of pg_stat_get_backend_activity()
- Same changePostgreSQL 16.12 · Fix possibly mis-encoded result of pg_stat_get_backend_activity()
- Same changePostgreSQL 14.21 · Fix possibly mis-encoded result of pg_stat_get_backend_activity()
ImprovementsGuard against recursive memory context logging
Changes
Guard against recursive memory context logging (Fujii Masao) §
A constant flow of signals requesting memory context logging could cause recursive execution of the logging code, which in theory could lead to stack overflow.
Related records (4)
- Same changePostgreSQL 18.2 · Guard against recursive memory context logging
- Same changePostgreSQL 17.8 · Guard against recursive memory context logging
- Same changePostgreSQL 16.12 · Guard against recursive memory context logging
- Same changePostgreSQL 14.21 · Guard against recursive memory context logging
Bug fixesFix memory context usage when reinitializing a parallel execution context
Changes
Fix memory context usage when reinitializing a parallel execution context (Jakub Wartak, Jeevan Chalke) §
This error could result in a crash due to a subsidiary data structure having a shorter lifespan than the parallel context. The problem is not known to be reachable using only core PostgreSQL, but we have reports of trouble in extensions.
Related records (4)
- Same changePostgreSQL 18.2 · Fix memory context usage when reinitializing a parallel execution context
- Same changePostgreSQL 17.8 · Fix memory context usage when reinitializing a parallel execution context
- Same changePostgreSQL 16.12 · Fix memory context usage when reinitializing a parallel execution context
- Same changePostgreSQL 14.21 · Fix memory context usage when reinitializing a parallel execution context
ImprovementsSet next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases
Changes
Set next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases (Andrey Borodin) § §
The previous logic could get stuck waiting for an update that would never occur.
Related records (4)
- Same changePostgreSQL 18.2 · Set next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases
- Same changePostgreSQL 17.8 · Set next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases
- Same changePostgreSQL 16.12 · Set next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases
- Same changePostgreSQL 14.21 · Set next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases
ImprovementsAvoid rewriting data-modifying CTEs more than once
Changes
Avoid rewriting data-modifying CTEs more than once (Bernice Southey, Dean Rasheed) §
Formerly, when updating an auto-updatable view or a relation with rules, if the original query had any data-modifying CTEs, the rewriter would rewrite those CTEs multiple times due to recursion. This was inefficient and could produce false errors if a CTE included an update of an always-generated column.
Related records (4)
- Same changePostgreSQL 18.2 · Avoid rewriting data-modifying CTEs more than once
- Same changePostgreSQL 17.8 · Avoid rewriting data-modifying CTEs more than once
- Same changePostgreSQL 16.12 · Avoid rewriting data-modifying CTEs more than once
- Same changePostgreSQL 14.21 · Avoid rewriting data-modifying CTEs more than once
ImprovementsFail recovery if WAL does not exist back to the redo point indicated by the checkpoint record
Changes
Fail recovery if WAL does not exist back to the redo point indicated by the checkpoint record (Nitin Jadhav) §
Add an explicit check for this before starting recovery, so that no harm is done and a useful error message is provided. Previously, recovery might crash or corrupt the database in this situation.
Related records (4)
- Same changePostgreSQL 18.2 · Fail recovery if WAL does not exist back to the redo point indicated by the checkpoint record
- Same changePostgreSQL 17.8 · Fail recovery if WAL does not exist back to the redo point indicated by the checkpoint record
- Same changePostgreSQL 16.12 · Fail recovery if WAL does not exist back to the redo point indicated by the checkpoint record
- Same changePostgreSQL 14.21 · Fail recovery if WAL does not exist back to the redo point indicated by the checkpoint record
ImprovementsAvoid scribbling on the source query tree during ALTER PUBLICATION
Changes
Avoid scribbling on the source query tree during ALTER PUBLICATION (Sunil S) §
This error had the visible effect that an event trigger fired for the query would see only the first publish option, even if several had been specified. If such a query were set up as a prepared statement, re-executions would misbehave too.
Related records (4)
- Same changePostgreSQL 18.2 · Avoid scribbling on the source query tree during ALTER PUBLICATION
- Same changePostgreSQL 17.8 · Avoid scribbling on the source query tree during ALTER PUBLICATION
- Same changePostgreSQL 16.12 · Avoid scribbling on the source query tree during ALTER PUBLICATION
- Same changePostgreSQL 14.21 · Avoid scribbling on the source query tree during ALTER PUBLICATION
ImprovementsPass connection options specified in CREATE SUBSCRIPTION ... CONNECTION to the publisher's walsender
Changes
Pass connection options specified in CREATE SUBSCRIPTION ... CONNECTION to the publisher's walsender (Fujii Masao) §
Before this fix, the options connection option (if any) was ignored, thus for example preventing setting custom server parameter values in the walsender session. It was intended for that to work, and it did work before refactoring in PostgreSQL version 15 broke it, so restore the previous behavior.
Related records (3)
- Same changePostgreSQL 18.2 · Pass connection options specified in CREATE SUBSCRIPTION ... CONNECTION to the publisher's walsender
- Same changePostgreSQL 17.8 · Pass connection options specified in CREATE SUBSCRIPTION ... CONNECTION to the publisher's walsender
- Same changePostgreSQL 16.12 · Pass connection options specified in CREATE SUBSCRIPTION ... CONNECTION to the publisher's walsender
ImprovementsPrevent invalidation of newly created or newly synced replication slots
Changes
Prevent invalidation of newly created or newly synced replication slots (Zhijie Hou) §
A race condition with a concurrent checkpoint could allow WAL to be removed that is needed by the replication slot, causing the slot to immediately get marked invalid.
Related records (4)
- Same changePostgreSQL 18.2 · Prevent invalidation of newly created or newly synced replication slots
- Same changePostgreSQL 17.8 · Prevent invalidation of newly created or newly synced replication slots
- Same changePostgreSQL 16.12 · Prevent invalidation of newly created or newly synced replication slots
- Same changePostgreSQL 14.21 · Prevent invalidation of newly created or newly synced replication slots
Bug fixesFix race condition in computing a replication slot's required xmin
Changes
Fix race condition in computing a replication slot's required xmin (Zhijie Hou) §
This could lead to the error “cannot build an initial slot snapshot as oldest safe xid follows snapshot's xmin”.
Related records (4)
- Same changePostgreSQL 18.2 · Fix race condition in computing a replication slot's required xmin
- Same changePostgreSQL 17.8 · Fix race condition in computing a replication slot's required xmin
- Same changePostgreSQL 16.12 · Fix race condition in computing a replication slot's required xmin
- Same changePostgreSQL 14.21 · Fix race condition in computing a replication slot's required xmin
ImprovementsDuring initial synchronization of a logical replication subscription, commit the addition of a pg_replication_origin entry before starting to copy data
Changes
During initial synchronization of a logical replication subscription, commit the addition of a pg_replication_origin entry before starting to copy data (Zhijie Hou) §
Previously, if the copy step failed, the new pg_replication_origin entry would be lost due to transaction rollback. This led to inconsistent state in shared memory.
Related records (4)
- Same changePostgreSQL 18.2 · During initial synchronization of a logical replication subscription, commit the addition of a pg_replication_origin entry before starting to copy data
- Same changePostgreSQL 17.8 · During initial synchronization of a logical replication subscription, commit the addition of a pg_replication_origin entry before starting to copy data
- Same changePostgreSQL 16.12 · During initial synchronization of a logical replication subscription, commit the addition of a pg_replication_origin entry before starting to copy data
- Same changePostgreSQL 14.21 · During initial synchronization of a logical replication subscription, commit the addition of a pg_replication_origin entry before starting to copy data
Bug fixesFix possible failure with “unexpected data beyond EOF” during restart of a streaming replica server
Changes
Fix possible failure with “unexpected data beyond EOF” during restart of a streaming replica server (Anthonin Bonnefoy) §
Related records (4)
- Same changePostgreSQL 18.2 · Fix possible failure with “unexpected data beyond EOF” during restart of a streaming replica server
- Same changePostgreSQL 17.8 · Fix possible failure with “unexpected data beyond EOF” during restart of a streaming replica server
- Same changePostgreSQL 16.12 · Fix possible failure with “unexpected data beyond EOF” during restart of a streaming replica server
- Same changePostgreSQL 14.21 · Fix possible failure with “unexpected data beyond EOF” during restart of a streaming replica server
Bug fixesFix erroneous tracking of column position when parsing partition range bounds
Changes
Fix erroneous tracking of column position when parsing partition range bounds (myzhen) §
This could, for example, lead to the wrong column name being cited in error messages about casting partition bound values to the column's data type.
Related records (4)
- Same changePostgreSQL 18.2 · Fix erroneous tracking of column position when parsing partition range bounds
- Same changePostgreSQL 17.8 · Fix erroneous tracking of column position when parsing partition range bounds
- Same changePostgreSQL 16.12 · Fix erroneous tracking of column position when parsing partition range bounds
- Same changePostgreSQL 14.21 · Fix erroneous tracking of column position when parsing partition range bounds
Bug fixesFix assorted minor errors in error messages
Bug fixesFix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later
Changes
Fix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later (Anthonin Bonnefoy) §
Related records (4)
- Same changePostgreSQL 18.2 · Fix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later
- Same changePostgreSQL 17.8 · Fix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later
- Same changePostgreSQL 16.12 · Fix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later
- Same changePostgreSQL 14.21 · Fix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later
ImprovementsAdjust our JIT code to work with LLVM 21
Changes
Adjust our JIT code to work with LLVM 21 (Holger Hoffstätte) §
The previous coding failed to compile on aarch64 machines.
Related records (4)
ImprovementsSupport process title changes on GNU/Hurd
ImprovementsMake pg_resetwal print the updated value when changing OldestXID
Changes
Make pg_resetwal print the updated value when changing OldestXID (Heikki Linnakangas) §
It already did that for every other variable it can change.
Related records (4)
- Same changePostgreSQL 18.2 · Make pg_resetwal print the updated value when changing OldestXID
- Same changePostgreSQL 17.8 · Make pg_resetwal print the updated value when changing OldestXID
- Same changePostgreSQL 16.12 · Make pg_resetwal print the updated value when changing OldestXID
- Same changePostgreSQL 14.21 · Make pg_resetwal print the updated value when changing OldestXID
ImprovementsMake pg_resetwal allow setting next multixact xid to 0 or next multixact offset to UINT32_MAX
Changes
Make pg_resetwal allow setting next multixact xid to 0 or next multixact offset to UINT32_MAX (Maxim Orlov) §
These are valid values, so rejecting them was incorrect. In the worst case, if a pg_upgrade is attempted when exactly at the point of multixact wraparound, the upgrade would fail.
Related records (3)
- Same changePostgreSQL 18.2 · Make pg_resetwal allow setting next multixact xid to 0 or next multixact offset to UINT32_MAX
- Same changePostgreSQL 17.8 · Make pg_resetwal allow setting next multixact xid to 0 or next multixact offset to UINT32_MAX
- Same changePostgreSQL 16.12 · Make pg_resetwal allow setting next multixact xid to 0 or next multixact offset to UINT32_MAX
Bug fixesIn contrib/amcheck, use the correct snapshot for btree index parent checks
Changes
In contrib/amcheck, use the correct snapshot for btree index parent checks (Mihail Nikalayeu) §
The previous coding caused spurious errors when examining indexes created with CREATE INDEX CONCURRENTLY.
Related records (4)
- Same changePostgreSQL 18.2 · In contrib/amcheck, use the correct snapshot for btree index parent checks
- Same changePostgreSQL 17.8 · In contrib/amcheck, use the correct snapshot for btree index parent checks
- Same changePostgreSQL 16.12 · In contrib/amcheck, use the correct snapshot for btree index parent checks
- Same changePostgreSQL 14.21 · In contrib/amcheck, use the correct snapshot for btree index parent checks
Bug fixesFix contrib/amcheck to handle “half-dead” btree index pages correctly
Changes
Fix contrib/amcheck to handle “half-dead” btree index pages correctly (Heikki Linnakangas) §
amcheck expected such a page to have a parent downlink, but it does not, leading to a false error report about “mismatch between parent key and child high key”.
Related records (4)
- Same changePostgreSQL 18.2 · Fix contrib/amcheck to handle “half-dead” btree index pages correctly
- Same changePostgreSQL 17.8 · Fix contrib/amcheck to handle “half-dead” btree index pages correctly
- Same changePostgreSQL 16.12 · Fix contrib/amcheck to handle “half-dead” btree index pages correctly
- Same changePostgreSQL 14.21 · Fix contrib/amcheck to handle “half-dead” btree index pages correctly
Bug fixesFix contrib/amcheck to handle incomplete btree root page splits correctly
Changes
Fix contrib/amcheck to handle incomplete btree root page splits correctly (Heikki Linnakangas) §
amcheck could report a false error about “block is not true root”.
Related records (4)
- Same changePostgreSQL 18.2 · Fix contrib/amcheck to handle incomplete btree root page splits correctly
- Same changePostgreSQL 17.8 · Fix contrib/amcheck to handle incomplete btree root page splits correctly
- Same changePostgreSQL 16.12 · Fix contrib/amcheck to handle incomplete btree root page splits correctly
- Same changePostgreSQL 14.21 · Fix contrib/amcheck to handle incomplete btree root page splits correctly
Bug fixesFix edge-case integer overflow in contrib/intarray's selectivity estimator for @@
Changes
Fix edge-case integer overflow in contrib/intarray's selectivity estimator for @@ (Chao Li) §
This could cause poor selectivity estimates to be produced for cases involving the maximum integer value.
Related records (4)
- Same changePostgreSQL 18.2 · Fix edge-case integer overflow in contrib/intarray's selectivity estimator for @@
- Same changePostgreSQL 17.8 · Fix edge-case integer overflow in contrib/intarray's selectivity estimator for @@
- Same changePostgreSQL 16.12 · Fix edge-case integer overflow in contrib/intarray's selectivity estimator for @@
- Same changePostgreSQL 14.21 · Fix edge-case integer overflow in contrib/intarray's selectivity estimator for @@
Bug fixesFix multibyte-encoding issue in contrib/ltree
Changes
Fix multibyte-encoding issue in contrib/ltree (Jeff Davis) §
The previous coding could pass an incomplete multibyte character to lower(), probably resulting in incorrect behavior.
Related records (4)
ImprovementsUpdate time zone data files to tzdata release 2025c
Changes
Update time zone data files to tzdata release 2025c (Tom Lane) §
The only change is in historical data for pre-1976 timestamps in Baja California.
Related records (4)
- Same changePostgreSQL 18.2 · Update time zone data files to tzdata release 2025c
- Same changePostgreSQL 17.8 · Update time zone data files to tzdata release 2025c
- Same changePostgreSQL 16.12 · Update time zone data files to tzdata release 2025c
- Same changePostgreSQL 14.21 · Update time zone data files to tzdata release 2025c
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.