Jump to:
⇑ Upgrade to 12.2 released on 2020-02-13 - docs
Fix possible crash or data corruption when a logical replication subscriber processes a row update (Tom Lane, Tomas Vondra)
This bug caused visible problems only if the subscriber's table contained columns that were not being copied from the publisher and had pass-by-reference data types.
⇑ Upgrade to 13 released on 2020-09-24 - docs
Use the glibc version in some cases as a collation version identifier (Thomas Munro)
If the glibc version changes, a warning will be issued about possible corruption of collation-dependent indexes.
⇑ Upgrade to 14 released on 2021-09-30 - docs
Add contrib module pg_surgery which allows changes to row visibility (Ashutosh Sharma)
This is useful for correcting database corruption.
⇑ Upgrade to 14.1 released on 2021-11-11 - docs
Fix corruption of parse tree while creating a range type (Alex Kozhemyakin, Sergey Shinderuk)
CREATE TYPE incorrectly freed an element of the parse tree, which could cause problems for a later event trigger, or if the CREATE TYPE command was stored in the plan cache and used again later.
Ensure that prepared transactions are properly accounted for during promotion of a standby server (Michael Paquier, Andres Freund)
There was a narrow window where a prepared transaction could be omitted from a snapshot taken by a concurrently-running session. If that session then used the snapshot to perform data updates, erroneous results or data corruption could occur.
Add more defensive checks around B-tree posting list splits (Peter Geoghegan)
This change should help detect index corruption involving duplicate table TIDs.
⇑ Upgrade to 14.2 released on 2022-02-10 - docs
Fix corruption of HOT chains when a RECENTLY_DEAD tuple changes state to fully DEAD during page pruning (Andres Freund)
It was possible for VACUUM to remove a recently-dead tuple while leaving behind a redirect item that pointed to it. When the tuple's item slot is later re-used by some new tuple, that tuple would be seen as part of the pre-existing HOT chain, creating a form of index corruption. If this has happened, reindexing the table should repair the damage. However, this is an extremely low-probability scenario, so we do not recommend reindexing just on the chance that it might have happened.
⇑ Upgrade to 14.4 released on 2022-06-16 - docs
Prevent possible corruption of indexes created or rebuilt with the CONCURRENTLY option (Álvaro Herrera)
An optimization added in v14 caused CREATE INDEX ... CONCURRENTLY and REINDEX ... CONCURRENTLY to sometimes miss indexing rows that were updated during the index build. Revert that optimization. It is recommended that any indexes made with the CONCURRENTLY option be rebuilt after installing this update. (Alternatively, rebuild them without CONCURRENTLY.)
⇑ Upgrade to 15 released on 2022-10-13 - docs
Record and check the collation version of each database (Peter Eisentraut)
This feature is designed to detect collation version changes to avoid index corruption. Function pg_database_collation_actual_version() reports the underlying operating system collation version, and ALTER DATABASE ... REFRESH sets the recorded database collation version to match the operating system collation version.
⇑ Upgrade to 15.1 released on 2022-11-10 - docs
Add plan-time check for attempted access to a table that has no table access method (Tom Lane)
This prevents a crash in some catalog-corruption scenarios, for example use of a view whose ON SELECT rule is missing.
⇑ Upgrade to 15.2 released on 2023-02-09 - docs
Fix edge-case data corruption in parallel hash joins (Dmitry Astapov)
If the final chunk of a large tuple being written out to a temporary file was exactly 32760 bytes, it would be corrupted due to a fencepost bug. The query would typically fail later with corrupted-data symptoms.
Fix possible corruption of very large tablespace map files in pg_basebackup (Antonin Houska)
⇑ Upgrade to 15.3 released on 2023-05-11 - docs
Fix potential corruption of the template (source) database after CREATE DATABASE with the STRATEGY WAL_LOG option (Nathan Bossart, Ryo Matsumura)
Improper buffer handling created a risk that any later modification of the template's pg_class catalog would be lost.
Fix data corruption due to vacuum_defer_cleanup_age being larger than the current 64-bit xid (Andres Freund)
In v14 and later with non-default settings of vacuum_defer_cleanup_age, it was possible to compute a very large vacuum cleanup horizon xid, leading to vacuum removing rows that are still live. v12 and v13 have a lesser form of the same problem affecting only GiST indexes, which could lead to index pages getting recycled too early.
Fix data structure corruption during parsing of serial SEQUENCE NAME options (David Rowley)
This can lead to trouble if an event trigger captures the corrupted parse tree.
Fix possible data corruption in ecpg programs built with the -C ORACLE option (Kyotaro Horiguchi)
When ecpg_get_data() is called with varcharsize set to zero, it could write a terminating zero character into the last byte of the preceding field, truncating the data in that field.
In contrib/amcheck, deal sanely with xids that appear to be before epoch zero (Andres Freund)
In cases of corruption we might see a wrapped-around 32-bit xid that appears to be before the first xid epoch. Promoting such a value to 64-bit form produced a value far in the future, resulting in wrong reports. Return FirstNormalFullTransactionId in such cases so that things work reasonably sanely.
⇑ Upgrade to 15.4 released on 2023-08-10 - docs
Allow VACUUM to continue after detecting certain types of b-tree index corruption (Peter Geoghegan)
If an invalid sibling-page link is detected, log the issue and press on, rather than throwing an error as before. Nothing short of REINDEX will fix the broken index, but preventing VACUUM from completing until that is done risks making matters far worse.
⇑ Upgrade to 16.1 released on 2023-11-09 - docs
In contrib/amcheck, do not report interrupted page deletion as corruption (Noah Misch)
This fix prevents false-positive reports of “the first child of leftmost target page is not leftmost of its level”, “block NNNN is not leftmost” or “left link/right link pair in index XXXX not in agreement”. They appeared if amcheck ran after an unfinished btree index page deletion and before VACUUM had cleaned things up.
⇑ Upgrade to 16.2 released on 2024-02-08 - docs
Fix corruption of local buffer state when an error occurs while trying to extend a temporary table (Tender Wang)
Fix insufficient locking when cleaning up an incomplete split of a GIN index's internal page (Fei Changhong, Heikki Linnakangas)
The code tried to do this with shared rather than exclusive lock on the buffer. This could lead to index corruption if two processes attempted the cleanup concurrently.
⇑ Upgrade to 17.1 released on 2024-11-14 - docs
Fix test for C locale when LC_COLLATE is different from LC_CTYPE (Jeff Davis) §
When using libc as the default collation provider, the test to see if C locale is in use for collation accidentally checked LC_CTYPE not LC_COLLATE. This has no impact in the typical case where those settings are the same, nor if both are not C (nor its alias POSIX). However, if LC_CTYPE is C while LC_COLLATE is some other locale, wrong query answers could ensue, and corruption of indexes on strings was possible. Users of databases with such settings should reindex affected indexes after installing this update. The converse case with LC_COLLATE being C while LC_CTYPE is some other locale would cause performance degradation, but no actual errors.
Fix ways in which an “in place” catalog update could be lost (Noah Misch) § § § § § § §
Normal row updates write a new version of the row to preserve rollback-ability of the transaction. However, certain system catalog updates are intentionally non-transactional and are done with an in-place update of the row. These patches fix race conditions that could cause the effects of an in-place update to be lost. As an example, it was possible to forget having set pg_class.relhasindex to true, preventing updates of the new index and thus causing index corruption.
⇑ Upgrade to 17.3 released on 2025-02-13 - docs
Prevent possible catalog corruption when a system catalog is vacuumed concurrently with an update (Noah Misch) § §
Fix data corruption when relation truncation fails (Thomas Munro) § § §
The filesystem calls needed to perform relation truncation could fail, leaving inconsistent state on disk (for example, effectively reviving deleted data). We can't really prevent that, but we can recover by dint of making such failures into PANICs, so that consistency is restored by replaying from WAL up to just before the attempted truncation. This isn't a hugely desirable behavior, but such failures are rare enough that it seems an acceptable solution.
Prevent checkpoints from starting during relation truncation (Robert Haas) §
This avoids a race condition wherein the modified file might not get fsync'd before completing the checkpoint, creating a risk of data corruption if the operating system crashes soon after.
⇑ Upgrade to 17.5 released on 2025-05-08 - docs
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.
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.
⇑ Upgrade to 18.4 released on 2026-05-14 - docs
Prevent bloating relation visibility maps during restore of an incremental backup (Robert Haas) §
Restore could append many blocks of zeroes to a visibility map, due to incorrect computation of the expected file length. This does not result in data corruption, but it could waste a substantial amount of disk space.