DocumentationVersion comparison
POSTGRESQL · VERSION COMPARE
PostgreSQL 16.15 release changes
All features, fixes, and compatibility notes in this release, with related records from other versions.
Includes changes after the source version through the target. A major version name means its initial release.
Detect the source version from your database
Complete release changes
16.15
2026-08-13
16.15stableSupport ends 2028-11-09
Security changes
| CVE / issue | Severity | Fixed version | Selection status |
|---|---|---|---|
| CVE-2026-6637 Avoid NULL-pointer dereference in contrib/refint's check_foreign_key() | 16.14 | Recorded fix | |
| CVE-2026-6473 Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl | 16.14 | Recorded fix | |
| CVE-2026-19385 Remove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries | 16.15 | Recorded fix | |
| CVE-2026-18408 Do not do backquote expansion on the argument of psql's \unrestrict command | 16.15 | Recorded fix | |
| CVE-2026-16239 Cross-check the output row type of a portal running EXECUTE or FETCH | 16.15 | Recorded fix | |
| CVE-2026-16238 Fix multirange type handling in pg_restore_attribute_stats() | Recorded fix | ||
| CVE-2026-15742 Fix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions | 16.15 | Recorded fix | |
| CVE-2026-15741 When deparsing an EXTRACT() function call, quote the field name if needed | 16.15 | Recorded fix | |
| CVE-2026-14680 Reject calls from SQL to functions that take or return type internal | 16.15 | Recorded fix | |
| CVE-2026-14677 Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl | 16.15 | Recorded fix | |
| CVE-2026-14676 Fix buffer overrun in contrib/pg_stat_statements | Recorded fix | ||
| CVE-2026-14671 Remove the plan cache in contrib/refint | 16.15 | Recorded fix | |
| CVE-2026-14670 Harden PL/Perl against “tied” Perl arrays and hashes | 16.15 | Recorded fix | |
| CVE-2026-14669 Fix buffer overrun with long time zone abbreviation in to_char() | 16.15 | Recorded fix | |
| CVE-2026-14664 Fix buffer overrun in regexp match/split functions | 16.15 | Recorded fix | |
| CVE-2026-14662 Harden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length) | 16.15 | Recorded fix | |
| CVE-2025-8714 Do not do backquote expansion on the argument of psql's \unrestrict command | 16.10 | Recorded fix | |
| CVE-2026-14679 Fix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments | 16.15 | Recorded fix | |
| CVE-2026-6464 Fix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN | 16.15 | Recorded fix | |
| CVE-2026-14668 Make scalarineqsel() check that a constant it expects to be of type tid actually is | 16.15 | Recorded fix | |
| CVE-2026-6471 Restrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries | 16.15 | Recorded fix | |
| CVE-2026-14663 Fix contrib/pgcrypto's PGP encryption to detect unsupported ciphers | 16.15 | Recorded fix | |
| CVE-2026-14672 Make mock SCRAM authentication secrets more plausible | 16.15 | Recorded fix | |
| CVE-2026-6470 Check for USAGE privilege on data types in places that formerly failed to check that | 16.15 | Recorded fix | |
| CVE-2026-18024 Harden the ascii() function against invalid input | 16.15 | Recorded fix | |
| CVE-2026-14678 Fix datatype error in contrib/pg_trgm's GiST picksplit function | 16.15 | Recorded fix | |
| CVE-2026-14681 Reject GSSEncRequest after direct SSL connection | Recorded fix | ||
| CVE-2026-14666 Invalidate role-dependent cached plans after role changes | 16.15 | Recorded fix | |
| CVE-2026-6469 Preserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE | 16.15 | Recorded fix | |
| CVE-2026-16241 Fix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server | 16.15 | Recorded fix | |
| CVE-2026-14673 Ensure that contrib/amcheck functions restrict search_path before executing index expressions | 16.15 | Recorded fix |
PostgreSQL 16.15
Migration and compatibility
A dump/restore is not required for those running 16.X.
However, the first three security entries below describe configuration adjustments and data cleanups that you may need to make after updating.
Also, if you use contrib/btree_gist or contrib/ltree, you may need to reindex indexes made with those extensions; see the relevant entries below.
Also, if you are upgrading from a version earlier than 16.10, see Section E.6.
SecurityRestrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries
Changes
Restrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries (Jacob Champion) §
Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins.
By default, only the output plugins shipped as part of PostgreSQL (pgoutput and test_decoding) are included in output_plugin_libraries. Installations that rely on other output plugins must add them after updating the server, for example
output_plugin_libraries = 'pgoutput, test_decoding, my_trusted_decoder'
Additionally, pg_upgrade --check will fail if the output_plugin_libraries parameter on the new cluster does not permit the plugins of logical replication slots on the old cluster, when migrating from versions 17 and later. Make necessary additions to the new cluster's setting before performing pg_upgrade.
The PostgreSQL Project thanks Vladimir Tokarev and Yu Kunpeng for reporting this problem. (CVE-2026-6471)
Related records (4)
- Same changePostgreSQL 18.6 · Restrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries
- Same changePostgreSQL 17.11 · Restrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries
- Same changePostgreSQL 15.19 · Restrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries
- Same changePostgreSQL 14.24 · Restrict logical decoding output plugins to the set specified by a new server parameter output_plugin_libraries
SecurityFix contrib/pgcrypto's PGP encryption to detect unsupported ciphers
Changes
Fix contrib/pgcrypto's PGP encryption to detect unsupported ciphers (Daniel Gustafsson) § §
Previously, if OpenSSL rejected the requested cipher (for example, because it is running in FIPS mode, or the legacy provider hasn't been loaded), pgcrypto failed to notice the failure and simply XOR'd the non-encrypted block with the plaintext, rendering the “encryption” trivially breakable. This will typically occur with deprecated or non-FIPS cipher algorithms (cipher-algo=blowfish/bf, twofish, cast5, or 3des).
By default, pgcrypto will now fail to decrypt any messages that were affected in this way. To allow retrieval of such data, a new option ignore-cipher-failure has been added to pgp_pub_decrypt() and pgp_sym_decrypt(). Setting ignore-cipher-failure=1 will restore their previous behavior, allowing the faulty encryption wrapper to be stripped off:
pgp_sym_decrypt(encrypted_column, any key, 'ignore-cipher-failure=1')
Once the affected messages are identified and stripped of their wrappers, they can then be re-encrypted with a modern algorithm. It is important however that the behavior of OpenSSL be the same as it was when the faulty messages were created: if the set of unsupported algorithms is not the same, this approach will not work. See the documentation for ignore-cipher-failure.
The PostgreSQL Project thanks Shishir Sharma for reporting this problem. (CVE-2026-14663)
Related records (4)
- Same changePostgreSQL 18.6 · Fix contrib/pgcrypto's PGP encryption to detect unsupported ciphers
- Same changePostgreSQL 17.11 · Fix contrib/pgcrypto's PGP encryption to detect unsupported ciphers
- Same changePostgreSQL 15.19 · Fix contrib/pgcrypto's PGP encryption to detect unsupported ciphers
- Same changePostgreSQL 14.24 · Fix contrib/pgcrypto's PGP encryption to detect unsupported ciphers
SecurityFix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN
Changes
Fix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN (Tom Lane) § §
Previously, if a COPY command failed at startup (for instance, because the target table doesn't exist) psql would not realize that and would proceed to read the following in-line data as SQL commands. In the best case that's wrong and in the worst case it's a SQL-injection hazard. Teach psql to recognize syntactically-valid COPY ... FROM STDIN commands and to skip data on its own authority if the server doesn't respond with PGRES_COPY_IN.
While this fix is unlikely to affect any production SQL scripts, test scripts might intentionally exercise failing COPY ... FROM STDIN commands. Those will need to gain a \. data terminator line after each such command.
The PostgreSQL Project thanks Alexander Lakhin for reporting this problem. (CVE-2026-6464)
Related records (4)
- Same changePostgreSQL 18.6 · Fix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN
- Same changePostgreSQL 17.11 · Fix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN
- Same changePostgreSQL 15.19 · Fix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN
- Same changePostgreSQL 14.24 · Fix psql to skip in-line data following a scripted COPY ... FROM STDIN command, even if the COPY fails before sending PGRES_COPY_IN
SecurityCross-check the output row type of a portal running EXECUTE or FETCH
Changes
Cross-check the output row type of a portal running EXECUTE or FETCH (Robert Haas) §
EXECUTE and FETCH use two portals: an outer one for the statement itself, and an inner one running the query being executed on its behalf. It was previously possible to make the declared row types of the two portals diverge, leading to server memory disclosure and arbitrary code execution.
The PostgreSQL Project thanks Ben Morris (in collaboration with Claude and Anthropic Research) and Peter Geoghegan for reporting this problem. (CVE-2026-16239)
Related records (4)
- Same changePostgreSQL 18.6 · Cross-check the output row type of a portal running EXECUTE or FETCH
- Same changePostgreSQL 17.11 · Cross-check the output row type of a portal running EXECUTE or FETCH
- Same changePostgreSQL 15.19 · Cross-check the output row type of a portal running EXECUTE or FETCH
- Same changePostgreSQL 14.24 · Cross-check the output row type of a portal running EXECUTE or FETCH
SecurityFix buffer overrun with long time zone abbreviation in to_char()
Changes
Fix buffer overrun with long time zone abbreviation in to_char() (Tom Lane) §
This can easily crash the server, and exploits leading to arbitrary code execution have been reported.
The PostgreSQL Project thanks Hcamael, Amjad Shahzad, Tan Zhen of AntAISecurityLab, Tomer Fichman, Zheng Yu, Amy Burnett (OpenAI Codex Security), Rick de Jager, Heewon Song, Sylvie Mayer, Aleksander Alekseev, and Hillai Ben Sasson for reporting this problem. (CVE-2026-14669)
Related records (9)
- Related commitsPostgreSQL 18.6 · Fix cascading standby reconnect failure after archive fallback
- Same changePostgreSQL 18.6 · Fix buffer overrun with long time zone abbreviation in to_char()
- Same changePostgreSQL 17.11 · Fix buffer overrun with long time zone abbreviation in to_char()
- Related commitsPostgreSQL 17.11 · Fix cascading standby reconnect failure after archive fallback
- Related commitsPostgreSQL 16.15 · Fix cascading standby reconnect failure after archive fallback
- Same changePostgreSQL 15.19 · Fix buffer overrun with long time zone abbreviation in to_char()
- Related commitsPostgreSQL 15.19 · Fix cascading standby reconnect failure after archive fallback
- Related commitsPostgreSQL 14.24 · Fix cascading standby reconnect failure after archive fallback
- Same changePostgreSQL 14.24 · Fix buffer overrun with long time zone abbreviation in to_char()
SecurityFix buffer overrun in regexp match/split functions
Changes
Fix buffer overrun in regexp match/split functions (Masahiko Sawada) §
If passed invalidly-encoded data, these functions could write past the end of their conversion buffer.
The PostgreSQL Project thanks Francesco Verardi for reporting this problem. (CVE-2026-14664)
Related records (4)
- Same changePostgreSQL 18.6 · Fix buffer overrun in regexp match/split functions
- Same changePostgreSQL 17.11 · Fix buffer overrun in regexp match/split functions
- Same changePostgreSQL 15.19 · Fix buffer overrun in regexp match/split functions
- Same changePostgreSQL 14.24 · Fix buffer overrun in regexp match/split functions
SecurityHarden the ascii() function against invalid input
Changes
Harden the ascii() function against invalid input (Michael Paquier) §
By supplying invalidly-encoded input, this function could be coaxed to read and return a few bytes of data that it shouldn't. In assert-enabled builds, its assertions could be triggered too.
The PostgreSQL Project thanks Hcamael for reporting this problem. (CVE-2026-18024)
Related records (4)
- Same changePostgreSQL 18.6 · Harden the ascii() function against invalid input
- Same changePostgreSQL 17.11 · Harden the ascii() function against invalid input
- Same changePostgreSQL 15.19 · Harden the ascii() function against invalid input
- Same changePostgreSQL 14.24 · Harden the ascii() function against invalid input
SecurityFix multirange type handling in pg_restore_attribute_stats()
Changes
Fix multirange type handling in pg_restore_attribute_stats() (OpenAI Security Research Team)
pg_restore_attribute_stats() treated multirange types just like their underlying range type. This works correctly for the bounds histogram, but it was wrong for all the other statistics kinds.
The PostgreSQL Project thanks Amy Burnett (OpenAI Codex Security) for reporting this problem. (CVE-2026-16238)
Related records (4)
- Same changePostgreSQL 18.6 · Fix multirange type handling in pg_restore_attribute_stats()
- Same changePostgreSQL 17.11 · Fix multirange type handling in pg_restore_attribute_stats()
- Same changePostgreSQL 15.19 · Fix multirange type handling in pg_restore_attribute_stats()
- Same changePostgreSQL 14.24 · Fix multirange type handling in pg_restore_attribute_stats()
SecurityMake scalarineqsel() check that a constant it expects to be of type tid actually is
Changes
Make scalarineqsel() check that a constant it expects to be of type tid actually is (Tom Lane) §
This expectation will hold for all the built-in operators that use this estimator, but a maliciously-constructed operator could violate it, leading to a crash or server memory disclosure.
The PostgreSQL Project thanks Hcamael for reporting this problem. (CVE-2026-14668)
Related records (4)
- Same changePostgreSQL 18.6 · Make scalarineqsel() check that a constant it expects to be of type tid actually is
- Same changePostgreSQL 17.11 · Make scalarineqsel() check that a constant it expects to be of type tid actually is
- Same changePostgreSQL 15.19 · Make scalarineqsel() check that a constant it expects to be of type tid actually is
- Same changePostgreSQL 14.24 · Make scalarineqsel() check that a constant it expects to be of type tid actually is
SecurityHarden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length)
Changes
Harden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length) (Tom Lane) § §
The documented limits were not enforced in all code paths.
The PostgreSQL Project thanks Yuhang Wu, Zhenpeng Lin, Zheng Yu, and Hcamael for reporting these problems. (CVE-2026-14662)
Related records (4)
- Same changePostgreSQL 18.6 · Harden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length)
- Same changePostgreSQL 17.11 · Harden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length)
- Same changePostgreSQL 15.19 · Harden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length)
- Same changePostgreSQL 14.24 · Harden tsvector and tsquery code against overly long values (both individual lexemes and total vector/query length)
SecurityFix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments
Changes
Fix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments (Tom Lane) § §
Notably, the server's actual limit on the number of arguments to an aggregate function is FUNC_MAX_ARGS - 1, but the parser failed to enforce that, creating hazards downstream.
The PostgreSQL Project thanks Zheng Yu, ylwangtju, and Masahiko Sawada for reporting these problems. (CVE-2026-14679)
Related records (4)
- Same changePostgreSQL 18.6 · Fix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments
- Same changePostgreSQL 17.11 · Fix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments
- Same changePostgreSQL 15.19 · Fix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments
- Same changePostgreSQL 14.24 · Fix various places that mistakenly assumed they would not have to deal with more than FUNC_MAX_ARGS function arguments
SecurityReject calls from SQL to functions that take or return type internal
Changes
Reject calls from SQL to functions that take or return type internal (Tom Lane) § §
The existing defenses against doing this have been shown to be insufficient, so add more explicit checks.
The PostgreSQL Project thanks Amy Burnett (OpenAI Codex Security) for reporting this problem. (CVE-2026-14680)
Related records (4)
- Same changePostgreSQL 18.6 · Reject calls from SQL to functions that take or return type internal
- Same changePostgreSQL 17.11 · Reject calls from SQL to functions that take or return type internal
- Same changePostgreSQL 15.19 · Reject calls from SQL to functions that take or return type internal
- Same changePostgreSQL 14.24 · Reject calls from SQL to functions that take or return type internal
SecurityPreserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE
Changes
Preserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE (Masahiko Sawada) §
Previously, the role running ALTER TABLE gained ownership of such objects, but that seems inappropriate.
The PostgreSQL Project thanks Noah Misch for reporting this problem. (CVE-2026-6469)
Related records (4)
- Same changePostgreSQL 18.6 · Preserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE
- Same changePostgreSQL 17.11 · Preserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE
- Same changePostgreSQL 15.19 · Preserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE
- Same changePostgreSQL 14.24 · Preserve the ownership of extended statistics objects when they are rebuilt by ALTER TABLE
SecurityWhen deparsing an EXTRACT() function call, quote the field name if needed
Changes
When deparsing an EXTRACT() function call, quote the field name if needed (Nathan Bossart) §
The parser accepts any string literal as a field name in EXTRACT(), deferring validation to execution. If the call is stored and deparsed (for example during pg_dump), the string body was regurgitated verbatim, allowing SQL injection.
The PostgreSQL Project thanks Ben Morris (in collaboration with Claude and Anthropic Research) for reporting this problem. (CVE-2026-15741)
Related records (4)
- Same changePostgreSQL 18.6 · When deparsing an EXTRACT() function call, quote the field name if needed
- Same changePostgreSQL 17.11 · When deparsing an EXTRACT() function call, quote the field name if needed
- Same changePostgreSQL 15.19 · When deparsing an EXTRACT() function call, quote the field name if needed
- Same changePostgreSQL 14.24 · When deparsing an EXTRACT() function call, quote the field name if needed
SecurityCheck for USAGE privilege on data types in places that formerly failed to check that
Changes
Check for USAGE privilege on data types in places that formerly failed to check that (Nathan Bossart) § § §
CREATE TYPE AS RANGE did not check, nor did ALTER TABLE OF, nor did commands that create stored expressions. These omissions allowed roles without USAGE privilege to nonetheless create objects depending on the type, possibly blocking the type's owner from changing the type later.
The PostgreSQL Project thanks Jingzhou Fu for reporting this problem. (CVE-2026-6470)
Related records (4)
- Same changePostgreSQL 18.6 · Check for USAGE privilege on data types in places that formerly failed to check that
- Same changePostgreSQL 17.11 · Check for USAGE privilege on data types in places that formerly failed to check that
- Same changePostgreSQL 15.19 · Check for USAGE privilege on data types in places that formerly failed to check that
- Same changePostgreSQL 14.24 · Check for USAGE privilege on data types in places that formerly failed to check that
SecurityInvalidate role-dependent cached plans after role changes
Changes
Invalidate role-dependent cached plans after role changes (Ilya Staroverov, Shinya Kato, Nathan Bossart) §
Role membership, role attribute, and database ownership changes may impact the expected behavior of row-level security policies, but previously we'd continue to use cached plans that were made according to the old state of affairs.
The PostgreSQL Project thanks Ilya Staroverov and Shinya Kato for reporting this problem. (CVE-2026-14666)
Related records (4)
- Same changePostgreSQL 18.6 · Invalidate role-dependent cached plans after role changes
- Same changePostgreSQL 17.11 · Invalidate role-dependent cached plans after role changes
- Same changePostgreSQL 15.19 · Invalidate role-dependent cached plans after role changes
- Same changePostgreSQL 14.24 · Invalidate role-dependent cached plans after role changes
SecurityReject GSSEncRequest after direct SSL connection
Changes
Reject GSSEncRequest after direct SSL connection (Michael Paquier)
After establishing a TLS-encrypted connection, the server would still accept a request for GSSAPI encryption. If that succeeded, the connection would proceed using TLS encryption, but it would look like a GSS connection to the pg_hba rules. Thus, a pg_hba policy intending to disallow TLS would not be enforced correctly.
The PostgreSQL Project thanks p4p3r for reporting this problem. (CVE-2026-14681)
Related records (4)
- Same changePostgreSQL 18.6 · Reject GSSEncRequest after direct SSL connection
- Same changePostgreSQL 17.11 · Reject GSSEncRequest after direct SSL connection
- Same changePostgreSQL 15.19 · Reject GSSEncRequest after direct SSL connection
- Same changePostgreSQL 14.24 · Reject GSSEncRequest after direct SSL connection
SecurityMake mock SCRAM authentication secrets more plausible
Changes
Make mock SCRAM authentication secrets more plausible (Nathan Bossart) §
If a SCRAM login is attempted against a role that doesn't exist or doesn't have a SCRAM secret, we generate a mock secret and carry out the authentication handshake anyway, to avoid revealing these facts to an attacker. But the mock secret was made with a fixed iteration count, which in itself can be an observable response discrepancy. Use the configuration setting scram_iterations instead, to make the mock secret look more like the installation's real secrets.
The PostgreSQL Project thanks Radim Marek for reporting this problem. (CVE-2026-14672)
Related records (4)
- Same changePostgreSQL 18.6 · Make mock SCRAM authentication secrets more plausible
- Same changePostgreSQL 17.11 · Make mock SCRAM authentication secrets more plausible
- Same changePostgreSQL 15.19 · Make mock SCRAM authentication secrets more plausible
- Same changePostgreSQL 14.24 · Make mock SCRAM authentication secrets more plausible
SecurityFix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server
Changes
Fix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server (Michael Paquier) §
ecpg assumed without checking that any bytea value must begin with \x. A broken or malicious server might send a string shorter than 2 bytes, resulting in memory clobber in the application.
The PostgreSQL Project thanks ylwangtju for reporting this problem. (CVE-2026-16241)
Related records (4)
- Same changePostgreSQL 18.6 · Fix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server
- Same changePostgreSQL 17.11 · Fix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server
- Same changePostgreSQL 15.19 · Fix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server
- Same changePostgreSQL 14.24 · Fix out-of-bounds writes in ecpg applications caused by invalid bytea data received from the server
SecurityDo not do backquote expansion on the argument of psql's \unrestrict command
Changes
Do not do backquote expansion on the argument of psql's \unrestrict command (Nathan Bossart) §
This oversight in the fix for CVE-2025-8714 allows a malicious server to inject shell commands into plain-text dump output that will be run at restore time on the machine running psql, the exact scenario that CVE-2025-8714 intended to prevent.
The PostgreSQL Project thanks Lucas Velgus, Filip Janus, and Daniel Bakker for reporting this problem. (CVE-2026-18408)
Related records (4)
- Same changePostgreSQL 18.6 · Do not do backquote expansion on the argument of psql's \unrestrict command
- Same changePostgreSQL 17.11 · Do not do backquote expansion on the argument of psql's \unrestrict command
- Same changePostgreSQL 15.19 · Do not do backquote expansion on the argument of psql's \unrestrict command
- Same changePostgreSQL 14.24 · Do not do backquote expansion on the argument of psql's \unrestrict command
SecurityRemove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries
Changes
Remove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries (Tom Lane) §
Since there could be entries for both input and output arguments, it's feasible for this array's length to exceed FUNC_MAX_ARGS (which constrains only input arguments). Even if that were not so, pg_dump cannot assume that the server was built with the same value of FUNC_MAX_ARGS that it has. An overrun would lead to a memory clobber inside pg_dump.
The PostgreSQL Project thanks Masahiko Sawada for reporting this problem. (CVE-2026-19385)
Related records (4)
- Same changePostgreSQL 18.6 · Remove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries
- Same changePostgreSQL 17.11 · Remove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries
- Same changePostgreSQL 15.19 · Remove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries
- Same changePostgreSQL 14.24 · Remove pg_dump's assumption that pg_proc.protrftypes cannot have more than FUNC_MAX_ARGS entries
SecurityHarden PL/Perl against “tied” Perl arrays and hashes
Changes
Harden PL/Perl against “tied” Perl arrays and hashes (Tom Lane) §
A tied object that doesn't behave like a regular one could lead to memory overwrite, or to constructing a corrupt result array (which would likely cause problems later).
The PostgreSQL Project thanks Hcamael for reporting this problem. (CVE-2026-14670)
Related records (4)
- Same changePostgreSQL 18.6 · Harden PL/Perl against “tied” Perl arrays and hashes
- Same changePostgreSQL 17.11 · Harden PL/Perl against “tied” Perl arrays and hashes
- Same changePostgreSQL 15.19 · Harden PL/Perl against “tied” Perl arrays and hashes
- Same changePostgreSQL 14.24 · Harden PL/Perl against “tied” Perl arrays and hashes
SecurityFix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl
Changes
Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl (Heikki Linnakangas) §
This is the same type of problem as CVE-2026-6473, just in a different part of the code, and is fixed in the same way.
The PostgreSQL Project thanks the Tulya Project (Team Dhiutsa, Bitecope Technologies Private Ltd) for reporting this problem. (CVE-2026-14677)
Related records (4)
- Same changePostgreSQL 18.6 · Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl
- Same changePostgreSQL 17.11 · Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl
- Same changePostgreSQL 15.19 · Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl
- Same changePostgreSQL 14.24 · Fix integer overflows in memory-allocation calculations in PL/Perl and PL/Tcl
SecurityEnsure that contrib/amcheck functions restrict search_path before executing index expressions
Changes
Ensure that contrib/amcheck functions restrict search_path before executing index expressions (Noah Misch) §
Because amcheck will run such index expressions as the owner of their tables, a caller could potentially hijack search_path-dependent functions to run arbitrary code as the table owner. By default this is not a vulnerability because only superusers are allowed to call amcheck functions; but if that privilege was granted out, it created a larger hazard than the documentation suggests.
The PostgreSQL Project thanks Yuelin Wang and Jacob Brazeal for reporting this problem. (CVE-2026-14673)
Related records (4)
- Same changePostgreSQL 18.6 · Ensure that contrib/amcheck functions restrict search_path before executing index expressions
- Same changePostgreSQL 17.11 · Ensure that contrib/amcheck functions restrict search_path before executing index expressions
- Same changePostgreSQL 15.19 · Ensure that contrib/amcheck functions restrict search_path before executing index expressions
- Same changePostgreSQL 14.24 · Ensure that contrib/amcheck functions restrict search_path before executing index expressions
SecurityFix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions
Changes
Fix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions (Nathan Bossart) §
Passing large cost values to these functions could cause integer overflows, thereby producing nonsensical results, and even causing out-of-bounds writes in some cases.
The PostgreSQL Project thanks Ben Morris (in collaboration with Claude and Anthropic Research) for reporting this problem. (CVE-2026-15742)
Related records (4)
- Same changePostgreSQL 18.6 · Fix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions
- Same changePostgreSQL 17.11 · Fix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions
- Same changePostgreSQL 15.19 · Fix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions
- Same changePostgreSQL 14.24 · Fix integer overflows in contrib/fuzzystrmatch's levenshtein() and levenshtein_less_equal() functions
SecurityFix buffer overrun in contrib/pg_stat_statements
Changes
Fix buffer overrun in contrib/pg_stat_statements (Álvaro Herrera)
Query normalization didn't accurately account for the amount of space the normalized string would require.
The PostgreSQL Project thanks Sajeeb Lohani (with TrendAI Zero Day Initiative) and Yuelin Wang for reporting this problem. (CVE-2026-14676)
Related records (4)
- Same changePostgreSQL 18.6 · Fix buffer overrun in contrib/pg_stat_statements
- Same changePostgreSQL 17.11 · Fix buffer overrun in contrib/pg_stat_statements
- Same changePostgreSQL 15.19 · Fix buffer overrun in contrib/pg_stat_statements
- Same changePostgreSQL 14.24 · Fix buffer overrun in contrib/pg_stat_statements
SecurityFix datatype error in contrib/pg_trgm's GiST picksplit function
Changes
Fix datatype error in contrib/pg_trgm's GiST picksplit function (Heikki Linnakangas) §
This mistake resulted in reading past the end of the buffer, typically causing bad split decisions; but a crash could ensue if you're very unlucky.
The PostgreSQL Project thanks Mehmet D. Ince for reporting this problem. (CVE-2026-14678)
Related records (4)
- Same changePostgreSQL 18.6 · Fix datatype error in contrib/pg_trgm's GiST picksplit function
- Same changePostgreSQL 17.11 · Fix datatype error in contrib/pg_trgm's GiST picksplit function
- Same changePostgreSQL 15.19 · Fix datatype error in contrib/pg_trgm's GiST picksplit function
- Same changePostgreSQL 14.24 · Fix datatype error in contrib/pg_trgm's GiST picksplit function
SecurityRemove the plan cache in contrib/refint
Changes
Remove the plan cache in contrib/refint (Ayush Tiwari) §
This caching behavior has several serious bugs, notably that check_foreign_key() embeds the new key values in its cascade-UPDATE queries, so a cached plan reuses the originally-needed values rather than the key values that should be used. The simplest solution is to remove it.
The PostgreSQL Project thanks Hcamael for reporting this problem. (CVE-2026-14671)
Related records (4)
Bug fixesFix self-deadlock when replaying WAL generated by an older minor version
Changes
Fix self-deadlock when replaying WAL generated by an older minor version (Andrey Borodin) §
This error was introduced in the previous set of minor releases. It caused standby servers that were following a primary of an older minor release version to get stuck in some scenarios.
Bug fixesFix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node
Changes
Fix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) §
When an upper plan node rescans an Append before having read the entire Append output, we need to discard any in-flight requests sent to external servers (by postgres_fdw for example). This was not done correctly in cases where a subplan has parameter changes or is discarded by partition pruning in the next scan. The outcome could be incorrect query results, an infinite loop, or an assertion failure.
Related records (4)
- Same changePostgreSQL 18.6 · Fix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node
- Same changePostgreSQL 17.11 · Fix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node
- Same changePostgreSQL 15.19 · Fix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node
- Same changePostgreSQL 14.24 · Fix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node
Bug fixesFix error in partition pruning for RANGE-partitioned tables
Changes
Fix error in partition pruning for RANGE-partitioned tables (David Rowley) §
In some cases the DEFAULT partition would be skipped when it should not be, which could lead to rows missing from query results.
Related records (4)
- Same changePostgreSQL 18.6 · Fix error in partition pruning for RANGE-partitioned tables
- Same changePostgreSQL 17.11 · Fix error in partition pruning for RANGE-partitioned tables
- Same changePostgreSQL 15.19 · Fix error in partition pruning for RANGE-partitioned tables
- Same changePostgreSQL 14.24 · Fix error in partition pruning for RANGE-partitioned tables
Bug fixesFix planner's nullability and strictness checks for value IN (array) expressions
Changes
Fix planner's nullability and strictness checks for expressions (Ayush Tiwari) §value IN (array)
These checks should only succeed if the array operand is known to be non-empty, but that consideration was missed, allowing optimizations to be applied that should not be. This could result in wrong query answers if the array actually was empty.
Related records (4)
- Same changePostgreSQL 18.6 · Fix planner's nullability and strictness checks for value IN (array) expressions
- Same changePostgreSQL 17.11 · Fix planner's nullability and strictness checks for value IN (array) expressions
- Same changePostgreSQL 15.19 · Fix planner's nullability and strictness checks for value IN (array) expressions
- Same changePostgreSQL 14.24 · Fix planner's nullability and strictness checks for value IN (array) expressions
Bug fixesFix incorrect join removal logic
ImprovementsAdd missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges)
Changes
Add missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges) (Andrei Lepikhov, Tom Lane) §
The planner must verify hashability of the container's component type(s) before deciding it can use a hash-based plan type. This step was missed in some places, leading to “could not identify a hash function” failures at execution.
Related records (4)
- Same changePostgreSQL 18.6 · Add missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges)
- Same changePostgreSQL 17.11 · Add missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges)
- Same changePostgreSQL 15.19 · Add missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges)
- Same changePostgreSQL 14.24 · Add missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges)
Bug fixesFix mis-optimization of COUNT window functions that have an EXCLUDE clause or lack ORDER BY
Changes
Fix mis-optimization of COUNT window functions that have an EXCLUDE clause or lack ORDER BY (Chengpeng Yan, David Rowley) §
These window functions were treated as monotonic when they should not be, allowing wrong answers to be computed.
Related records (3)
- Same changePostgreSQL 18.6 · Fix mis-optimization of COUNT window functions that have an EXCLUDE clause or lack ORDER BY
- Same changePostgreSQL 17.11 · Fix mis-optimization of COUNT window functions that have an EXCLUDE clause or lack ORDER BY
- Same changePostgreSQL 15.19 · Fix mis-optimization of COUNT window functions that have an EXCLUDE clause or lack ORDER BY
Bug fixesFix ALTER COLUMN ... DROP EXPRESSION to work when there are multiple levels of partitions
Changes
Fix ALTER COLUMN ... DROP EXPRESSION to work when there are multiple levels of partitions (Alberto Piai) §
Related records (4)
- Same changePostgreSQL 18.6 · Fix ALTER COLUMN ... DROP EXPRESSION to work when there are multiple levels of partitions
- Same changePostgreSQL 17.11 · Fix ALTER COLUMN ... DROP EXPRESSION to work when there are multiple levels of partitions
- Same changePostgreSQL 15.19 · Fix ALTER COLUMN ... DROP EXPRESSION to work when there are multiple levels of partitions
- Same changePostgreSQL 14.24 · Fix ALTER COLUMN ... DROP EXPRESSION to work when there are multiple levels of partitions
ImprovementsDisallow renaming a rule to _RETURN
Changes
Disallow renaming a rule to _RETURN (Tom Lane) §
That name is reserved for a view's ON SELECT rule, but ALTER RULE allowed renaming other rules to _RETURN, causing trouble later.
Related records (4)
Bug fixesFix missing lock release for role membership grants in DROP OWNED BY
Changes
Fix missing lock release for role membership grants in DROP OWNED BY (Jeff Davis) §
This oversight resulted in a warning message, followed by retaining a lock on the membership grant until the end of the transaction.
Bug fixesFix failure of EXPLAIN when deparsing SQL/JSON aggregates
Changes
Fix failure of EXPLAIN when deparsing SQL/JSON aggregates (Richard Guo) §
Some plan structures resulted in “invalid JsonConstructorExpr underlying node type” errors.
Related records (2)
Bug fixesFix use of REINDEX CONCURRENTLY with a deferred uniqueness constraint
Changes
Fix use of REINDEX CONCURRENTLY with a deferred uniqueness constraint (Nitin Motiani) §
The transient index copy created during REINDEX CONCURRENTLY was incorrectly marked as enforcing immediate uniqueness, causing spurious reports of constraint violation.
Related records (4)
- Same changePostgreSQL 18.6 · Fix use of REINDEX CONCURRENTLY with a deferred uniqueness constraint
- Same changePostgreSQL 17.11 · Fix use of REINDEX CONCURRENTLY with a deferred uniqueness constraint
- Same changePostgreSQL 15.19 · Fix use of REINDEX CONCURRENTLY with a deferred uniqueness constraint
- Same changePostgreSQL 14.24 · Fix use of REINDEX CONCURRENTLY with a deferred uniqueness constraint
Bug fixesFix matching of localized month/day names in to_date()
Changes
Fix matching of localized month/day names in to_date() (Heikki Linnakangas) §
The matching logic misbehaved in cases where case-folding changes the byte length of the string.
Related records (4)
- Related commitsPostgreSQL 18.6 · Fix matching of localized month/day names in to_date()
- Same changePostgreSQL 17.11 · Fix matching of localized month/day names in to_date()
- Same changePostgreSQL 15.19 · Fix matching of localized month/day names in to_date()
- Same changePostgreSQL 14.24 · Fix matching of localized month/day names in to_date()
Bug fixesFix incorrect NFC recomposition for Hangul U+11A7 (TBASE)
Changes
Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE) (Diego Frias, Michael Paquier) §
This character was treated as a valid T syllable, which it is not, and hence silently swallowed during normalization.
Related records (4)
- Same changePostgreSQL 18.6 · Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE)
- Same changePostgreSQL 17.11 · Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE)
- Same changePostgreSQL 15.19 · Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE)
- Same changePostgreSQL 14.24 · Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE)
ImprovementsAvoid possible truncation of output lexemes in case-insensitive synonym dictionaries
Changes
Avoid possible truncation of output lexemes in case-insensitive synonym dictionaries (Jeff Davis) §
If folding to lower case increased the byte length of a lexeme, it was incorrectly truncated to its original byte length when emitted.
Related records (4)
- Same changePostgreSQL 18.6 · Avoid possible truncation of output lexemes in case-insensitive synonym dictionaries
- Same changePostgreSQL 17.11 · Avoid possible truncation of output lexemes in case-insensitive synonym dictionaries
- Same changePostgreSQL 15.19 · Avoid possible truncation of output lexemes in case-insensitive synonym dictionaries
- Same changePostgreSQL 14.24 · Avoid possible truncation of output lexemes in case-insensitive synonym dictionaries
Bug fixesFix typo in hash_record_extended()
Changes
Fix typo in hash_record_extended() (Man Zeng) §
The code failed to initialize the second isnull argument passed to FunctionCallInvoke(). This is harmless for existing in-core extended hash support functions, which will not examine that value. However, extension-provided hash functions could be affected if they inspect PG_ARGISNULL(1).
Related records (4)
Bug fixesFix pg_get_publication_tables() to not fail if a publishable table is dropped concurrently
Changes
Fix pg_get_publication_tables() to not fail if a publishable table is dropped concurrently (Bharath Rupireddy) §
Bug fixesPrevent satisfies_hash_partition() from crashing with VARIADIC NULL
Changes
Prevent satisfies_hash_partition() from crashing with VARIADIC NULL (Robert Haas) §
Related records (4)
- Same changePostgreSQL 18.6 · Prevent satisfies_hash_partition() from crashing with VARIADIC NULL
- Same changePostgreSQL 17.11 · Prevent satisfies_hash_partition() from crashing with VARIADIC NULL
- Same changePostgreSQL 15.19 · Prevent satisfies_hash_partition() from crashing with VARIADIC NULL
- Same changePostgreSQL 14.24 · Prevent satisfies_hash_partition() from crashing with VARIADIC NULL
ImprovementsReport invalid-weight errors more cleanly and consistently in tsvector_filter() and allied functions
Changes
Report invalid-weight errors more cleanly and consistently in tsvector_filter() and allied functions (Ewan Young) §
In particular, report weight characters that are not printable ASCII in octal form (\), as nnncharout() would render them. This avoids possibly producing an invalidly-encoded error message.
Related records (4)
- Same changePostgreSQL 18.6 · Report invalid-weight errors more cleanly and consistently in tsvector_filter() and allied functions
- Same changePostgreSQL 17.11 · Report invalid-weight errors more cleanly and consistently in tsvector_filter() and allied functions
- Same changePostgreSQL 15.19 · Report invalid-weight errors more cleanly and consistently in tsvector_filter() and allied functions
- Same changePostgreSQL 14.24 · Report invalid-weight errors more cleanly and consistently in tsvector_filter() and allied functions
Bug fixesFix mishandling of namespace nodes in xpath()
ImprovementsTreat an undefined jsonpath variable as an error even when no variables are supplied
Changes
Treat an undefined jsonpath variable as an error even when no variables are supplied (Andrey Rachitskiy) §
The jsonb @? and @@ operators cannot supply any variables to be used in their jsonpath expressions. This code path erroneously treated an unknown jsonpath variable as a JSON null, rather than raising an error as expected. Aside from not being the expected behavior, this mistake could result in unbounded memory consumption.
Bug fixesFix NULL-pointer crash when IS JSON or similar constructs have an argument that is of string category but lacks a cast to type text
Changes
Fix NULL-pointer crash when IS JSON or similar constructs have an argument that is of string category but lacks a cast to type text (Ayush Tiwari) §
There are no such data types in core PostgreSQL, but the problem is reachable with some extension types.
Related records (2)
- Same changePostgreSQL 18.6 · Fix NULL-pointer crash when IS JSON or similar constructs have an argument that is of string category but lacks a cast to type text
- Same changePostgreSQL 17.11 · Fix NULL-pointer crash when IS JSON or similar constructs have an argument that is of string category but lacks a cast to type text
ImprovementsAvoid machine-dependent behavior when dividing the smallest possible money value by -1
Changes
Avoid machine-dependent behavior when dividing the smallest possible money value by -1 (Andrey Rachitskiy) §
Related records (4)
- Same changePostgreSQL 18.6 · Avoid machine-dependent behavior when dividing the smallest possible money value by -1
- Same changePostgreSQL 17.11 · Avoid machine-dependent behavior when dividing the smallest possible money value by -1
- Same changePostgreSQL 15.19 · Avoid machine-dependent behavior when dividing the smallest possible money value by -1
- Same changePostgreSQL 14.24 · Avoid machine-dependent behavior when dividing the smallest possible money value by -1
Bug fixesFix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary
Changes
Fix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary (Tom Lane) §
Related records (4)
- Same changePostgreSQL 18.6 · Fix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary
- Same changePostgreSQL 17.11 · Fix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary
- Same changePostgreSQL 15.19 · Fix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary
- Same changePostgreSQL 14.24 · Fix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary
Bug fixesFix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files
Changes
Fix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files (Andrey Rachitskiy) §
Related records (4)
- Same changePostgreSQL 18.6 · Fix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files
- Same changePostgreSQL 17.11 · Fix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files
- Same changePostgreSQL 15.19 · Fix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files
- Same changePostgreSQL 14.24 · Fix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files
ImprovementsPrevent access to other sessions' temporary tables
Changes
Prevent access to other sessions' temporary tables (Jim Jones, Daniil Davydov, Alexander Korotkov) §
Some code paths failed to prevent this, leading to silently wrong (inconsistent) results.
Related records (2)
ImprovementsHonor query cancel and vacuum delay during GIN index posting-tree cleanup
Changes
Honor query cancel and vacuum delay during GIN index posting-tree cleanup (Paul Kim, Alexander Korotkov) §
The posting tree for a common value can be large, so that this missed check could allow vacuum to run for a long time before noticing an interrupt.
Related records (4)
- Same changePostgreSQL 18.6 · Honor query cancel and vacuum delay during GIN index posting-tree cleanup
- Same changePostgreSQL 17.11 · Honor query cancel and vacuum delay during GIN index posting-tree cleanup
- Same changePostgreSQL 15.19 · Honor query cancel and vacuum delay during GIN index posting-tree cleanup
- Same changePostgreSQL 14.24 · Honor query cancel and vacuum delay during GIN index posting-tree cleanup
Bug fixesFix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans
Changes
Fix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans (Peter Geoghegan) §
This error could lead to emitting corrupted data from an index-only scan plan. The only affected core opclass is GiST's range_ops, and it could only fail if the range column were not the first index column.
Related records (4)
- Same changePostgreSQL 18.6 · Fix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans
- Same changePostgreSQL 17.11 · Fix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans
- Same changePostgreSQL 15.19 · Fix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans
- Same changePostgreSQL 14.24 · Fix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans
ImprovementsEnsure that the new last block of a bulk-extended table is added to its free space map promptly
Changes
Ensure that the new last block of a bulk-extended table is added to its free space map promptly (Jingtang Zhang) §
An off-by-one error caused the last block of a multi-block table extension to not be marked as free in the map. This would eventually get corrected by vacuum, but meanwhile the space wouldn't be used.
ImprovementsWhen creating directories, tolerate concurrent creation of the same directory
Changes
When creating directories, tolerate concurrent creation of the same directory (Andrew Dunstan, Tom Lane) §
Related records (4)
- Same changePostgreSQL 18.6 · When creating directories, tolerate concurrent creation of the same directory
- Same changePostgreSQL 17.11 · When creating directories, tolerate concurrent creation of the same directory
- Same changePostgreSQL 15.19 · When creating directories, tolerate concurrent creation of the same directory
- Same changePostgreSQL 14.24 · When creating directories, tolerate concurrent creation of the same directory
ImprovementsPrevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on
Changes
Prevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on (Bertrand Drouvot) § §
The shared lock will conflict with any attempt to drop the depended-on object, eliminating the race condition that formerly existed. For example, if one session drops a schema (that appears empty to it) concurrently with some other session creating a function in that schema, previously both transactions could commit, leaving an invalid function definition behind. Now, one transaction or the other will fail.
Related records (4)
- Same changePostgreSQL 18.6 · Prevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on
- Same changePostgreSQL 17.11 · Prevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on
- Same changePostgreSQL 15.19 · Prevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on
- Same changePostgreSQL 14.24 · Prevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on
Bug fixesFix race condition in conflict detection for SERIALIZABLE isolation mode
Changes
Fix race condition in conflict detection for SERIALIZABLE isolation mode (Peter Geoghegan) §
A conflict could be missed when examining an initially-empty btree index, allowing failure of serializability due to improperly allowing conflicting transactions to commit.
Related records (4)
- Same changePostgreSQL 18.6 · Fix race condition in conflict detection for SERIALIZABLE isolation mode
- Same changePostgreSQL 17.11 · Fix race condition in conflict detection for SERIALIZABLE isolation mode
- Same changePostgreSQL 15.19 · Fix race condition in conflict detection for SERIALIZABLE isolation mode
- Same changePostgreSQL 14.24 · Fix race condition in conflict detection for SERIALIZABLE isolation mode
Bug fixesFix race condition in ProcSignalBarrier code
Changes
Fix race condition in ProcSignalBarrier code (Masahiko Sawada) §
This error could result in processes getting stuck, typically after reporting “still waiting for backend with PID nnnn to accept ProcSignalBarrier”.
Related records (3)
Bug fixesFix race conditions when a set of processes that belong to the same lock group exit at the same time
Changes
Fix race conditions when a set of processes that belong to the same lock group exit at the same time (Vlad Lesin) § §
These errors could lead to PANIC aborts, with messages such as “latch already owned”. The issue does not normally arise in regular parallel query, since the leader won't exit before seeing its workers finish; but some extensions reach the problem.
Related records (4)
- Same changePostgreSQL 18.6 · Fix race conditions when a set of processes that belong to the same lock group exit at the same time
- Same changePostgreSQL 17.11 · Fix race conditions when a set of processes that belong to the same lock group exit at the same time
- Same changePostgreSQL 15.19 · Fix race conditions when a set of processes that belong to the same lock group exit at the same time
- Same changePostgreSQL 14.24 · Fix race conditions when a set of processes that belong to the same lock group exit at the same time
Bug fixesFix race with timeline selection in logical decoding during standby promotion
Changes
Fix race with timeline selection in logical decoding during standby promotion (Bertrand Drouvot) § § §
Logical decoding being performed on the standby could fail with a “requested WAL segment has already been removed” error. A repeat attempt would succeed, so there was no permanent problem but there was an availability hazard.
ImprovementsAvoid exposing a WAL receiver's full connection string during timeline jumps
Changes
Avoid exposing a WAL receiver's full connection string during timeline jumps (Chao Li) §
The pg_stat_wal_receiver view should show a sanitized version of the connection string, without sensitive data. But it transiently showed the full string when we re-use an existing WAL receiver.
Related records (4)
- Same changePostgreSQL 18.6 · Avoid exposing a WAL receiver's full connection string during timeline jumps
- Same changePostgreSQL 17.11 · Avoid exposing a WAL receiver's full connection string during timeline jumps
- Same changePostgreSQL 15.19 · Avoid exposing a WAL receiver's full connection string during timeline jumps
- Same changePostgreSQL 14.24 · Avoid exposing a WAL receiver's full connection string during timeline jumps
Bug fixesUse run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication
Changes
Use run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication (Varik Matevosyan) §
A malicious or buggy publisher could send inconsistent numbers of columns. While we could not find a scenario in which this would have serious ill effects, extra caution seems warranted.
Related records (4)
- Same changePostgreSQL 18.6 · Use run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication
- Same changePostgreSQL 17.11 · Use run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication
- Same changePostgreSQL 15.19 · Use run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication
- Same changePostgreSQL 14.24 · Use run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication
ImprovementsClean up quoting of string parameters within constructed replication commands
Changes
Clean up quoting of string parameters within constructed replication commands (Tom Lane) §
Various places that generate replication commands were not being adequately careful about quoting replication slot names and other parameters that need to be inserted into those commands. This could result in unexpected syntax errors in those commands. In principle, a crafted replication slot name could result in SQL injection; but such a scenario seems very unlikely to occur in practice, since replication operations can only be invoked by highly-privileged users and there is no reason for them to use a slot name coming from an untrustworthy source.
Related records (4)
- Same changePostgreSQL 18.6 · Clean up quoting of string parameters within constructed replication commands
- Same changePostgreSQL 17.11 · Clean up quoting of string parameters within constructed replication commands
- Same changePostgreSQL 15.19 · Clean up quoting of string parameters within constructed replication commands
- Same changePostgreSQL 14.24 · Clean up quoting of string parameters within constructed replication commands
Bug fixesFix logical decoding of empty prepared transactions
Changes
Fix logical decoding of empty prepared transactions (Masahiko Sawada) §
A prepared transaction that did not cause any decodable updates could result in sending COMMIT/ROLLBACK PREPARED to the output plugin with no preceding PREPARE. For the built-in subscriber this breaks replication, and other plugins will probably not like it either.
Related records (4)
- Same changePostgreSQL 18.6 · Fix logical decoding of empty prepared transactions
- Same changePostgreSQL 17.11 · Fix logical decoding of empty prepared transactions
- Same changePostgreSQL 15.19 · Fix logical decoding of empty prepared transactions
- Same changePostgreSQL 14.24 · Fix logical decoding of empty prepared transactions
Bug fixesFix corruption of unlogged sequences after standby promotion
Changes
Fix corruption of unlogged sequences after standby promotion (Fujii Masao) §
Previously, if an unlogged sequence was created on the primary and replicated to a standby, accessing the sequence after promoting the standby could fail with “bad magic number in sequence” or related errors.
Bug fixesFix cascading standby reconnect failure after archive fallback
Changes
Fix cascading standby reconnect failure after archive fallback (Marco Nenciarini) §
A cascading standby could fail to reconnect to its upstream standby with “requested starting point ... is ahead of the WAL flush position” after falling back to archive recovery.
Related records (9)
- Same changePostgreSQL 18.6 · Fix cascading standby reconnect failure after archive fallback
- Related commitsPostgreSQL 18.6 · Fix buffer overrun with long time zone abbreviation in to_char()
- Related commitsPostgreSQL 17.11 · Fix buffer overrun with long time zone abbreviation in to_char()
- Same changePostgreSQL 17.11 · Fix cascading standby reconnect failure after archive fallback
- Related commitsPostgreSQL 16.15 · Fix buffer overrun with long time zone abbreviation in to_char()
- Related commitsPostgreSQL 15.19 · Fix buffer overrun with long time zone abbreviation in to_char()
- Same changePostgreSQL 15.19 · Fix cascading standby reconnect failure after archive fallback
- Same changePostgreSQL 14.24 · Fix cascading standby reconnect failure after archive fallback
- Related commitsPostgreSQL 14.24 · Fix buffer overrun with long time zone abbreviation in to_char()
ImprovementsAvoid race condition while dropping ephemeral replication slots
Changes
Avoid race condition while dropping ephemeral replication slots (Zhijie Hou) §
The slot-releasing code performed some additional updates to the replication slot's shared-memory entry after releasing the slot. This is unsafe since another session could immediately re-use the dropped slot's shared-memory entry. Skip those updates in the case of an ephemeral slot.
Related records (4)
- Same changePostgreSQL 18.6 · Avoid race condition while dropping ephemeral replication slots
- Same changePostgreSQL 17.11 · Avoid race condition while dropping ephemeral replication slots
- Same changePostgreSQL 15.19 · Avoid race condition while dropping ephemeral replication slots
- Same changePostgreSQL 14.24 · Avoid race condition while dropping ephemeral replication slots
Bug fixesFix stale progress reports during logical replication table synchronization
Changes
Fix stale progress reports during logical replication table synchronization (Shinya Kato) §
Previously, the pg_stat_progress_copy view in the subscriber would continue to show the initial COPY operation as active even after the data copy had finished. The stale entry remained visible until synchronization caught up with the publisher.
Related records (4)
- Same changePostgreSQL 18.6 · Fix stale progress reports during logical replication table synchronization
- Same changePostgreSQL 17.11 · Fix stale progress reports during logical replication table synchronization
- Same changePostgreSQL 15.19 · Fix stale progress reports during logical replication table synchronization
- Same changePostgreSQL 14.24 · Fix stale progress reports during logical replication table synchronization
ImprovementsClear base backup progress on backup failure
Changes
Clear base backup progress on backup failure (Chao Li) § §
Previously the pg_stat_progress_basebackup view would continue to show a stale progress entry after a failure, until the replication client disconnected. pg_basebackup normally disconnects immediately, but other clients might not.
Related records (3)
Bug fixesFix possible PANIC due to concurrent drop of pgstats entries when track_functions is enabled
Changes
Fix possible PANIC due to concurrent drop of pgstats entries when track_functions is enabled (Sami Imseih, Michael Paquier) § § §
Related records (3)
- Same changePostgreSQL 18.6 · Fix possible PANIC due to concurrent drop of pgstats entries when track_functions is enabled
- Same changePostgreSQL 17.11 · Fix possible PANIC due to concurrent drop of pgstats entries when track_functions is enabled
- Same changePostgreSQL 15.19 · Fix possible PANIC due to concurrent drop of pgstats entries when track_functions is enabled
ImprovementsClean up broken local pgstats entry after failing to obtain space for the corresponding shared hashtable entry
Changes
Clean up broken local pgstats entry after failing to obtain space for the corresponding shared hashtable entry (Niall Newman) §
Failure to do this led to a null-pointer dereference the next time the local entry was used.
Related records (3)
- Same changePostgreSQL 18.6 · Clean up broken local pgstats entry after failing to obtain space for the corresponding shared hashtable entry
- Same changePostgreSQL 17.11 · Clean up broken local pgstats entry after failing to obtain space for the corresponding shared hashtable entry
- Same changePostgreSQL 15.19 · Clean up broken local pgstats entry after failing to obtain space for the corresponding shared hashtable entry
Bug fixesIn PL/Perl, avoid NULL pointer dereference crash when working with an invalid PostgreSQL::InServer::ARRAY object
Changes
In PL/Perl, avoid NULL pointer dereference crash when working with an invalid PostgreSQL::InServer::ARRAY object (Xing Guo) §
Related records (4)
- Same changePostgreSQL 18.6 · In PL/Perl, avoid NULL pointer dereference crash when working with an invalid PostgreSQL::InServer::ARRAY object
- Same changePostgreSQL 17.11 · In PL/Perl, avoid NULL pointer dereference crash when working with an invalid PostgreSQL::InServer::ARRAY object
- Same changePostgreSQL 15.19 · In PL/Perl, avoid NULL pointer dereference crash when working with an invalid PostgreSQL::InServer::ARRAY object
- Same changePostgreSQL 14.24 · In PL/Perl, avoid NULL pointer dereference crash when working with an invalid PostgreSQL::InServer::ARRAY object
ImprovementsIn PL/Python, properly check for errors when working with sequence and mapping objects
Changes
In PL/Python, properly check for errors when working with sequence and mapping objects (Richard Guo) §
Previously, a broken object or an unhandled exception could result in a NULL pointer dereference crash.
Related records (4)
- Same changePostgreSQL 18.6 · In PL/Python, properly check for errors when working with sequence and mapping objects
- Same changePostgreSQL 17.11 · In PL/Python, properly check for errors when working with sequence and mapping objects
- Same changePostgreSQL 15.19 · In PL/Python, properly check for errors when working with sequence and mapping objects
- Same changePostgreSQL 14.24 · In PL/Python, properly check for errors when working with sequence and mapping objects
ImprovementsIn libpq, always drain all pending bytes from the SSL or GSS decryption buffer during pqReadData()
Changes
In libpq, always drain all pending bytes from the SSL or GSS decryption buffer during pqReadData() (Jacob Champion) § § § §
This avoids edge cases where libpq or its calling application waits for more data to arrive on the socket, but actually all the data has already arrived.
Related records (4)
- Same changePostgreSQL 18.6 · In libpq, always drain all pending bytes from the SSL or GSS decryption buffer during pqReadData()
- Same changePostgreSQL 17.11 · In libpq, always drain all pending bytes from the SSL or GSS decryption buffer during pqReadData()
- Same changePostgreSQL 15.19 · In libpq, always drain all pending bytes from the SSL or GSS decryption buffer during pqReadData()
- Same changePostgreSQL 14.24 · In libpq, always drain all pending bytes from the SSL or GSS decryption buffer during pqReadData()
ImprovementsAllow libpq to accept ParameterDescription messages exceeding 30000 bytes
Changes
Allow libpq to accept ParameterDescription messages exceeding 30000 bytes (Ning Sun) §
Previously, this message type was not among those that libpq's validity heuristics believed could be long. The limit resulted in failure for prepared queries having more than 7498 parameters, which is unlikely but supported.
Related records (4)
- Same changePostgreSQL 18.6 · Allow libpq to accept ParameterDescription messages exceeding 30000 bytes
- Same changePostgreSQL 17.11 · Allow libpq to accept ParameterDescription messages exceeding 30000 bytes
- Same changePostgreSQL 15.19 · Allow libpq to accept ParameterDescription messages exceeding 30000 bytes
- Same changePostgreSQL 14.24 · Allow libpq to accept ParameterDescription messages exceeding 30000 bytes
ImprovementsReject multiple descriptor header items in ecpg's GET/SET DESCRIPTOR statements
Changes
Reject multiple descriptor header items in ecpg's GET/SET DESCRIPTOR statements (Masashi Kamura) §
Previously the grammar allowed this syntax, but broken C code was generated. Adjust the grammar and the documentation to allow only one header item.
Related records (4)
- Same changePostgreSQL 18.6 · Reject multiple descriptor header items in ecpg's GET/SET DESCRIPTOR statements
- Same changePostgreSQL 17.11 · Reject multiple descriptor header items in ecpg's GET/SET DESCRIPTOR statements
- Same changePostgreSQL 15.19 · Reject multiple descriptor header items in ecpg's GET/SET DESCRIPTOR statements
- Same changePostgreSQL 14.24 · Reject multiple descriptor header items in ecpg's GET/SET DESCRIPTOR statements
ImprovementsMake line widths match in psql's expanded aligned output format
Changes
Make line widths match in psql's expanded aligned output format (Pavel Stehule) §
When the table's data rows are narrower than the record header lines, widen the data rows to match the headers, avoiding unsightly output.
Related records (4)
- Same changePostgreSQL 18.6 · Make line widths match in psql's expanded aligned output format
- Same changePostgreSQL 17.11 · Make line widths match in psql's expanded aligned output format
- Same changePostgreSQL 15.19 · Make line widths match in psql's expanded aligned output format
- Same changePostgreSQL 14.24 · Make line widths match in psql's expanded aligned output format
Bug fixesFix psql's privilege check for showing database size in \l+
Changes
Fix psql's privilege check for showing database size in \l+ (Christoph Berg) §
The underlying server function permits users who have pg_read_all_stats privileges to see the sizes of all databases, even if they lack CONNECT privilege. But psql was unaware of that provision and would not call the function unless the user has CONNECT privilege.
Related records (4)
- Same changePostgreSQL 18.6 · Fix psql's privilege check for showing database size in \l+
- Same changePostgreSQL 17.11 · Fix psql's privilege check for showing database size in \l+
- Same changePostgreSQL 15.19 · Fix psql's privilege check for showing database size in \l+
- Same changePostgreSQL 14.24 · Fix psql's privilege check for showing database size in \l+
Bug fixesFix psql's tab completion for \df to consider procedures too
Changes
Fix psql's tab completion for \df to consider procedures too (Erik Wienhold) §
Related records (4)
- Same changePostgreSQL 18.6 · Fix psql's tab completion for \df to consider procedures too
- Same changePostgreSQL 17.11 · Fix psql's tab completion for \df to consider procedures too
- Same changePostgreSQL 15.19 · Fix psql's tab completion for \df to consider procedures too
- Same changePostgreSQL 14.24 · Fix psql's tab completion for \df to consider procedures too
Bug fixesFix thread-safety bug in pgbench
Changes
Fix thread-safety bug in pgbench (Fujii Masao) §
When pgbench runs with multiple threads and the --verbose-errors option, different threads could attempt to use the same buffer to construct error messages, leading to corrupted log output.
Related records (3)
ImprovementsUse the source cluster's group-read file permissions for pg_recvlogical output files
Changes
Use the source cluster's group-read file permissions for pg_recvlogical output files (Fujii Masao) §
pg_recvlogical was documented to behave this way, but it never actually enabled group-read.
Related records (4)
- Same changePostgreSQL 18.6 · Use the source cluster's group-read file permissions for pg_recvlogical output files
- Same changePostgreSQL 17.11 · Use the source cluster's group-read file permissions for pg_recvlogical output files
- Same changePostgreSQL 15.19 · Use the source cluster's group-read file permissions for pg_recvlogical output files
- Same changePostgreSQL 14.24 · Use the source cluster's group-read file permissions for pg_recvlogical output files
ImprovementsIn contrib/amcheck, handle short-header varlena datums correctly
Changes
In contrib/amcheck, handle short-header varlena datums correctly (Andrey Borodin) §
This error could result in doing excess work while verifying a btree index, but seems not to have had any worse consequences.
Related records (4)
- Same changePostgreSQL 18.6 · In contrib/amcheck, handle short-header varlena datums correctly
- Same changePostgreSQL 17.11 · In contrib/amcheck, handle short-header varlena datums correctly
- Same changePostgreSQL 15.19 · In contrib/amcheck, handle short-header varlena datums correctly
- Same changePostgreSQL 14.24 · In contrib/amcheck, handle short-header varlena datums correctly
Bug fixesIn contrib/btree_gist, fix NaN handling in the float4 and float8 opclasses
Changes
In contrib/btree_gist, fix NaN handling in the float4 and float8 opclasses (Bill Kim, Tom Lane) §
Comparisons, as well as the GiST penalty and distance functions, did not account for NaN and would give the wrong answer when handed one. It is recommended to reindex btree_gist indexes on float columns after installing this update, if there is any possibility that there are NaN entries in those columns.
Related records (4)
- Same changePostgreSQL 18.6 · In contrib/btree_gist, fix NaN handling in the float4 and float8 opclasses
- Same changePostgreSQL 17.11 · In contrib/btree_gist, fix NaN handling in the float4 and float8 opclasses
- Same changePostgreSQL 15.19 · In contrib/btree_gist, fix NaN handling in the float4 and float8 opclasses
- Same changePostgreSQL 14.24 · In contrib/btree_gist, fix NaN handling in the float4 and float8 opclasses
Bug fixesIn contrib/btree_gist, fix searches using a not-equal operator
Changes
In contrib/btree_gist, fix searches using a not-equal operator (Ayush Tiwari) §
For variable-length data types, the code for scanning non-leaf index pages applied the wrong comparison function, leading to wrong results and potentially crashes.
Related records (4)
- Same changePostgreSQL 18.6 · In contrib/btree_gist, fix searches using a not-equal operator
- Same changePostgreSQL 17.11 · In contrib/btree_gist, fix searches using a not-equal operator
- Same changePostgreSQL 15.19 · In contrib/btree_gist, fix searches using a not-equal operator
- Same changePostgreSQL 14.24 · In contrib/btree_gist, fix searches using a not-equal operator
Bug fixesFix unguarded recursion and loops in contrib/hstore_plperl, contrib/jsonb_plperl, and contrib/jsonb_plpython
Changes
Fix unguarded recursion and loops in contrib/hstore_plperl, contrib/jsonb_plperl, and contrib/jsonb_plpython (Aleksander Alekseev) § §
Prevent stack overflow when dealing with deeply nested jsonb values, and allow interruption of the infinite loop caused when attempting to dereference circular chains of Perl object references.
Related records (4)
- Same changePostgreSQL 18.6 · Fix unguarded recursion and loops in contrib/hstore_plperl, contrib/jsonb_plperl, and contrib/jsonb_plpython
- Same changePostgreSQL 17.11 · Fix unguarded recursion and loops in contrib/hstore_plperl, contrib/jsonb_plperl, and contrib/jsonb_plpython
- Same changePostgreSQL 15.19 · Fix unguarded recursion and loops in contrib/hstore_plperl, contrib/jsonb_plperl, and contrib/jsonb_plpython
- Same changePostgreSQL 14.24 · Fix unguarded recursion and loops in contrib/hstore_plperl, contrib/jsonb_plperl, and contrib/jsonb_plpython
Bug fixesFix missed release of statistics catcache entry in contrib/intarray
Changes
Fix missed release of statistics catcache entry in contrib/intarray (Man Zeng) §
This oversight led to warnings like “resource was not closed: cache pg_statistic”.
Related records (4)
- Same changePostgreSQL 18.6 · Fix missed release of statistics catcache entry in contrib/intarray
- Same changePostgreSQL 17.11 · Fix missed release of statistics catcache entry in contrib/intarray
- Same changePostgreSQL 15.19 · Fix missed release of statistics catcache entry in contrib/intarray
- Same changePostgreSQL 14.24 · Fix missed release of statistics catcache entry in contrib/intarray
Bug fixesIn contrib/ltree, fix integer overflow in comparisons
Changes
In contrib/ltree, fix integer overflow in comparisons (Ayush Tiwari) §
ltree values containing more than about 14,653 labels resulted in wrong comparison answers due to overflow. If a btree index contains such values, it is probably corrupt and should be reindexed after installing this update.
Related records (4)
- Same changePostgreSQL 18.6 · In contrib/ltree, fix integer overflow in comparisons
- Same changePostgreSQL 17.11 · In contrib/ltree, fix integer overflow in comparisons
- Same changePostgreSQL 15.19 · In contrib/ltree, fix integer overflow in comparisons
- Same changePostgreSQL 14.24 · In contrib/ltree, fix integer overflow in comparisons
Bug fixesFix array overrun in contrib/pg_surgery's heap_force_kill and heap_force_freeze functions
Changes
Fix array overrun in contrib/pg_surgery's heap_force_kill and heap_force_freeze functions (Michael Paquier) §
Attempting to change a TID whose offset number equals MaxHeapTuplesPerPage wrote one byte past the end of the allocated array, potentially crashing the server.
Related records (4)
- Same changePostgreSQL 18.6 · Fix array overrun in contrib/pg_surgery's heap_force_kill and heap_force_freeze functions
- Same changePostgreSQL 17.11 · Fix array overrun in contrib/pg_surgery's heap_force_kill and heap_force_freeze functions
- Same changePostgreSQL 15.19 · Fix array overrun in contrib/pg_surgery's heap_force_kill and heap_force_freeze functions
- Same changePostgreSQL 14.24 · Fix array overrun in contrib/pg_surgery's heap_force_kill and heap_force_freeze functions
ImprovementsIn contrib/pg_surgery, avoid infinite loop with TID arrays having more than 64K elements
Changes
In contrib/pg_surgery, avoid infinite loop with TID arrays having more than 64K elements (Andrey Rachitskiy) §
Related records (4)
- Same changePostgreSQL 18.6 · In contrib/pg_surgery, avoid infinite loop with TID arrays having more than 64K elements
- Same changePostgreSQL 17.11 · In contrib/pg_surgery, avoid infinite loop with TID arrays having more than 64K elements
- Same changePostgreSQL 15.19 · In contrib/pg_surgery, avoid infinite loop with TID arrays having more than 64K elements
- Same changePostgreSQL 14.24 · In contrib/pg_surgery, avoid infinite loop with TID arrays having more than 64K elements
SecurityAvoid NULL-pointer dereference in contrib/refint's check_foreign_key()
Changes
Avoid NULL-pointer dereference in contrib/refint's check_foreign_key() (Ayush Tiwari) §
In the on-update-cascade case, a null value of a referenced column led to a crash. This is an oversight in the fix for CVE-2026-6637, but the code that was there before that wasn't really right either.
Related records (4)
- Same changePostgreSQL 18.6 · Avoid NULL-pointer dereference in contrib/refint's check_foreign_key()
- Same changePostgreSQL 17.11 · Avoid NULL-pointer dereference in contrib/refint's check_foreign_key()
- Same changePostgreSQL 15.19 · Avoid NULL-pointer dereference in contrib/refint's check_foreign_key()
- Same changePostgreSQL 14.24 · Avoid NULL-pointer dereference in contrib/refint's check_foreign_key()
Bug fixesFix contrib/seg to print segments with ~ certainty indicators correctly
Changes
Fix contrib/seg to print segments with ~ certainty indicators correctly (Ewan Young) §
Due to a typo, seg_out() did not print a ~ certainty indicator attached to a segment's upper boundary. Worse, if the lower boundary had ~ while the upper boundary had no indicator, the upper boundary was not printed at all, incorrectly converting the value into an open interval.
Related records (4)
- Same changePostgreSQL 18.6 · Fix contrib/seg to print segments with ~ certainty indicators correctly
- Same changePostgreSQL 17.11 · Fix contrib/seg to print segments with ~ certainty indicators correctly
- Same changePostgreSQL 15.19 · Fix contrib/seg to print segments with ~ certainty indicators correctly
- Same changePostgreSQL 14.24 · Fix contrib/seg to print segments with ~ certainty indicators correctly
Bug fixesFix crash with namespace nodes in contrib/xml2's xpath_nodeset() function
Changes
Fix crash with namespace nodes in contrib/xml2's xpath_nodeset() function (Andrey Chernyy, Michael Paquier) §
Related records (4)
- Same changePostgreSQL 18.6 · Fix crash with namespace nodes in contrib/xml2's xpath_nodeset() function
- Same changePostgreSQL 17.11 · Fix crash with namespace nodes in contrib/xml2's xpath_nodeset() function
- Same changePostgreSQL 15.19 · Fix crash with namespace nodes in contrib/xml2's xpath_nodeset() function
- Same changePostgreSQL 14.24 · Fix crash with namespace nodes in contrib/xml2's xpath_nodeset() function
ImprovementsSupport building PostgreSQL with Visual Studio 2026
ImprovementsSupport building PostgreSQL with OpenSSL 4
ImprovementsUpdate time zone data files to tzdata release 2026c
Changes
Update time zone data files to tzdata release 2026c (Tom Lane) §
Alberta (America/Edmonton) will be on year-round UTC-06 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be CST from that time forward. That seems likely to change, but it's unclear what new abbreviation will be used.
Morocco (Africa/Casablanca) will move to permanent UTC+00, without daylight saving time transitions, on 2026-09-20.
Related records (4)
- Same changePostgreSQL 18.6 · Update time zone data files to tzdata release 2026c
- Same changePostgreSQL 17.11 · Update time zone data files to tzdata release 2026c
- Same changePostgreSQL 15.19 · Update time zone data files to tzdata release 2026c
- Same changePostgreSQL 14.24 · Update time zone data files to tzdata release 2026c
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.