DocumentationVersion comparison
POSTGRESQL · VERSION COMPARE
PostgreSQL 13.21 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
13.21
2025-05-08
13.21stableSupport ends 2025-11-13
Security changes
| CVE / issue | Severity | Fixed version | Selection status |
|---|---|---|---|
| CVE-2025-4207 Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding | 13.21 | Recorded fix |
PostgreSQL 13.21
Migration and compatibility
A dump/restore is not required for those running 13.X.
However, if you have any self-referential foreign key constraints on partitioned tables, it may be necessary to recreate those constraints to ensure that they are being enforced correctly. See the second changelog entry below.
Also, if you are upgrading from a version earlier than 13.17, see Section E.7.
SecurityAvoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding
Changes
Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding (Noah Misch, Andres Freund) § §
While unlikely, a SIGSEGV crash could occur if an incomplete multibyte character appeared at the end of memory. This was possible both in the server and in libpq-using applications. (CVE-2025-4207)
Related records (4)
- Same changePostgreSQL 17.5 · Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding
- Same changePostgreSQL 16.9 · Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding
- Same changePostgreSQL 15.13 · Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding
- Same changePostgreSQL 14.18 · Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding
ImprovementsHandle self-referential foreign keys on partitioned tables correctly
Changes
Handle self-referential foreign keys on partitioned tables correctly (Álvaro Herrera) §
Creating or attaching partitions failed to make the required catalog entries for a foreign-key constraint, if the table referenced by the constraint was the same partitioned table. This resulted in failure to enforce the constraint fully.
To fix this, you should drop and recreate any self-referential foreign keys on partitioned tables, if partitions have been created or attached since the constraint was created. Bear in mind that violating rows might already be present, in which case recreating the constraint will fail, and you'll need to fix up those rows before trying again.
Related records (4)
- Same changePostgreSQL 17.5 · Handle self-referential foreign keys on partitioned tables correctly
- Same changePostgreSQL 16.9 · Handle self-referential foreign keys on partitioned tables correctly
- Same changePostgreSQL 15.13 · Handle self-referential foreign keys on partitioned tables correctly
- Same changePostgreSQL 14.18 · Handle self-referential foreign keys on partitioned tables correctly
Bug fixesFix unexpected “attribute has wrong type” errors in UPDATE, DELETE, and MERGE queries that use whole-row table references to views or functions in FROM
Changes
Fix unexpected “attribute has wrong type” errors in UPDATE, DELETE, and MERGE queries that use whole-row table references to views or functions in FROM (Tom Lane) § § §
Related records (4)
- Same changePostgreSQL 17.5 · Fix unexpected “attribute has wrong type” errors in UPDATE, DELETE, and MERGE queries that use whole-row table references to views or functions in FROM
- Same changePostgreSQL 16.9 · Fix unexpected “attribute has wrong type” errors in UPDATE, DELETE, and MERGE queries that use whole-row table references to views or functions in FROM
- Same changePostgreSQL 15.13 · Fix unexpected “attribute has wrong type” errors in UPDATE, DELETE, and MERGE queries that use whole-row table references to views or functions in FROM
- Same changePostgreSQL 14.18 · Fix unexpected “attribute has wrong type” errors in UPDATE, DELETE, and MERGE queries that use whole-row table references to views or functions in FROM
ImprovementsCorrectly process references to outer CTE names that appear within a WITH clause attached to an INSERT/UPDATE/DELETE/MERGE command that's inside WITH
Changes
Correctly process references to outer CTE names that appear within a WITH clause attached to an INSERT/UPDATE/DELETE/MERGE command that's inside WITH (Tom Lane) §
The parser failed to detect disallowed recursion cases, nor did it account for such references when sorting CTEs into a usable order.
Related records (4)
- Same changePostgreSQL 17.5 · Correctly process references to outer CTE names that appear within a WITH clause attached to an INSERT/UPDATE/DELETE/MERGE command that's inside WITH
- Same changePostgreSQL 16.9 · Correctly process references to outer CTE names that appear within a WITH clause attached to an INSERT/UPDATE/DELETE/MERGE command that's inside WITH
- Same changePostgreSQL 15.13 · Correctly process references to outer CTE names that appear within a WITH clause attached to an INSERT/UPDATE/DELETE/MERGE command that's inside WITH
- Same changePostgreSQL 14.18 · Correctly process references to outer CTE names that appear within a WITH clause attached to an INSERT/UPDATE/DELETE/MERGE command that's inside WITH
Bug fixesFix ARRAY(subquery) and ARRAY[expression, ...] constructs to produce sane results when the input is of type int2vector or oidvector
Changes
Fix ARRAY( and subquery)ARRAY[ constructs to produce sane results when the input is of type expression, ...]int2vector or oidvector (Tom Lane) §
This patch restores the behavior that existed before PostgreSQL 9.5: the result is of type int2vector[] or oidvector[].
Related records (4)
- Same changePostgreSQL 17.5 · Fix ARRAY(subquery) and ARRAY[expression, ...] constructs to produce sane results when the input is of type int2vector or oidvector
- Same changePostgreSQL 16.9 · Fix ARRAY(subquery) and ARRAY[expression, ...] constructs to produce sane results when the input is of type int2vector or oidvector
- Same changePostgreSQL 15.13 · Fix ARRAY(subquery) and ARRAY[expression, ...] constructs to produce sane results when the input is of type int2vector or oidvector
- Same changePostgreSQL 14.18 · Fix ARRAY(subquery) and ARRAY[expression, ...] constructs to produce sane results when the input is of type int2vector or oidvector
Bug fixesFix possible erroneous reports of invalid affixes while parsing Ispell dictionaries
Changes
Fix possible erroneous reports of invalid affixes while parsing Ispell dictionaries (Jacob Brazeal) §
Related records (4)
- Same changePostgreSQL 17.5 · Fix possible erroneous reports of invalid affixes while parsing Ispell dictionaries
- Same changePostgreSQL 16.9 · Fix possible erroneous reports of invalid affixes while parsing Ispell dictionaries
- Same changePostgreSQL 15.13 · Fix possible erroneous reports of invalid affixes while parsing Ispell dictionaries
- Same changePostgreSQL 14.18 · Fix possible erroneous reports of invalid affixes while parsing Ispell dictionaries
Bug fixesFix ALTER TABLE ADD COLUMN to correctly handle the case of a domain type that has a default
Changes
Fix ALTER TABLE ADD COLUMN to correctly handle the case of a domain type that has a default (Jian He, Tom Lane, Tender Wang) § §
If a domain type has a default, adding a column of that type (without any explicit DEFAULT clause) failed to install the domain's default value in existing rows, instead leaving the new column null.
Related records (4)
- Same changePostgreSQL 17.5 · Fix ALTER TABLE ADD COLUMN to correctly handle the case of a domain type that has a default
- Same changePostgreSQL 16.9 · Fix ALTER TABLE ADD COLUMN to correctly handle the case of a domain type that has a default
- Same changePostgreSQL 15.13 · Fix ALTER TABLE ADD COLUMN to correctly handle the case of a domain type that has a default
- Same changePostgreSQL 14.18 · Fix ALTER TABLE ADD COLUMN to correctly handle the case of a domain type that has a default
ImprovementsImprove the error message for disallowed attempts to alter the properties of a foreign key constraint
Changes
Improve the error message for disallowed attempts to alter the properties of a foreign key constraint (Álvaro Herrera) §
Related records (4)
- Same changePostgreSQL 17.5 · Improve the error message for disallowed attempts to alter the properties of a foreign key constraint
- Same changePostgreSQL 16.9 · Improve the error message for disallowed attempts to alter the properties of a foreign key constraint
- Same changePostgreSQL 15.13 · Improve the error message for disallowed attempts to alter the properties of a foreign key constraint
- Same changePostgreSQL 14.18 · Improve the error message for disallowed attempts to alter the properties of a foreign key constraint
ImprovementsAvoid error when resetting the relhassubclass flag of a temporary table that's marked ON COMMIT DELETE ROWS
Changes
Avoid error when resetting the relhassubclass flag of a temporary table that's marked ON COMMIT DELETE ROWS (Noah Misch) §
Related records (4)
- Same changePostgreSQL 17.5 · Avoid error when resetting the relhassubclass flag of a temporary table that's marked ON COMMIT DELETE ROWS
- Same changePostgreSQL 16.9 · Avoid error when resetting the relhassubclass flag of a temporary table that's marked ON COMMIT DELETE ROWS
- Same changePostgreSQL 15.13 · Avoid error when resetting the relhassubclass flag of a temporary table that's marked ON COMMIT DELETE ROWS
- Same changePostgreSQL 14.18 · Avoid error when resetting the relhassubclass flag of a temporary table that's marked ON COMMIT DELETE ROWS
ImprovementsDisable “skip fetch” optimization in bitmap heap scan
Changes
Disable “skip fetch” optimization in bitmap heap scan (Matthias van de Meent) §
It turns out that this optimization can result in returning dead tuples when a concurrent vacuum marks a page all-visible.
Related records (4)
- Same changePostgreSQL 17.5 · Disable “skip fetch” optimization in bitmap heap scan
- Same changePostgreSQL 16.9 · Disable “skip fetch” optimization in bitmap heap scan
- Same changePostgreSQL 15.13 · Disable “skip fetch” optimization in bitmap heap scan
- Same changePostgreSQL 14.18 · Disable “skip fetch” optimization in bitmap heap scan
Bug fixesFix performance issues in GIN index search startup when there are many search keys
Changes
Fix performance issues in GIN index search startup when there are many search keys (Tom Lane, Vinod Sridharan) § §
An indexable clause with many keys (for example, jsonbcol ?| array[...] with tens of thousands of array elements) took O(N2) time to start up, and was uncancelable for that interval too.
Related records (4)
- Same changePostgreSQL 17.5 · Fix performance issues in GIN index search startup when there are many search keys
- Same changePostgreSQL 16.9 · Fix performance issues in GIN index search startup when there are many search keys
- Same changePostgreSQL 15.13 · Fix performance issues in GIN index search startup when there are many search keys
- Same changePostgreSQL 14.18 · Fix performance issues in GIN index search startup when there are many search keys
ImprovementsDetect missing support procedures in a BRIN index operator class, and report an error instead of crashing
Changes
Detect missing support procedures in a BRIN index operator class, and report an error instead of crashing (Álvaro Herrera) §
Related records (4)
- Same changePostgreSQL 17.5 · Detect missing support procedures in a BRIN index operator class, and report an error instead of crashing
- Same changePostgreSQL 16.9 · Detect missing support procedures in a BRIN index operator class, and report an error instead of crashing
- Same changePostgreSQL 15.13 · Detect missing support procedures in a BRIN index operator class, and report an error instead of crashing
- Same changePostgreSQL 14.18 · Detect missing support procedures in a BRIN index operator class, and report an error instead of crashing
Bug fixesFix race condition in handling of synchronous_standby_names immediately after startup
Changes
Fix race condition in handling of synchronous_standby_names immediately after startup (Melnikov Maksim, Michael Paquier) §
For a short period after system startup, backends might fail to wait for synchronous commit even though synchronous_standby_names is enabled.
Related records (4)
- Same changePostgreSQL 17.5 · Fix race condition in handling of synchronous_standby_names immediately after startup
- Same changePostgreSQL 16.9 · Fix race condition in handling of synchronous_standby_names immediately after startup
- Same changePostgreSQL 15.13 · Fix race condition in handling of synchronous_standby_names immediately after startup
- Same changePostgreSQL 14.18 · Fix race condition in handling of synchronous_standby_names immediately after startup
Bug fixesFix pg_strtof() to not crash with null endptr
Changes
Fix pg_strtof() to not crash with null endptr (Alexander Lakhin, Tom Lane) §
Related records (4)
Bug fixesAvoid crash when a Snowball stemmer encounters an out-of-memory condition
Changes
Avoid crash when a Snowball stemmer encounters an out-of-memory condition (Maksim Korotkov) §
Related records (5)
- Related commitsPostgreSQL 18.0 · Add full text search stemming for Estonian
- Same changePostgreSQL 17.5 · Avoid crash when a Snowball stemmer encounters an out-of-memory condition
- Same changePostgreSQL 16.9 · Avoid crash when a Snowball stemmer encounters an out-of-memory condition
- Same changePostgreSQL 15.13 · Avoid crash when a Snowball stemmer encounters an out-of-memory condition
- Same changePostgreSQL 14.18 · Avoid crash when a Snowball stemmer encounters an out-of-memory condition
Bug fixesSkip WAL recycling and preallocation during archive recovery, to avoid corruption of WAL files that were restored from the archive
Changes
Skip WAL recycling and preallocation during archive recovery, to avoid corruption of WAL files that were restored from the archive (Noah Misch, Arun Thirupathi) § § § § § § §
This change back-patches v15-era fixes that were considered largely cosmetic at the time, but turn out to prevent data corruption in the wake of subsequent fixes.
ImprovementsPrevent over-advancement of catalog xmin in “fast forward” mode of logical decoding
Changes
Prevent over-advancement of catalog xmin in “fast forward” mode of logical decoding (Zhijie Hou) §
This mistake could allow deleted catalog entries to be vacuumed away even though they were still potentially needed by the WAL-reading process.
Related records (4)
- Same changePostgreSQL 17.5 · Prevent over-advancement of catalog xmin in “fast forward” mode of logical decoding
- Same changePostgreSQL 16.9 · Prevent over-advancement of catalog xmin in “fast forward” mode of logical decoding
- Same changePostgreSQL 15.13 · Prevent over-advancement of catalog xmin in “fast forward” mode of logical decoding
- Same changePostgreSQL 14.18 · Prevent over-advancement of catalog xmin in “fast forward” mode of logical decoding
ImprovementsAvoid data loss when DDL operations that don't take a strong lock affect tables that are being logically replicated
Changes
Avoid data loss when DDL operations that don't take a strong lock affect tables that are being logically replicated (Shlok Kyal, Hayato Kuroda) § §
The catalog changes caused by the DDL command were not reflected into WAL-decoding processes, allowing them to decode subsequent changes using stale catalog data, probably resulting in data corruption.
Related records (4)
- Same changePostgreSQL 17.5 · Avoid data loss when DDL operations that don't take a strong lock affect tables that are being logically replicated
- Same changePostgreSQL 16.9 · Avoid data loss when DDL operations that don't take a strong lock affect tables that are being logically replicated
- Same changePostgreSQL 15.13 · Avoid data loss when DDL operations that don't take a strong lock affect tables that are being logically replicated
- Same changePostgreSQL 14.18 · Avoid data loss when DDL operations that don't take a strong lock affect tables that are being logically replicated
ImprovementsAvoid duplicate snapshot creation in logical replication index lookups
Changes
Related records (4)
- Same changePostgreSQL 17.5 · Avoid duplicate snapshot creation in logical replication index lookups
- Same changePostgreSQL 16.9 · Avoid duplicate snapshot creation in logical replication index lookups
- Same changePostgreSQL 15.13 · Avoid duplicate snapshot creation in logical replication index lookups
- Same changePostgreSQL 14.18 · Avoid duplicate snapshot creation in logical replication index lookups
Bug fixesFix overly-strict assertion in gistFindCorrectParent()
Changes
Fix overly-strict assertion in gistFindCorrectParent() (Heikki Linnakangas) §
Related records (4)
- Same changePostgreSQL 17.5 · Fix overly-strict assertion in gistFindCorrectParent()
- Same changePostgreSQL 16.9 · Fix overly-strict assertion in gistFindCorrectParent()
- Same changePostgreSQL 15.13 · Fix overly-strict assertion in gistFindCorrectParent()
- Same changePostgreSQL 14.18 · Fix overly-strict assertion in gistFindCorrectParent()
ImprovementsIn PL/pgSQL, avoid “unexpected plan node type” error when a scrollable cursor is defined on a simple SELECT expression query
Changes
In PL/pgSQL, avoid “unexpected plan node type” error when a scrollable cursor is defined on a simple SELECT query (Andrei Lepikhov) §expression
Related records (4)
- Same changePostgreSQL 17.5 · In PL/pgSQL, avoid “unexpected plan node type” error when a scrollable cursor is defined on a simple SELECT expression query
- Same changePostgreSQL 16.9 · In PL/pgSQL, avoid “unexpected plan node type” error when a scrollable cursor is defined on a simple SELECT expression query
- Same changePostgreSQL 15.13 · In PL/pgSQL, avoid “unexpected plan node type” error when a scrollable cursor is defined on a simple SELECT expression query
- Same changePostgreSQL 14.18 · In PL/pgSQL, avoid “unexpected plan node type” error when a scrollable cursor is defined on a simple SELECT expression query
ImprovementsDon't try to drop individual index partitions in pg_dump's --clean mode
Changes
Don't try to drop individual index partitions in pg_dump's --clean mode (Jian He) §
The server rejects such DROP commands. That has no real consequences, since the partitions will go away anyway in the subsequent DROPs of either their parent tables or their partitioned index. However, the error reported for the attempted drop causes problems when restoring in --single-transaction mode.
Related records (4)
- Same changePostgreSQL 17.5 · Don't try to drop individual index partitions in pg_dump's --clean mode
- Same changePostgreSQL 16.9 · Don't try to drop individual index partitions in pg_dump's --clean mode
- Same changePostgreSQL 15.13 · Don't try to drop individual index partitions in pg_dump's --clean mode
- Same changePostgreSQL 14.18 · Don't try to drop individual index partitions in pg_dump's --clean mode
ImprovementsIn pg_dumpall, avoid emitting invalid role GRANT commands if pg_auth_members contains invalid role OIDs
Changes
In pg_dumpall, avoid emitting invalid role GRANT commands if pg_auth_members contains invalid role OIDs (Tom Lane) §
Instead, print a warning and skip the entry. This copes better with catalog corruption that has been seen to occur in back branches as a result of race conditions between GRANT and DROP ROLE.
Related records (4)
- Same changePostgreSQL 17.5 · In pg_dumpall, avoid emitting invalid role GRANT commands if pg_auth_members contains invalid role OIDs
- Same changePostgreSQL 16.9 · In pg_dumpall, avoid emitting invalid role GRANT commands if pg_auth_members contains invalid role OIDs
- Same changePostgreSQL 15.13 · In pg_dumpall, avoid emitting invalid role GRANT commands if pg_auth_members contains invalid role OIDs
- Same changePostgreSQL 14.18 · In pg_dumpall, avoid emitting invalid role GRANT commands if pg_auth_members contains invalid role OIDs
ImprovementsAllow contrib/dblink queries to be interrupted by query cancel
Bug fixesAvoid crashing with corrupt input data in contrib/pageinspect's heap_page_items()
Changes
Avoid crashing with corrupt input data in contrib/pageinspect's heap_page_items() (Dmitry Kovalenko) §
Related records (4)
- Same changePostgreSQL 17.5 · Avoid crashing with corrupt input data in contrib/pageinspect's heap_page_items()
- Same changePostgreSQL 16.9 · Avoid crashing with corrupt input data in contrib/pageinspect's heap_page_items()
- Same changePostgreSQL 15.13 · Avoid crashing with corrupt input data in contrib/pageinspect's heap_page_items()
- Same changePostgreSQL 14.18 · Avoid crashing with corrupt input data in contrib/pageinspect's heap_page_items()
ImprovementsPrevent assertion failure in contrib/pg_freespacemap's pg_freespacemap()
Changes
Prevent assertion failure in contrib/pg_freespacemap's pg_freespacemap() (Tender Wang) §
Applying pg_freespacemap() to a relation lacking storage (such as a view) caused an assertion failure, although there was no ill effect in non-assert builds. Add an error check to reject that case.
Related records (4)
- Same changePostgreSQL 17.5 · Prevent assertion failure in contrib/pg_freespacemap's pg_freespacemap()
- Same changePostgreSQL 16.9 · Prevent assertion failure in contrib/pg_freespacemap's pg_freespacemap()
- Same changePostgreSQL 15.13 · Prevent assertion failure in contrib/pg_freespacemap's pg_freespacemap()
- Same changePostgreSQL 14.18 · Prevent assertion failure in contrib/pg_freespacemap's pg_freespacemap()
Bug fixesFix build failure on macOS 15.4
Changes
Fix build failure on macOS 15.4 (Tom Lane, Peter Eisentraut) §
This macOS update broke our configuration probe for strchrnul().
Related records (4)
ImprovementsUpdate time zone data files to tzdata release 2025b for DST law changes in Chile, plus historical corrections for Iran
Changes
Update time zone data files to tzdata release 2025b for DST law changes in Chile, plus historical corrections for Iran (Tom Lane) §
There is a new time zone America/Coyhaique for Chile's Aysén Region, to account for it changing to UTC-03 year-round and thus diverging from America/Santiago.
Related records (4)
- Same changePostgreSQL 17.5 · Update time zone data files to tzdata release 2025b for DST law changes in Chile, plus historical corrections for Iran
- Same changePostgreSQL 16.9 · Update time zone data files to tzdata release 2025b for DST law changes in Chile, plus historical corrections for Iran
- Same changePostgreSQL 15.13 · Update time zone data files to tzdata release 2025b for DST law changes in Chile, plus historical corrections for Iran
- Same changePostgreSQL 14.18 · Update time zone data files to tzdata release 2025b for DST law changes in Chile, plus historical corrections for Iran
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.