DocumentationVersion comparison
POSTGRESQL · VERSION COMPARE
PostgreSQL 18.1 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
18.1
2025-11-13
18.1stableSupport ends 2030-11-14
Security changes
| CVE / issue | Severity | Fixed version | Selection status |
|---|---|---|---|
| CVE-2025-12818 Avoid integer overflow in allocation-size calculations within libpq | 18.1 | Recorded fix | |
| CVE-2025-12817 Check for CREATE privileges on the schema in CREATE STATISTICS | 18.1 | Recorded fix |
PostgreSQL 18.1
Migration and compatibility
A dump/restore is not required for those running 18.X.
SecurityCheck for CREATE privileges on the schema in CREATE STATISTICS
Changes
Check for CREATE privileges on the schema in CREATE STATISTICS (Jelte Fennema-Nio) §
This omission allowed table owners to create statistics in any schema, potentially leading to unexpected naming conflicts.
The PostgreSQL Project thanks Jelte Fennema-Nio for reporting this problem. (CVE-2025-12817)
Related records (5)
- Same changePostgreSQL 17.7 · Check for CREATE privileges on the schema in CREATE STATISTICS
- Same changePostgreSQL 16.11 · Check for CREATE privileges on the schema in CREATE STATISTICS
- Same changePostgreSQL 15.15 · Check for CREATE privileges on the schema in CREATE STATISTICS
- Same changePostgreSQL 14.20 · Check for CREATE privileges on the schema in CREATE STATISTICS
- Same changePostgreSQL 13.23 · Check for CREATE privileges on the schema in CREATE STATISTICS
SecurityAvoid integer overflow in allocation-size calculations within libpq
Changes
Avoid integer overflow in allocation-size calculations within libpq (Jacob Champion) §
Several places in libpq were not sufficiently careful about computing the required size of a memory allocation. Sufficiently large inputs could cause integer overflow, resulting in an undersized buffer, which would then lead to writing past the end of the buffer.
The PostgreSQL Project thanks Aleksey Solovev of Positive Technologies for reporting this problem. (CVE-2025-12818)
Related records (5)
- Same changePostgreSQL 17.7 · Avoid integer overflow in allocation-size calculations within libpq
- Same changePostgreSQL 16.11 · Avoid integer overflow in allocation-size calculations within libpq
- Same changePostgreSQL 15.15 · Avoid integer overflow in allocation-size calculations within libpq
- Same changePostgreSQL 14.20 · Avoid integer overflow in allocation-size calculations within libpq
- Same changePostgreSQL 13.23 · Avoid integer overflow in allocation-size calculations within libpq
ImprovementsPrevent “unrecognized node type” errors when a SQL/JSON function such as JSON_VALUE has a DEFAULT clause containing a COLLATE expression
ImprovementsAvoid incorrect optimization of variable-free HAVING clauses with grouping sets
ImprovementsDo not use parallelism in hash right semi joins
Changes
Do not use parallelism in hash right semi joins (Richard Guo) §
The case does not work reliably due to a race condition in updating the join's shared hash table.
ImprovementsAvoid possible division-by-zero when creating ordered-append plans
Changes
Avoid possible division-by-zero when creating ordered-append plans (Richard Guo) §
This mistake could result in incorrect selection of the cheapest path, or in an assertion failure in debug builds.
Bug fixesFix planner failure with index types that can do ordered access but not index-only scans
Changes
Fix planner failure with index types that can do ordered access but not index-only scans (Maxime Schoemans) §
This oversight resulted in errors like “no data returned for index-only scan”. The case does not arise with any in-core index type, but some extensions encountered the problem.
ImprovementsRemove faulty assertion in btree index cleanup
Changes
Remove faulty assertion in btree index cleanup (Peter Geoghegan) §
Related records (5)
- Same changePostgreSQL 17.7 · Remove faulty assertion in btree index cleanup
- Same changePostgreSQL 16.11 · Remove faulty assertion in btree index cleanup
- Same changePostgreSQL 15.15 · Remove faulty assertion in btree index cleanup
- Same changePostgreSQL 14.20 · Remove faulty assertion in btree index cleanup
- Same changePostgreSQL 13.23 · Remove faulty assertion in btree index cleanup
ImprovementsAvoid possible out-of-memory or “invalid memory alloc request size” failures during parallel GIN index build
Changes
Avoid possible out-of-memory or “invalid memory alloc request size” failures during parallel GIN index build (Tomas Vondra) §
ImprovementsEnsure that BRIN autosummarization provides a snapshot for index expressions that need one
Changes
Ensure that BRIN autosummarization provides a snapshot for index expressions that need one (Álvaro Herrera) § §
Previously, autosummarization would fail for such indexes, and then leave placeholder index tuples behind, causing the index to bloat over time.
Related records (5)
- Same changePostgreSQL 17.7 · Ensure that BRIN autosummarization provides a snapshot for index expressions that need one
- Same changePostgreSQL 16.11 · Ensure that BRIN autosummarization provides a snapshot for index expressions that need one
- Same changePostgreSQL 15.15 · Ensure that BRIN autosummarization provides a snapshot for index expressions that need one
- Same changePostgreSQL 14.20 · Ensure that BRIN autosummarization provides a snapshot for index expressions that need one
- Same changePostgreSQL 13.23 · Ensure that BRIN autosummarization provides a snapshot for index expressions that need one
Bug fixesFix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages
Changes
Fix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages (Sunil S) §
This oversight could result in an infinite loop or scanning of unneeded table pages.
Related records (5)
- Same changePostgreSQL 17.7 · Fix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages
- Same changePostgreSQL 16.11 · Fix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages
- Same changePostgreSQL 15.15 · Fix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages
- Same changePostgreSQL 14.20 · Fix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages
- Same changePostgreSQL 13.23 · Fix integer-overflow hazard in BRIN index scans when the table contains close to 232 pages
Bug fixesFix incorrect zero-extension of stored values in JIT-generated tuple deforming code
Changes
Fix incorrect zero-extension of stored values in JIT-generated tuple deforming code (David Rowley) §
When not using JIT, the equivalent code does sign-extension not zero-extension, leading to a different Datum representation of small integer data types. This inconsistency was masked in most cases, but it is known to lead to “could not find memoization table entry” errors when using Memoize plan nodes, and there might be other symptoms.
Related records (5)
- Same changePostgreSQL 17.7 · Fix incorrect zero-extension of stored values in JIT-generated tuple deforming code
- Same changePostgreSQL 16.11 · Fix incorrect zero-extension of stored values in JIT-generated tuple deforming code
- Same changePostgreSQL 15.15 · Fix incorrect zero-extension of stored values in JIT-generated tuple deforming code
- Same changePostgreSQL 14.20 · Fix incorrect zero-extension of stored values in JIT-generated tuple deforming code
- Same changePostgreSQL 13.23 · Fix incorrect zero-extension of stored values in JIT-generated tuple deforming code
Bug fixesFix rare crash when processing hashed GROUPING SETS queries
Changes
Fix rare crash when processing hashed GROUPING SETS queries (David Rowley) §
Bug fixesRepair faulty hash-table-size-choosing logic in hash joins
Changes
Repair faulty hash-table-size-choosing logic in hash joins (Tomas Vondra) §
Hash joins sometimes used more memory than intended, or failed to divide it in an efficient way.
ImprovementsImprove relation lookup logic in statistics manipulation functions
Bug fixesFix incorrect logic for caching result-relation information for triggers
Changes
Fix incorrect logic for caching result-relation information for triggers (David Rowley, Amit Langote) §
In cases where partitions' column sets aren't physically identical to their parent partitioned tables' column sets, this oversight could lead to crashes.
Related records (3)
- Same changePostgreSQL 17.7 · Fix incorrect logic for caching result-relation information for triggers
- Same changePostgreSQL 16.11 · Fix incorrect logic for caching result-relation information for triggers
- Same changePostgreSQL 15.15 · Fix incorrect logic for caching result-relation information for triggers
Bug fixesFix crash during EvalPlanQual rechecks on partitioned tables
Changes
Fix crash during EvalPlanQual rechecks on partitioned tables (David Rowley, Amit Langote) §
Bug fixesFix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ
Changes
Fix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ (Masahiko Sawada, Etsuro Fujita) §
In such cases the foreign or custom access method should be invoked normally, but that did not happen, typically leading to a crash.
Related records (5)
- Same changePostgreSQL 17.7 · Fix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ
- Same changePostgreSQL 16.11 · Fix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ
- Same changePostgreSQL 15.15 · Fix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ
- Same changePostgreSQL 14.20 · Fix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ
- Same changePostgreSQL 13.23 · Fix EvalPlanQual handling of foreign or custom joins that do not have an alternative local-join plan prepared for EPQ
ImprovementsAvoid duplicating hash partition constraints during DETACH CONCURRENTLY
Changes
Avoid duplicating hash partition constraints during DETACH CONCURRENTLY (Haiyang Li) §
ALTER TABLE DETACH PARTITION CONCURRENTLY was written to add a copy of the partitioning constraint to the now-detached partition. This was misguided, partially because non-concurrent DETACH doesn't do that, but mostly because in the case of hash partitioning the constraint expression contains references to the parent table's OID. That causes problems during dump/restore, or if the parent table is dropped after DETACH. In v19 and later, we'll no longer create any such copied constraints at all. In released branches, to minimize the risk of unforeseen consequences, only skip adding a copied constraint if it is for hash partitioning.
Related records (4)
- Same changePostgreSQL 17.7 · Avoid duplicating hash partition constraints during DETACH CONCURRENTLY
- Same changePostgreSQL 16.11 · Avoid duplicating hash partition constraints during DETACH CONCURRENTLY
- Same changePostgreSQL 15.15 · Avoid duplicating hash partition constraints during DETACH CONCURRENTLY
- Same changePostgreSQL 14.20 · Avoid duplicating hash partition constraints during DETACH CONCURRENTLY
ImprovementsDisallow generated columns in partition keys
Changes
Disallow generated columns in partition keys (Jian He, Ashutosh Bapat) §
This was already not allowed, but the check missed some cases, such as where the column reference is implicit in a whole-row reference.
Related records (5)
- Same changePostgreSQL 17.7 · Disallow generated columns in partition keys
- Same changePostgreSQL 16.11 · Disallow generated columns in partition keys
- Same changePostgreSQL 15.15 · Disallow generated columns in partition keys
- Same changePostgreSQL 14.20 · Disallow generated columns in partition keys
- Same changePostgreSQL 13.23 · Disallow generated columns in partition keys
ImprovementsDisallow generated columns in COPY ... FROM ... WHERE clauses
Changes
Disallow generated columns in COPY ... FROM ... WHERE clauses (Peter Eisentraut, Jian He) §
Previously, incorrect behavior or an obscure error message resulted from attempting to reference such a column, since generated columns have not yet been computed at the point where WHERE filtering is done.
Related records (5)
- Same changePostgreSQL 17.7 · Disallow generated columns in COPY ... FROM ... WHERE clauses
- Same changePostgreSQL 16.11 · Disallow generated columns in COPY ... FROM ... WHERE clauses
- Same changePostgreSQL 15.15 · Disallow generated columns in COPY ... FROM ... WHERE clauses
- Same changePostgreSQL 14.20 · Disallow generated columns in COPY ... FROM ... WHERE clauses
- Same changePostgreSQL 13.23 · Disallow generated columns in COPY ... FROM ... WHERE clauses
ImprovementsPrevent setting a column as identity if it has a not-null constraint but the constraint is marked as invalid
Changes
Prevent setting a column as identity if it has a not-null constraint but the constraint is marked as invalid (Jian He) §
Identity columns must be not-null, but the check for that missed this edge case.
ImprovementsAvoid potential use-after-free in parallel vacuum
Changes
Avoid potential use-after-free in parallel vacuum (Kevin Oommen Anish) §
This bug seems to have no consequences in standard builds, but it's theoretically a hazard.
Related records (1)
Bug fixesFix visibility checking for statistics objects in pg_temp
Changes
Fix visibility checking for statistics objects in pg_temp (Noah Misch) §
A statistics object located in a temporary schema cannot be named without schema qualification, but pg_statistics_obj_is_visible() missed that memo and could return “true” regardless. In turn, functions such as pg_describe_object() could fail to schema-qualify the object's name as expected.
Related records (5)
- Same changePostgreSQL 17.7 · Fix visibility checking for statistics objects in pg_temp
- Same changePostgreSQL 16.11 · Fix visibility checking for statistics objects in pg_temp
- Same changePostgreSQL 15.15 · Fix visibility checking for statistics objects in pg_temp
- Same changePostgreSQL 14.20 · Fix visibility checking for statistics objects in pg_temp
- Same changePostgreSQL 13.23 · Fix visibility checking for statistics objects in pg_temp
Bug fixesFix minor memory leak during WAL replay of database creation
Changes
Fix minor memory leak during WAL replay of database creation (Nathan Bossart) §
Bug fixesFix incorrect reporting of replication lag in pg_stat_replication view
Changes
Fix incorrect reporting of replication lag in pg_stat_replication view (Fujii Masao) §
If any standby server's replay LSN stopped advancing, the write_lag and flush_lag columns would eventually stop updating.
Related records (5)
- Same changePostgreSQL 17.7 · Fix incorrect reporting of replication lag in pg_stat_replication view
- Same changePostgreSQL 16.11 · Fix incorrect reporting of replication lag in pg_stat_replication view
- Same changePostgreSQL 15.15 · Fix incorrect reporting of replication lag in pg_stat_replication view
- Same changePostgreSQL 14.20 · Fix incorrect reporting of replication lag in pg_stat_replication view
- Same changePostgreSQL 13.23 · Fix incorrect reporting of replication lag in pg_stat_replication view
ImprovementsAvoid duplicative log messages about invalid primary_slot_name settings
Changes
Avoid duplicative log messages about invalid primary_slot_name settings (Fujii Masao) §
Related records (5)
- Same changePostgreSQL 17.7 · Avoid duplicative log messages about invalid primary_slot_name settings
- Same changePostgreSQL 16.11 · Avoid duplicative log messages about invalid primary_slot_name settings
- Same changePostgreSQL 15.15 · Avoid duplicative log messages about invalid primary_slot_name settings
- Same changePostgreSQL 14.20 · Avoid duplicative log messages about invalid primary_slot_name settings
- Same changePostgreSQL 13.23 · Avoid duplicative log messages about invalid primary_slot_name settings
ImprovementsAvoid failures when synchronized_standby_slots references nonexistent replication slots
Changes
Avoid failures when synchronized_standby_slots references nonexistent replication slots (Shlok Kyal) §
Related records (1)
ImprovementsRemove the unfinished slot state file after failing to write a replication slot's state to disk
Changes
Remove the unfinished slot state file after failing to write a replication slot's state to disk (Michael Paquier) §
Previously, a failure such as out-of-disk-space resulted in leaving a temporary state.tmp file behind. That's problematic because it would block all subsequent attempts to write the state, requiring manual intervention to clean up.
Related records (5)
- Same changePostgreSQL 17.7 · Remove the unfinished slot state file after failing to write a replication slot's state to disk
- Same changePostgreSQL 16.11 · Remove the unfinished slot state file after failing to write a replication slot's state to disk
- Same changePostgreSQL 15.15 · Remove the unfinished slot state file after failing to write a replication slot's state to disk
- Same changePostgreSQL 14.20 · Remove the unfinished slot state file after failing to write a replication slot's state to disk
- Same changePostgreSQL 13.23 · Remove the unfinished slot state file after failing to write a replication slot's state to disk
Bug fixesFix mishandling of lock timeout signals in parallel apply workers for logical replication
Changes
Fix mishandling of lock timeout signals in parallel apply workers for logical replication (Hayato Kuroda) §
The same signal number was being used for both worker shutdown and lock timeout, leading to confusion.
ImprovementsAvoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source
Changes
Avoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source (Xuneng Zhou) §
During a timeline change, a standby server's WAL receiver should remain alive, waiting for a new WAL streaming start point. Instead it was repeatedly shutting down and immediately getting restarted, which could confuse status monitoring code.
Related records (5)
- Same changePostgreSQL 17.7 · Avoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source
- Same changePostgreSQL 16.11 · Avoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source
- Same changePostgreSQL 15.15 · Avoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source
- Same changePostgreSQL 14.20 · Avoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source
- Same changePostgreSQL 13.23 · Avoid unwanted WAL receiver shutdown when switching from streaming to archive WAL source
Bug fixesFix use-after-free issue in the relation synchronization cache maintained by the pgoutput logical decoding plugin
Changes
Fix use-after-free issue in the relation synchronization cache maintained by the pgoutput logical decoding plugin (Vignesh C, Masahiko Sawada) §
An error during logical decoding could result in crashes in subsequent logical decoding attempts in the same session. The case is only reachable when pgoutput is invoked via SQL functions.
Related records (3)
- Same changePostgreSQL 17.7 · Fix use-after-free issue in the relation synchronization cache maintained by the pgoutput logical decoding plugin
- Same changePostgreSQL 16.11 · Fix use-after-free issue in the relation synchronization cache maintained by the pgoutput logical decoding plugin
- Same changePostgreSQL 15.15 · Fix use-after-free issue in the relation synchronization cache maintained by the pgoutput logical decoding plugin
ImprovementsAvoid unnecessary invalidation of logical replication slots
Changes
Avoid unnecessary invalidation of logical replication slots (Bertrand Drouvot) §
Related records (2)
ImprovementsRe-establish special case for C collation in locale setup
Changes
Re-establish special case for C collation in locale setup (Jeff Davis) §
This fixes a regression in access to shared catalogs early in backend startup, before a database has been selected. It is not known to be a problem for any core PostgreSQL code, but some extensions were broken.
Bug fixesFix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege
Changes
Fix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege (Bryan Green) §
This code would have crashed or at least printed garbage. No such cases have been reported though, indicating that failure of these system calls is extremely rare.
Related records (5)
- Same changePostgreSQL 17.7 · Fix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege
- Same changePostgreSQL 16.11 · Fix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege
- Same changePostgreSQL 15.15 · Fix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege
- Same changePostgreSQL 14.20 · Fix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege
- Same changePostgreSQL 13.23 · Fix incorrect printing of messages about failures in checking whether the user has Windows administrator privilege
Bug fixesAvoid crash when attempting to test PostgreSQL with certain libsanitizer options
Changes
Avoid crash when attempting to test PostgreSQL with certain libsanitizer options (Emmanuel Sibi, Jacob Champion) §
Bug fixesFix false memory-context-checking warnings in debug builds on 64-bit Windows
Changes
Fix false memory-context-checking warnings in debug builds on 64-bit Windows (David Rowley) §
Related records (5)
- Same changePostgreSQL 17.7 · Fix false memory-context-checking warnings in debug builds on 64-bit Windows
- Same changePostgreSQL 16.11 · Fix false memory-context-checking warnings in debug builds on 64-bit Windows
- Same changePostgreSQL 15.15 · Fix false memory-context-checking warnings in debug builds on 64-bit Windows
- Same changePostgreSQL 14.20 · Fix false memory-context-checking warnings in debug builds on 64-bit Windows
- Same changePostgreSQL 13.23 · Fix false memory-context-checking warnings in debug builds on 64-bit Windows
ImprovementsCorrectly handle GROUP BY DISTINCT in PL/pgSQL assignment statements
Changes
Correctly handle GROUP BY DISTINCT in PL/pgSQL assignment statements (Tom Lane) §
The parser failed to record the DISTINCT option in this context, so that the command would act as if it were plain GROUP BY.
Related records (4)
- Same changePostgreSQL 17.7 · Correctly handle GROUP BY DISTINCT in PL/pgSQL assignment statements
- Same changePostgreSQL 16.11 · Correctly handle GROUP BY DISTINCT in PL/pgSQL assignment statements
- Same changePostgreSQL 15.15 · Correctly handle GROUP BY DISTINCT in PL/pgSQL assignment statements
- Same changePostgreSQL 14.20 · Correctly handle GROUP BY DISTINCT in PL/pgSQL assignment statements
Bug fixesAvoid leaking memory when handling a SQL error within PL/Python
Changes
Avoid leaking memory when handling a SQL error within PL/Python (Tom Lane) §
This fixes a session-lifespan memory leak introduced in our previous minor releases.
Related records (5)
- Same changePostgreSQL 17.7 · Avoid leaking memory when handling a SQL error within PL/Python
- Same changePostgreSQL 16.11 · Avoid leaking memory when handling a SQL error within PL/Python
- Same changePostgreSQL 15.15 · Avoid leaking memory when handling a SQL error within PL/Python
- Same changePostgreSQL 14.20 · Avoid leaking memory when handling a SQL error within PL/Python
- Same changePostgreSQL 13.23 · Avoid leaking memory when handling a SQL error within PL/Python
Bug fixesFix libpq's handling of socket-related errors on Windows within its GSSAPI logic
Changes
Fix libpq's handling of socket-related errors on Windows within its GSSAPI logic (Ning Wu, Tom Lane) §
The code for encrypting/decrypting transmitted data using GSSAPI did not correctly recognize error conditions on the connection socket, since Windows reports those differently than other platforms. This led to failure to make such connections on Windows.
Related records (5)
- Same changePostgreSQL 17.7 · Fix libpq's handling of socket-related errors on Windows within its GSSAPI logic
- Same changePostgreSQL 16.11 · Fix libpq's handling of socket-related errors on Windows within its GSSAPI logic
- Same changePostgreSQL 15.15 · Fix libpq's handling of socket-related errors on Windows within its GSSAPI logic
- Same changePostgreSQL 14.20 · Fix libpq's handling of socket-related errors on Windows within its GSSAPI logic
- Same changePostgreSQL 13.23 · Fix libpq's handling of socket-related errors on Windows within its GSSAPI logic
Bug fixesFix dumping of non-inherited not-null constraints on inherited table columns
Changes
Fix dumping of non-inherited not-null constraints on inherited table columns (Dilip Kumar) §
pg_dump failed to preserve such constraints when dumping from a pre-v18 server.
Related records (1)
Bug fixesFix pg_dump's sorting of foreign key constraints
Changes
Fix pg_dump's sorting of foreign key constraints (Álvaro Herrera) §
Ensure consistent ordering of these database objects, as was already done for other object types.
Related records (5)
- Related commitsPostgreSQL 17.7 · Fix pg_dump's sorting of default ACLs and foreign key constraints
- Related commitsPostgreSQL 16.11 · Fix pg_dump's sorting of default ACLs and foreign key constraints
- Related commitsPostgreSQL 15.15 · Fix pg_dump's sorting of default ACLs and foreign key constraints
- Related commitsPostgreSQL 14.20 · Fix pg_dump's sorting of default ACLs and foreign key constraints
- Related commitsPostgreSQL 13.23 · Fix pg_dump's sorting of default ACLs and foreign key constraints
Bug fixesFix assorted errors in the data compression logic in pg_dump and pg_restore
Changes
Fix assorted errors in the data compression logic in pg_dump and pg_restore (Daniel Gustafsson, Tom Lane) § § §
Error checking was missing or incorrect in several places, and there were also portability issues that would manifest on big-endian hardware. These problems had been missed because this code is only used to read compressed TOC files within directory-format dumps. pg_dump never produces such a dump; the case can be reached only by manually compressing the TOC file after the fact, which is a supported thing to do but very uncommon.
Related records (5)
- Same changePostgreSQL 17.7 · Fix assorted errors in the data compression logic in pg_dump and pg_restore
- Same changePostgreSQL 16.11 · Fix assorted errors in the data compression logic in pg_dump and pg_restore
- Same changePostgreSQL 15.15 · Fix assorted errors in the data compression logic in pg_dump and pg_restore
- Same changePostgreSQL 14.20 · Fix assorted errors in the data compression logic in pg_dump and pg_restore
- Same changePostgreSQL 13.23 · Fix assorted errors in the data compression logic in pg_dump and pg_restore
Bug fixesFix pgbench to error out cleanly if a COPY operation is started
Changes
Fix pgbench to error out cleanly if a COPY operation is started (Anthonin Bonnefoy) §
pgbench doesn't intend to support this case, but previously it went into an infinite loop.
Related records (5)
- Same changePostgreSQL 17.7 · Fix pgbench to error out cleanly if a COPY operation is started
- Same changePostgreSQL 16.11 · Fix pgbench to error out cleanly if a COPY operation is started
- Same changePostgreSQL 15.15 · Fix pgbench to error out cleanly if a COPY operation is started
- Same changePostgreSQL 14.20 · Fix pgbench to error out cleanly if a COPY operation is started
- Same changePostgreSQL 13.23 · Fix pgbench to error out cleanly if a COPY operation is started
Bug fixesFix pgbench's reporting of multiple errors
Changes
Fix pgbench's reporting of multiple errors (Yugo Nagata) §
In cases where two successive PQgetResult calls both fail, pgbench might report the wrong error message.
Related records (5)
- Same changePostgreSQL 17.7 · Fix pgbench's reporting of multiple errors
- Same changePostgreSQL 16.11 · Fix pgbench's reporting of multiple errors
- Same changePostgreSQL 15.15 · Fix pgbench's reporting of multiple errors
- Same changePostgreSQL 14.20 · Fix pgbench's reporting of multiple errors
- Same changePostgreSQL 13.23 · Fix pgbench's reporting of multiple errors
Bug fixesIn pgbench, fix faulty assertion about errors in pipeline mode
Changes
In pgbench, fix faulty assertion about errors in pipeline mode (Yugo Nagata) §
Bug fixesFix per-file memory leakage in pg_combinebackup
ImprovementsEnsure that contrib/pg_buffercache functions can be canceled
Changes
Ensure that contrib/pg_buffercache functions can be canceled (Satyanarayana Narlapuram, Yuhang Qiu) § §
Some code paths were capable of running for a long time without checking for interrupts.
Related records (5)
- Same changePostgreSQL 17.7 · Ensure that contrib/pg_buffercache functions can be canceled
- Same changePostgreSQL 16.11 · Ensure that contrib/pg_buffercache functions can be canceled
- Same changePostgreSQL 15.15 · Ensure that contrib/pg_buffercache functions can be canceled
- Same changePostgreSQL 14.20 · Ensure that contrib/pg_buffercache functions can be canceled
- Same changePostgreSQL 13.23 · Ensure that contrib/pg_buffercache functions can be canceled
Bug fixesFix contrib/pg_prewarm's privilege checks for indexes
Changes
Fix contrib/pg_prewarm's privilege checks for indexes (Ayush Vatsa, Nathan Bossart) § §
pg_prewarm() requires SELECT privilege on relations to be prewarmed. However, since indexes have no SQL privileges of their own, this resulted in non-superusers being unable to prewarm indexes. Instead, check for SELECT privilege on the index's table.
Related records (5)
- Same changePostgreSQL 17.7 · Fix contrib/pg_prewarm's privilege checks for indexes
- Same changePostgreSQL 16.11 · Fix contrib/pg_prewarm's privilege checks for indexes
- Same changePostgreSQL 15.15 · Fix contrib/pg_prewarm's privilege checks for indexes
- Same changePostgreSQL 14.20 · Fix contrib/pg_prewarm's privilege checks for indexes
- Same changePostgreSQL 13.23 · Fix contrib/pg_prewarm's privilege checks for indexes
Bug fixesIn contrib/pg_stat_statements, avoid crash when two or more constants are marked as having the same location in the SQL statement text
Changes
In contrib/pg_stat_statements, avoid crash when two or more constants are marked as having the same location in the SQL statement text (Sami Imseih, Dmitry Dolgov) §
ImprovementsMake contrib/pgstattuple more robust about empty or invalid index pages
Changes
Make contrib/pgstattuple more robust about empty or invalid index pages (Nitin Motiani) §
Count all-zero pages as free space, and ignore pages that are invalid according to a check of the page's special-space size. The code for btree indexes already counted all-zero pages as free, but the hash and gist code would error out, which has been found to be much less user-friendly. Similarly, make all three cases agree on ignoring corrupted pages rather than throwing errors.
Related records (5)
- Same changePostgreSQL 17.7 · Make contrib/pgstattuple more robust about empty or invalid index pages
- Same changePostgreSQL 16.11 · Make contrib/pgstattuple more robust about empty or invalid index pages
- Same changePostgreSQL 15.15 · Make contrib/pgstattuple more robust about empty or invalid index pages
- Same changePostgreSQL 14.20 · Make contrib/pgstattuple more robust about empty or invalid index pages
- Same changePostgreSQL 13.23 · Make contrib/pgstattuple more robust about empty or invalid index pages
ImprovementsHarden our read and write barrier macros to satisfy Clang
Changes
Harden our read and write barrier macros to satisfy Clang (Thomas Munro) §
We supposed that __atomic_thread_fence() is a sufficient barrier to prevent the C compiler from re-ordering memory accesses around it, but it appears that that's not true for Clang, allowing it to generate incorrect code for at least RISC-V, MIPS, and LoongArch machines. Add explicit compiler barriers to fix that.
Related records (5)
- Same changePostgreSQL 17.7 · Harden our read and write barrier macros to satisfy Clang
- Same changePostgreSQL 16.11 · Harden our read and write barrier macros to satisfy Clang
- Same changePostgreSQL 15.15 · Harden our read and write barrier macros to satisfy Clang
- Same changePostgreSQL 14.20 · Harden our read and write barrier macros to satisfy Clang
- Same changePostgreSQL 13.23 · Harden our read and write barrier macros to satisfy Clang
Bug fixesFix PGXS build infrastructure to support building NLS po files for extensions
Changes
Fix PGXS build infrastructure to support building NLS po files for extensions (Ryo Matsumura) §
Related records (5)
- Same changePostgreSQL 17.7 · Fix PGXS build infrastructure to support building NLS po files for extensions
- Same changePostgreSQL 16.11 · Fix PGXS build infrastructure to support building NLS po files for extensions
- Same changePostgreSQL 15.15 · Fix PGXS build infrastructure to support building NLS po files for extensions
- Same changePostgreSQL 14.20 · Fix PGXS build infrastructure to support building NLS po files for extensions
- Same changePostgreSQL 13.23 · Fix PGXS build infrastructure to support building NLS po files for extensions
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.