PostgreSQL 15.19 commit log

commit   : 2ff1375b5dd8bf09d8cb0e795974528180fd75ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:57:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:57:41 -0400    

commit   : 492b517f362a4325bbcd6c1aa6f1204b7696d7ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:35:48 -0400    

Security: CVE-2026-6470, CVE-2026-6471, CVE-2026-6469  

commit   : 1f2cda1948187d1b2ab4fc347ee73e56ce38292a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:15:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 12:15:10 -0400    

Security: CVE-2026-6464, CVE-2026-6469, CVE-2026-6470, CVE-2026-6471, CVE-2026-14662, CVE-2026-14663, CVE-2026-14664, CVE-2026-14666, CVE-2026-14668, CVE-2026-14669, CVE-2026-14670, CVE-2026-14671, CVE-2026-14672, CVE-2026-14673, CVE-2026-14676, CVE-2026-14677, CVE-2026-14678, CVE-2026-14679, CVE-2026-14680, CVE-2026-14681, CVE-2026-15741, CVE-2026-15742, CVE-2026-16238, CVE-2026-16239, CVE-2026-16241, CVE-2026-18024, CVE-2026-18408, CVE-2026-19385  

commit   : df245c37458315cf8a6ff08f4f8c3b1103857ed3    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    

This oversight in commit 71ea0d6795 allows a malicious server to  
inject shell commands into plain-text dump output that are run at  
restore time on the machine running psql.  To fix, interpret all  
text after \unrestrict until the end of the line as its argument.  
  
Reported-by: Lucas Velgus <velgusgus599@gmail.com>  
Reported-by: Filip Janus <fjanus@redhat.com>  
Reported-by: Daniel Bakker <daniel@jackds.nl>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-18408  
Backpatch-through: 14  

commit   : 953be116c978bf517e7d5e4498d75e229e6c5368    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    

The previous commit raises an ERROR during PGP operations if OpenSSL  
does not support the cipher in use. However, any existing messages  
created with faulty encryption will no longer be accessible via  
pgp_[sym|pub]_decrypt().  
  
To help users out of this situation, add a new ignore-cipher-failure  
option which reverts to the broken behavior during decryption only. A  
faulty encryption wrapper, created by an OpenSSL configuration that does  
not support the cipher, can then be stripped back off by that same  
OpenSSL in order to safely reencrypt it. (Note that when OpenSSL does  
support the cipher, corrupted messages will not be decrypted regardless  
of the ignore-cipher-failure setting; this is unchanged.)  
  
The new tests add a corrupted Blowfish message for both public- and  
symmetric-key decryption, resulting in the following test matrix:  
  
- Blowfish supported, default behavior:      fails to decrypt  
- Blowfish supported, ignore-cipher-failure: fails to decrypt  
- Blowfish unsupported, default behavior:    fails to load cipher  
- Blowfish unsupported, ignore-cipher-failure: strips faulty encryption  
  
The previous commit's change to the pubkey tests is expanded similarly:  
correctly encrypted messages cannot be decrypted by an OpenSSL that does  
not support the cipher, regardless of the option's setting, though the  
failure mode will change.  
  
Suggested-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-14663  
Backpatch-through: 14  

commit   : 472ef7e4a1d755723adf4c0b24851d822c0ef9f7    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    

PGP encryption was using px_cipher_encrypt without checking if any  
error was returned.  When OpenSSL is running in FIPS mode, or when  
the legacy provider hasn't been loaded, not all ciphers which are  
supported by the PGP code are available and fail the init step in  
px_cipher_encrypt.  Since the PGP encryption failed to notice this  
it XORed the non-encrypted block with the plaintext, effectively  
disabling the encryption.  
  
This was found due to a report of PGP encryption not respecting  
the pgcrypto.builtin_crypto_enabled flag and allowing Blowfish  
and DES.  This however turned out to be a false positive, since  
the PGP code only use ciphers from OpenSSL and not the built in  
ciphers.  
  
Bug: #19457  
Reported-by: Shishir Sharma <ansh01072001@gmail.com>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/19457-4bab15c17aea36c7@postgresql.org  
Security: CVE-2026-14663  
Backpatch-through: 14  

commit   : 3b925133b54df3fc89bcec47c525b6a7386dcc88    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    

This commit addresses two defects in this SQL function, the code  
assuming that:  
- The user-supplied string was long enough to contain a character of the  
length implied by the first byte.  It is possible to provide in input  
data that was able to disclose a few bytes of server memory, allowing  
out-of-bound reads.  
- Specific bytes had values within the expected range, using a set of  
assertions to validate them.  The assertions could be triggered on  
invalid input.  These are replaced by tests and error reports.  
  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-18024  

commit   : 3fdcfa8f7939783adff360f515ef7b37f1659c17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    

If the COPY command fails before sending PGRES_COPY_IN, psql did  
not realize that it ought to consume any in-line data following  
the command.  Failing to do so leads to trying to execute that  
data as SQL commands, which in the best case is wrong and in the  
worst case is a SQL-injection hazard.  
  
To fix:  
  
1. Extend psqlscan.l to recognize COPY ... FROM STDIN.  This can  
be done with a pretty simple extension to the logic that already  
recognizes nested BEGIN blocks within CREATE FUNCTION et al.  
But unlike that case, we need to consider and count multiple COPY  
commands within a single query string (separated by "\;").  The  
fallout from that is that psql_scan_reset must now always be called  
before starting a new query string.  (The comment for it that claimed  
we didn't need that because "the scan state must be INITIAL" was  
really obsolete already, since it has long reset more state besides  
start_state.)  
  
2. Teach handleCopyIn() to read and discard data when passed  
NULL for "conn".  
  
3. Add logic to SendQuery() to call handleCopyIn() that way  
if the query string contained COPY ... FROM STDIN command(s)  
that remain unaccounted-for at the end.  
  
Now that we have this counting logic, we can also detect  
if the backend sends an unexpected PGRES_COPY_IN message.  
That should never happen, but perhaps a malicious server  
could try to extract data that way.  
  
A side-effect of doing this is that we have to adjust a number of test  
scripts that thought they needn't write "\." after a COPY FROM STDIN  
that they expect to fail.  On the whole this is an improvement, since  
there's now a uniform rule "write \. after COPY FROM STDIN, whether  
you expect it to work or not".  But it is an annoying amount of test  
churn.  
  
A loose end in this patch is that if it has to skip data, it assumes  
that that data is text not binary.  It seems unduly difficult to  
detect whether the COPY command requested binary (we could handle the  
old-style COPY BINARY ... syntax, but not the new style with format  
options).  In practice, copying in-line binary data is unsupported  
anyway, because there's no way to write an end marker: the textual  
terminator sequence "\n\\.\n" could appear in binary data and there's  
no provision for escaping it, so neither psql nor the server look for  
it when in binary mode.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 14  
Security: CVE-2026-6464  

commit   : 8cdbabea74a42dedaa2731658529336e5ef5a5f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:31 -0700    

When we implemented \if ... \endif in psql, we arranged to  
save/restore the lexer's parenthesis depth counter across any chunk  
of input that we're ignoring.  At the time, that was sufficient,  
because no other part of PsqlScanState could need to be restored to  
its prior value.  However, commit e717a9a18 and follow-ons added  
more state fields that ought to be restored to their prior values.  
A problem would only be observed if someone tries to \if out a  
portion of a CREATE FUNCTION/PROCEDURE command that is relevant to  
BEGIN/END matching, which seems like a pretty unusual usage, so the  
lack of field reports isn't surprising.  Nonetheless it's a bug.  
  
To fix, replace the simple counter field in ConditionalStack  
entries with a pointer to a struct defined by psqlscan_int.h.  
(In the back branches, keep the old field and associated functions  
to minimize the risk of API/ABI breakage, even though it seems  
unlikely that any third-party code is using this.  Making the  
new struct private to psqlscan-related code should prevent API/ABI  
issues for future additions of this type.)  
  
In itself this is only a minor bug fix, but it's prerequisite  
infrastructure for the fix for CVE-2026-6464, which will add  
another such field.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 14  
Security: CVE-2026-6464  

commit   : 17b6083dbce2ba10ea5b5cf0156ec77cfa681eb5    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

Role membership, role attribute, and database ownership changes may  
impact the expected behavior of row-level security policies, but  
currently the plan cache doesn't take notice.  To fix, register  
syscache callbacks on pg_auth_members, pg_authid, and pg_database  
that invalidate the role-dependent plans.  Changes to other  
databases' pg_database rows are ignored.  
  
Reported-by: Ilya Staroverov <i.staroverov@ftdata.ru>  
Reported-by: Shinya Kato <shinya11.kato@gmail.com>  
Author: Ilya Staroverov <i.staroverov@ftdata.ru>  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Security: CVE-2026-14666  
Backpatch-through: 14  

commit   : c062734cdb8a7a966f4e39bda47279b9178f5da0    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

This omission allowed roles without USAGE on a type to create  
tables that depend on it, which could prevent the owner from  
changing the type later.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Security: CVE-2026-6470  
Backpatch-through: 14  

commit   : 6dbedd48b7c5024ef847572f073b94c3eed88042    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

This omission allowed roles without USAGE on a type to create  
stored expressions that depend on it, which could prevent the owner  
from changing the type later.  
  
The checks deliberately live in the command paths rather than the  
dependency-recording routines.  Those routines also run whenever  
the server re-derives an existing expression, and re-checking there  
would break routine maintenance for an owner who has since lost  
USAGE on a type its objects already reference.  (Checking in the  
dependency-recording routines would also require additional  
CommandCounterIncrement() calls to avoid spurious errors.)  
  
The addition of a parameter to AlterDomainAddConstraint() breaks  
ABI compatibility, but we are unaware of any impacted third-party  
code.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Security: CVE-2026-6470  
Backpatch-through: 14  

commit   : 97e2774028bdeda9499ec7bb8f15e706b17fd1c8    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

This omission allowed roles without USAGE on a type to create range  
types that depend on it, which could prevent the owner from  
changing the type later.  
  
Reported-by: Jingzhou Fu <fuboat@outlook.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Security: CVE-2026-6470  
Backpatch-through: 14  

commit   : 74916136fc6c9fcc5a94e1b53863703593009583    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

levenshtein() and levenshtein_less_equal() let the caller specify  
the insertion, deletion, and substitution costs, and  
fuzzystrmatch's corresponding SQL functions accept any 32-bit  
integer for each.  Since the distances are calculated with 32-bit  
arithmetic, large costs can cause overflows, thereby producing  
nonsensical results.  Certain inputs to levenshtein_less_equal()  
can even cause out-of-bounds writes.  To fix, use 64-bit arithmetic  
instead, and error whenever the final result won't fit in the  
returned 32-bit integer.  
  
We may want to teach these functions to reject negative costs, too,  
but that didn't seem appropriate for a security fix, and therefore  
it is left as a future exercise.  
  
Reported-by: Ben Morris in collaboration with Claude and Anthropic Research  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Security: CVE-2026-15742  
Backpatch-through: 14  

commit   : fc933ce0026942477e5a7909aa6624ae381ba083    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

When an EXECUTE or FETCH statement is executed, there are two portals:  
an outer portal that is created for the EXECUTE or FETCH statement itself,  
and an inner portal for the statement being executed on its behalf.  
Before this commit, nothing checked that these two portals agreed on  
the tuple descriptor of the rows being returned. This can be leveraged  
to disclose server memory contents and achieve arbitrary code execution.  
  
To prevent that, we can make use of an existing safety mechanism,  
added by Tom Lane in commit 2f48ede080f42b97b594fb14102c82ca1001b80c,  
which allows a tuplestore DestReceiver to be informed of the tupleDesc  
required by the caller, and which will cause an ERROR to occur if  
that doesn't match the tupleDesc of what emerges from the executor  
(modulo dropped columns, which aren't an issue in the case at hand).  
  
Reported-by: Ben Morris in collaboration with Claude and Anthropic Research  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Security: CVE-2026-16239  

commit   : 99f205407e85e1e54b1a89c0453c64ec3df3ed2d    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

REPLICATION users were not previously subject to restrictions on output  
plugin paths, so they were able to bypass LOAD-time protections during  
logical decoding. Unfortunately, adding the standard LOAD restrictions  
now would retroactively require all third-party output plugins to be  
installed under the $libdir/plugins directory. This would prevent the  
use of dynamic_library_path, introduce a wire incompatibility for  
clients, and require all plugin authors to check that their libraries  
are safe for use by any unprivileged user; we want to avoid that.  
  
Instead, introduce an output_plugin_libraries GUC so that DBAs can  
specify the output plugins that are trusted for use in logical decoding.  
For simplicity, superusers are subject to the restriction as well  
(though they're free to modify the GUC at will during a session, so no  
power is actually lost).  
  
The default setting is 'pgoutput, test_decoding'. If other third-party  
plugins are in use, DBAs will need to modify this parameter after they  
update. Some pointers have been added to the documentation to assist  
with this.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Reported-by: Vladimir Tokarev <vladimirelitokarev@gmail.com>  
Reported-by: Yu Kunpeng <yu443940816@live.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-6471  

commit   : e43e74756b4c89b1a145ffda0696acfa9f9b492a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

A grantee of amcheck function EXECUTE privilege could execute arbitrary  
functions as the owners of expression indexes that depend on the search  
path.  An expression like (lower(col)) was not vulnerable, because  
lower() is resolved at CREATE INDEX time.  However, an expression  
calling an sql-language or plpgsql-language function often was  
vulnerable, even if it used search_path only to find objects in  
pg_catalog.  The amcheck documentation has been warning about data  
disclosure after such a GRANT, not about function execution.  
  
This might cause new amcheck errors when index expressions rely on a  
broader search_path.  Such indexes have seen errors during auto-analyze  
since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and  
v17 amcheck always worked this way.  Hence, the risk is low.  
  
Leave a comment on the one other sandbox entrance that doesn't empty  
search_path.  In its case, the choice was valid.  
  
Back-patch to v14 (all supported versions), but v17 was safe already.  
Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally  
blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b  
(v18) unintentionally removed that protection.  Hence, this adds to v17  
just a test and a comment.  While emptying search_path became more  
widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17),  
none of its other changes blocked an attack available in v16, even when  
considering GRANT.  For example, brin_summarize_range() has had an owner  
check that GRANT does not override.  
  
Reported-by: 王跃林 <violin0613@tju.edu.cn>  
Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-14673  

commit   : 44ea6764be76ebb3d8dd01d60b5751acbe7b87d3    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

The parser accepts any string as an EXTRACT() field name, but  
deparsing does not quote and escape it accordingly.  To fix, quote  
and escape the field name during deparsing as needed.  It might be  
a good idea to validate the field name during parsing and  
deparsing, too, but that is left as a future exercise.  
  
Reported-by: Ben Morris in collaboration with Claude and Anthropic Research  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Security: CVE-2026-15741  
Backpatch-through: 14  

commit   : 5737110b60afffb90d1178acfaa0fe6881c2f5a9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

ECPG assumes that any bytea data it receives from a backend starts with  
'\x' as its first two bytes, but a check was missed to enforce that.  A  
rogue server sending some garbage bytea data would be able to crash a  
client, resulting in a client-side DoS, in the most common cases.  
  
Reported-by: ylwangtju <ylwangtju@qq.com>  
Backpatch-through: 14  
Security: CVE-2026-16241  

commit   : 1eb0d53804a42b9d2bcc645bbd4ec75fd7c5291a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:30 -0700    

Some of these could overflow on 32-bit systems with the right input.  
Convert all cases where we called palloc() with multiplication to fix  
them. Not all of them were bugs, but it's better to be safe than  
sorry.  
  
Reported-by: Tulya Project, Team Dhiutsa, Bitecope Technologies Private Ltd  
Backpatch-through: 14  
Security: CVE-2026-14677  

commit   : c7c82a88c312dc6ff626c037ac12846f1d0ca9c4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

The CACHESIGN.sign field is a BITVECP, not a TRGM, so you should not  
use GETSIGN() on it. You don't get a compiler warning because the  
GETSIGN() macro includes a cast. It resulted in a bogus read beyond  
end of buffer, which would cause bad split decisions or a crash if  
you're very unlucky.  
  
Reported-by: Mehmet D. INCE <mehmet@mehmetince.net>  
Backpatch-through: 14  
Security: CVE-2026-14678  

commit   : fb6d1ca8d746dc1ca0e32890a50d7b93d2fbebae    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

When ALTER TABLE ... ALTER COLUMN TYPE (or any subcommand that rebuilds  
them) drops and re-creates the extended statistics objects depending on  
the altered column, the re-created objects were owned by the role running  
ALTER TABLE rather than by the original owner of the statistics.  
  
Remember each object's owner before dropping it, and restore it on  
re-creation.  
  
CreateStatistics()'s signature changes and CreateStatsStmt gains a field,  
but no known third-party code calls the former or constructs the latter.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 14  
Security: CVE-2026-6469  

commit   : d6e861e19ab668b5e3567318bbded59b3359b79d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

numeric_combine() and several other state-combining functions for  
aggregates cheated for the case of both inputs being NULL: they  
returned a null pointer without bothering to mark it as a SQL NULL.  
This was harmless in the expected usage where the result would be  
passed to the same combine function or a related aggregate final  
function.  But it's bad news from a security standpoint, because  
now that value can be passed to an internal-accepting function  
even if said function is strict.  While a previous patch prevented  
such queries from being issued, it seems like good defense-in-depth  
to expend the few additional lines of code needed to do this properly.  
Comparable functions such as array_agg_combine() already do so.  
  
Reported-by: Amy Burnett (OpenAI Codex Security)  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-14680  

commit   : e926a9aacbd7a3b20d1e806b0e8445a62d9f8168    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

Allowing that is a security hole, since there are many different  
functions with different ideas of what their "internal" argument or  
result is.  We already had a defense against the easy case of  
"'foo'::internal", but that turns out to be insufficient.  Lock down  
both function and operator syntax.  Also disallow attempts to cast to  
or from type internal; those would mostly fail anyway, but we have  
created some holes with features such as CoerceViaIO.  
  
Reported-by: Amy Burnett (OpenAI Codex Security)  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-14680  

commit   : eb2fa2704b23ace6eadeb2958267b217c6533b96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

The maximum number of arguments allowed for an aggregate function  
is FUNC_MAX_ARGS-1 (since the underlying transfn and/or finalfn  
will be called with one more argument).  parse_func.c failed to  
enforce this, allowing construction of calls that would try to  
pass FUNC_MAX_ARGS+1 to the underlying functions, resulting in  
a memory stomp in the executor.  Add correct checking there.  
  
Since it's possible that a bad call has been stored in a view or  
SQL function, also add checks in various aggregate-related and  
window-function-related code that there are not more than  
FUNC_MAX_ARGS arguments.  These will also protect us against the  
possibility that we're trying to run a stored view that was made  
by a server executable with different FUNC_MAX_ARGS.  (Arguably,  
that scenario does not qualify as a security problem.  But let's  
just tighten up all of this while we're here, rather than split  
hairs over whether an overrun is reachable.)  
  
Likewise check in compute_function_hashkey.  Here the hazard is  
directly from a pg_proc row, but the scenario is the same.  
  
PL/Tcl has a similar issue with a fixed-size string buffer.  
Let's just replace that buffer with a Tcl_DString, removing the  
whole issue and making the code look more like what's around it.  
  
There are a lot of other FUNC_MAX_ARGS-sized arrays, but the rest  
have nearby guards already, some with comments explicitly pointing  
out the hazard of FUNC_MAX_ARGS changing.  
  
I also used palloc_array() in a few related places in funcapi.c.  
Those aren't live hazards AFAICS, but nearby code has been  
palloc_array-ified already, so it seemed inconsistent to not use  
it here.  
  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-14679  

commit   : 71ba5705d685ea56fc31309f5691c887275a632a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

The backend doesn't impose any particular limit on the length of this  
array, and since there could be entries for both input and output  
arguments, it's feasible for the length to exceed FUNC_MAX_ARGS  
even without funny business.  This could lead to crashes or worse.  
  
Moreover, pg_dump shouldn't rely on hard-coding FUNC_MAX_ARGS in the  
first place: it has no business assuming that the backend it's dumping  
from was compiled with the same value of FUNC_MAX_ARGS that it is.  
So the stanza in dumpFunc() that allocates exactly FUNC_MAX_ARGS space  
for the parsed OID array is fundamentally misguided.  And it's broken  
in another way too: if there are exactly FUNC_MAX_ARGS OIDs, then  
parseOidArray won't zero-fill any entries, allowing the subsequent  
loop to run off the end of the array.  A crash seems unlikely in  
this variant, but garbage output is certain.  
  
To fix, redesign parseOidArray's API so that it does the  
array-mallocing, which simplifies the callers anyway.  While we're  
here, tighten and modernize it a bit; in particular, split it into  
separate functions for OIDs and integers, as was foreseen long ago.  
This lets us get rid of the confusing type-punning involved in  
having IndxInfo.indkeys be declared as "Oid *" when it's really  
potentially-signed ints.  Also, most of the callers expect an exact  
number of array entries, so make it verify that not just check for  
"too many".  
  
I noted while testing that this dumpFunc() stanza isn't even reached  
during check-world.  Add a function with transform to the regression  
tests to rectify that.  
  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-19385  

commit   : b417744a7035dd9c282fedbf24f5d4c8d45fccb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

MatchNamedCall's arggiven array was declared FUNC_MAX_ARGS long,  
but we may actually use up to pronallargs elements, and that can  
be more than FUNC_MAX_ARGS if the function has OUT arguments  
(cf. ProcedureCreate).  Convert it to a palloc'd array.  
  
Reported-by: Zheng Yu <zheng@depthfirst.com>  
Reported-by: ylwangtju <ylwangtju@qq.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-14679  

commit   : 005ffaa7fad3a7cc730d94bcf1125b85b8b13ceb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

The special case here for estimating conditions involving a ctid  
column failed to check that the RHS constant is of type tid.  
While that'd always be true for the built-in operators that  
reference this selectivity estimator, a maliciously constructed  
operator could provide a user-controlled Datum value that would  
get interpreted as an ItemPointer pointer.  That at least risks  
SIGSEGV, and perhaps with a bit of sweat it could be used for  
server memory disclosure.  
  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 14  
Security: CVE-2026-14668  

commit   : cf4ae7c3bff2e22f3fb1a92a4cbaefb40a482251    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

Tied arrays might report different sizes each time they are inspected.  
To avoid generating a corrupt result array, fix plperl_array_to_datum()  
to read av_len() of each input array only once.  If the input does  
appear to get shorter, we'll fill nulls for the now-missing entries,  
which seems fine.  Conversely, if it gets longer, we'll ignore the new  
entries.  
  
plperl_to_hstore() assumed that Perl's hv_iterinit() returns the  
number of entries in the given Perl hash.  Usually that's true,  
but per the Perl docs, "the return value is currently only meaningful  
for hashes without tie magic".  That could potentially end in a memory  
stomp.  We don't depend on that result value anywhere else, so don't  
do so here either.  
  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Backpatch-through: 14  
Security: CVE-2026-14670  

commit   : 127a0673f868ae743cc4d36fd6aecb1316fd3eb0    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

setup_regexp_matches() sizes the buffer used to convert matched  
substrings back from pg_wchar form at the smaller of maxlen*eml and  
the original string's byte length, on the assumption that such a  
conversion cannot produce more bytes than the string it came  
from. That assumption holds only for validly encoded input. But  
pg_mb2wchar_with_len() silently accepts bytes that are invalid in the  
database encoding, turning each such byte into one pg_wchar, and  
converting that back can take more bytes than the input did. A string  
made of such bytes therefore overruns the conversion buffer by up to  
its own length, corrupting the following memory. regexp_match(),  
regexp_matches(), regexp_split_to_table() and regexp_split_to_array()  
are all affected.  
  
Fix by dropping the tighter bound and always allocating maxlen*eml + 1  
bytes.  
  
Reported-by: Francesco Verardi <frevadiscor89@gmail.com>  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-14664  

commit   : 4f8b37b6bf0f6b038e26d1d75ce6407e1a56aa9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

The only overflow hazards I could find in tsquery construction  
are in QTN2QT(), which builds a flat tsquery datum from the  
QTNode tree representation used by tsquery_or, tsquery_rewrite,  
and allied functions.  There are two:  
  
1. It seems theoretically possible for the outputs of cntsize() to  
overflow an int, so I widened them to size_t.  There's no hazard  
certainly in tsquery_or and friends, but tsquery_rewrite could expand  
the query tree by large multiples (by replacing many identical  
subtrees with a large replacement tree), so in a 64-bit machine  
with plenty of available memory it should be possible to build a  
QTNode tree large enough to cause that.  If these counters did  
overflow then we'd under-allocate the output tsquery and have a heap  
overwrite problem.  size_t is sufficient, since it's counting the size  
of a subset of an in-memory data structure.  We also have to fix the  
TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds  
MaxAllocSize.  
  
2. fillQT() neglects to check that the new "distance" value for a  
QI_VAL item fits into the available 20-bit field.  It's quite easy  
to reach this, for example by tsquery_or'ing two near-megabyte-sized  
tsquerys.  However, the result is only a corrupt tsquery that does  
not represent the expected query, so perhaps this doesn't rise to  
the level of a security bug.  Nonetheless it should be fixed.  
  
Note: I followed the practice used in other tsquery code of checking  
each distance value as it's assigned, which means that the last  
operand string could extend past the MAXSTRPOS boundary.  This is a  
bit different from the pattern used for tsvectors, which insist that  
the total data length not exceed MAXSTRPOS and thereby avoid making  
per-item checks.  Perhaps that should be harmonized sometime, but for  
now it's okay for the two types to do this differently as long as  
each one is self-consistent.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-14662  

commit   : f443d0a0af03e9edc95f2c6a8da6229d025d0d4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:29 -0700    

The core of this patch is to prevent array_to_tsvector() from  
generating invalid tsvectors.  It did not check for overly-long  
lexemes (so that WordEntry.len fields could overflow), nor did it  
check that the total "datalen" fits within MAXSTRPOS (so that  
WordEntry.pos fields could overflow, and the number of entries  
in the tsvector could be much more than the normal limit).  
While the field overflows couldn't do anything much worse than  
produce a corrupted tsvector value, a sufficiently large number  
of tsvector entries could cause integer overflows in later  
processing, such as tsvectorout.  
  
Another important fix is to prevent tsvectorrecv() from accepting  
invalid tsvectors.  The main problem there is that it did not  
reject empty-string lexemes.  Hence, even though it did (mostly)  
enforce the MAXSTRPOS limit, it could still produce a result  
with an unreasonable number of tsvector entries, if they were  
primarily empty strings.  
  
Also, fix tsvectorout's calculation of its required output  
buffer size: it was multiplying the string lengths by  
pg_database_encoding_max_length() for no reason.  That contributed  
to the risk of integer overflow there.  With valid tsvector input,  
there's no risk, but there's still no reason to make the output  
buffer several times bigger than needed.  
  
I also tried to make a couple of related routines more robust,  
and spent some effort on improving the comments in ts_type.h.  
Also, standardize on a single spelling of the "string is too long  
for tsvector" message, using %zu instead of an assortment of formats.  
These changes aren't security per se but came out of inspecting the  
code for problems.  
  
Reported-by: Yuhang Wu <yuhang@depthfirst.com> and Zhenpeng Lin  
Reported-by: Zheng Yu <zheng@depthfirst.com>  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-14662  

commit   : 88b3312028950a3b35ca7d7a1e49740069e37b6f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:22:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:22:21 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: c039b261f71688c8c1751e44747bbbdf359cfe41  

commit   : 334582e9d72d4fcefadc8f045da175d6d0e33cf9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2026 12:52:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2026 12:52:47 -0400    

commit   : 7213cbfa02144b3a79a19cfae6964afd8219ecde    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:05 +0900    

The logic for asynchronous Append assumes that pending requests made for  
subplans of an Append are drained during ExecReScanAppend.  To ensure  
that, commit 9e283fc85 modified postgresReScanForeignScan to drain such  
a request if any, but failed to take into account that if such a request  
was made for a subplan that is re-scanned with parameter changes or  
pruned in the next round by runtime pruning, the postgres_fdw callback  
function is called after ExecReScanAppend or never called, respectively.  
This would cause such a request to remain even after ExecReScanAppend,  
leading to incorrect results, an infinite loop, or an assertion failure.  
  
To fix, modify ExecReScanAppend to, for each of the pending requests,  
give the FDW a chance to drain that request using the existing  
ForeignAsyncConfigureWait/ForeignAsyncNotify callback functions.  This  
makes the change made to postgresReScanForeignScan useless, so remove it  
as well.  
  
Back-patch to v14 where asynchronous Append was added.  
  
Reported-by: Alexander Korotkov <aekorotkov@gmail.com>  
Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com>  
Co-authored-by: Gleb Kashkin <g.kashkin@postgrespro.ru>  
Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Alexander Pyhalov <a.pyhalov@postgrespro.ru>  
Reviewed-by: Gleb Kashkin <g.kashkin@postgrespro.ru>  
Discussion: https://postgr.es/m/CAPpHfduMOTnV5Zj2KGJ7zanL_10QvccZHtPUaDfJvBhsh9axnQ%40mail.gmail.com  
Backpatch-through: 14  

commit   : 10e20e59e9fdf4458c23570bc813333acc328e6c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Aug 2026 14:23:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Aug 2026 14:23:39 +0900    

When pgstat_init_entry() fails due to an OOM in the DSA allocation,  
pgstat_get_entry_ref() cleaned up the shared hashtable but forgot to  
remove the local reference that pgstat_get_entry_ref_cached() had  
already inserted into pgStatEntryRefHash.  
  
Missing this cleanup would leave a backend with a stale local cache  
entry whose entry_ref points to a NULL shared_stats.  If  
pgstat_gc_entry_refs() runs with this reference still around, it would  
crash due to a pointer dereference.  
  
The local reference is now removed before removing the shared entry,  
the order being sensitive to pending interrupts.  
  
Oversight in 8191e0c16a03.  
  
Author: Niall Newman <nn@turacolabs.com>  
Discussion: https://postgr.es/m/2FDAA194-9CF3-4FD7-A450-F1A4BEB125F6@turacolabs.com  
Backpatch-through: 15  

commit   : 0de744cd5281021c96ce7366efae2b17321909f8    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 5 Aug 2026 11:40:39 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 5 Aug 2026 11:40:39 +0200    

seq_search_localized() returns the length of the matching prefix in  
*len, but because it internally case-folds the inputs, it gets  
confused on the length. The caller expects to get the length of the  
prefix in the original string, but what it actually returns is the  
length of the prefix after case-folding, which can be different if the  
case-folded characters have different byte-length than the original,  
or with ICU, if the case-folding changes the number of characters  
(e.g. "ß", the German double s).  
  
To fix, once we have determined that we have a match, work harder to  
find the match's length in the original string.  This adds some  
overhead, but the strings are expected to be short.  
  
The function does "case-folding" by converting a string to upper-case,  
then to lower-case, which is a little ugly given that we have  
dedicated functions for case-folding nowadays. But switching to that  
doesn't seem appropriate to backpatch in a security fix, and that's  
not available in older stable versions, anyway.  
  
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Reported-by: Xint Code  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  

commit   : 395700f48f25c00e1bbce01d3a67be2a28fe7c44    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Aug 2026 11:44:11 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Aug 2026 11:44:11 +0200    

heap_force_common() tracked the current position in the caller-supplied  
tid[] using OffsetNumber, which is only 16 bits wide, so when the array  
held more than 65535 entries, the updated index wrapped around and the  
outer loop never reached the exit condition.  A SQL call with a  
sufficiently large TID array would then run until interrupted.  
  
Fix by tracking the tid[] position using int instead of OffsetNumber.  
A regress case based on the report is included.  
  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reported-by: Yuelin Wang <1217816127@qq.com>  
Backpatch-through: 14  
Bug: #19607  
Discussion: https://postgr.es/m/19607-2f256a66481c514b@postgresql.org  

commit   : 785289de01b02e63475bd6f9802bcddb93c1d468    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Aug 2026 09:06:46 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Aug 2026 09:06:46 +0200    

Per commit 8bf6ec3ba3a4, a column can be GENERATED only if it is such in  
the whole inheritance tree.  
  
For this reason, ATPrepDropExpression refuses to be called with ONLY on  
a partitioned table. To detect this, the current implementation checks  
whether recurse is set to false and the rel has direct children.  
  
Recursion is implemented with ATSimpleRecursion, which calls ATPrepCmd  
with recurse = false for every node in the tree. Inner nodes (for  
example a partition which itself has subpartitions) then fail the check,  
accidentally preventing the command from working on inheritance trees of  
depth > 2.  
  
This commit fixes it by also checking that we're at the top level of the  
recursive calls using the recursing parameter, which is always true when  
called through ATSimpleRecursion, always false when invoked on the root  
rel.  
  
Also, remove a comment claiming that DROP EXPRESSION could be  
implemented with some effort.  It cannot, as the commit message for  
8bf6ec3ba3a4 explains.  
  
Author: Alberto Piai <alberto.piai@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/DHMT78XOD8BK.341V3H87KZ7NO@gmail.com  

commit   : d782c97e14a97b215d439a4578732b84b67da43d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:01:31 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:01:31 +1200    

Similar to what 1f7cb5c30 did for the INT types, protect against  
overflow when dividing the lowest possible money value by -1.  This  
cannot be represented on a two's complement machine.  
  
Without this check, the result depends on the machine, and in the worst  
case, could result in a crash.  With the fix installed, this will now  
result in:  
  
ERROR:  money out of range  
  
Bug: #19585  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reported-by: Michael Malis <malis@pgrust.com>  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com>  
Discussion: https://postgr.es/m/19586-bb603bf5ad9934dd%40postgresql.org  
Discussion: https://postgr.es/m/CAB8bMisnXJVXte6s3kUOpuuAY9%3D9kehG6MMX-%2BTQoFsSGan22Q%40mail.gmail.com  
Backpatch-through: 14  

commit   : e7e04e1d3c54466194ee6d1687fcbd4254f65ab5    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 3 Aug 2026 11:34:58 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 3 Aug 2026 11:34:58 -0700    

Logging connection information, even at DEBUG1, creates unnecessary  
risks. Remove the entire log message because it had no other useful  
content.  
  
Addresses finding 14 in report from linked discussion.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260710195902.4f.noahmisch@microsoft.com  
Backpatch-through: 14  

commit   : 0252281049a6e06f6afb5b827f1ac6a45a7637c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2026 16:49:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2026 16:49:18 -0400    

In the not-too-likely scenario where we successfully created a hash  
table entry for a TS dictionary, but then failed to make a small  
memory context for it, we left the hash entry in existence but with  
a garbage value for dictCtx.  This confused the code the next time  
through, leading to a crash.  Rearrange things so that we leave  
the hash entry in a well-defined state with dictCtx == NULL, and  
then the next try knows it still needs to make a memory context.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com  
Backpatch-through: 14  

commit   : 0fb88979bf43859c65cdf6731bfab31532bd7161    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2026 13:22:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2026 13:22:39 -0400    

Allocate CompoundAffix with room for its terminator, initialize the  
old-format flag buffer before NIAddAffix(), and reject incomplete or  
missing Hunspell AF aliases.  None of these errors would be likely to  
trigger on real dictionary files, accounting for the lack of previous  
reports; but they're certainly bugs.  
  
Bug: #19595  
Reported-by: Michael Malis <michaelmalis2@gmail.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19595-7dc18b4e212c4757@postgresql.org  
Backpatch-through: 14  

commit   : af7be5672bb8d6cb216c40edc3de1f060f0eb579    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2026 11:26:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2026 11:26:30 -0400    

Alberta (America/Edmonton) moved to permanent UTC-06 on  
2026-06-18, which will affect their clocks beginning on 2026-11-01.  
For lack of any clarity on the point, assume their TZ abbreviation  
will be CST from that time forward.  
  
Morocco (Africa/Casablanca) will move to permanent UTC+00,  
without daylight saving time transitions, on 2026-09-20.  
  
Backpatch-through: 14  

commit   : 5190732c91f0327a3a78697d715f1ea1f0e14a2f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:39:01 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:39:01 +1200    

Partition pruning for RANGE-partitioned tables could mistakenly prune  
the DEFAULT partition in some cases when it was not valid to do so,  
which could lead to rows missing from query results.  
  
The only known cases where this could happen is when combining pruning  
steps from an IS NOT NULL clause with other steps that matched to the  
DEFAULT partition.  This could occur due to RANGE partitioned tables  
having two distinct internal representations for marking if the DEFAULT  
partition should be scanned.  The IS NOT NULL steps would mark the  
"scan_default" boolean, but other steps created for different purposes  
could mark a bound_offset Bitmapset, which would ultimately translate into  
also scanning the default partition.  This could all fail after multiple  
steps were combined with a combine intersect operator, as that will  
intersect the bound_offset bits and only set scan_default if all pruning  
steps have that flag set.  When both input steps to the intersect operator  
had different representations of whether to scan the DEFAULT partition,  
the resulting intersect step result would contain neither representation.  
  
Here, we fix this by having the IS NOT NULL pruning result mark the  
bound_offsets so that it uses both representations to mark that the  
DEFAULT partition must be scanned.  
  
Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com>  
Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com  
Backpatch-through: 14  

commit   : 51cae2563a71bf47516947d568bad593261d2338    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 29 Jul 2026 21:51:46 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 29 Jul 2026 21:51:46 +0200    

refint has been removed from the spi contrib module in v20.  Add a note  
to the documentation of the still-supported back branches so that users  
are aware the module is going away.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reported-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAJTYsWUHq8Ohc6-N-xamOPYz-q3qUYMtwQX-1=Zi=5N1Q_GSEQ@mail.gmail.com  
Backpatch-through: 14  

commit   : 8f64cc83f9ddde828e99c13301c10d573f399baa    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 29 Jul 2026 17:15:45 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 29 Jul 2026 17:15:45 +0200    

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.  This happened because archive  
recovery processes whole segment files, so after replaying a segment the  
cascade's next read position lands at the start of the following  
segment, which is ahead of the upstream's flush position reported by  
GetStandbyFlushRecPtr() (still inside the just-replayed segment).  
  
Fix by having the walreceiver check the upstream's current WAL flush  
position via IDENTIFY_SYSTEM before issuing START_REPLICATION.  
IDENTIFY_SYSTEM already returns this position (as xlogpos), but  
walrcv_identify_system() previously discarded it; now we have a use for  
it.  If the requested start point exceeds the upstream's flush position  
on the same timeline, the walreceiver waits for  
wal_retrieve_retry_interval and retries.  
  
The wait is limited to gaps of at most one WAL segment, which is the  
expected case from the segment-granularity of archive recovery.  Larger  
gaps indicate the upstream is genuinely behind, so START_REPLICATION is  
allowed to proceed (and fail) normally, letting the startup process fall  
back to other WAL sources.  The first wait is logged at LOG level;  
subsequent waits are demoted to DEBUG1 to avoid log noise.  The  
walreceiver honors wal_receiver_timeout during the wait, so it will exit  
if the upstream doesn't catch up in time.  
  
To preserve ABI compatibility on back branches, the flush position from  
IDENTIFY_SYSTEM is communicated via a new global variable  
(WalRcvIdentifySystemLsn) rather than changing the signature of  
walrcv_identify_system().  
  
The bug was introduced in Postgres 9.3 by commit abfd192b1b5b, which  
added a flush-position check in StartReplication() that rejects requests  
ahead of the upstream server's WAL flush position.  
  
Author: Marco Nenciarini <marco.nenciarini@enterprisedb.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CA+nrD2cTuTkkX5WXVZengTYYZbAO6zV8K+Tri-R0fbLFuoyMBA@mail.gmail.com  

commit   : 53470ffba99a3590469a118b8cc82d7ab080e071    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2026 16:08:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2026 16:08:46 -0400    

find_nonnullable_rels and find_nonnullable_vars mistakenly treated a  
ScalarArrayOpExpr that could return FALSE as strict, but that's okay  
only at top level of a qual expression; further down, we've got to  
insist on a guaranteed-NULL result.  The result was that we could draw  
mistaken conclusions about whether outer joins can be simplified, if  
the decision hinged on a non-top-level ScalarArrayOpExpr with a  
potentially-empty array argument.  
  
I believe this error dates to commit 72a070a36, which taught  
find_nonnullable_rels to descend into non-top-level parts of qual  
expressions.  is_strict_saop (added earlier by 72153c058) already had  
enough intelligence to do the case correctly, but it wasn't passed the  
proper flag, ie "top_level" needs to be passed for "falseOK".  
e006a24ad copied that mistake into find_nonnullable_vars.  
  
Later, over-eager refactoring in commit 2f153ddfd broke  
contain_nonstrict_functions' handling of ScalarArrayOpExpr by treating  
it as though it were no different from an OpExpr.  It is, because  
we must also prove the array is non-empty before concluding that the  
expression is strict.  This could result in misclassifying an  
expression as strict when it is not, leading to assorted planning  
mistakes such as inlining a SQL function that shouldn't be inlined.  
We can almost fix this by just re-adding the previous handling of  
ScalarArrayOpExpr in that function, but doing only that would lead to  
also calling check_functions_in_node() and thus redundantly checking  
the operator's strictness.  Avoid that by turning the if-series into  
an else-if chain, as it arguably should have been all along.  
  
The reason these errors have escaped detection for decades is that  
they are exposed only in arcane corner cases.  ScalarArrayOpExpr with  
an empty array isn't typical usage, and even when that's possible  
several other conditions apply before the planner can reach a mistaken  
conclusion.  While it's possible to build test cases demonstrating  
these mistakes, I (tgl) judged them too indirect and special-purpose  
to justify consuming regression test cycles forevermore.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAJTYsWV3vqRJmST-gv1NsXEef-zOnjVJpYS910aBaiuMij4nFg@mail.gmail.com  
Discussion: https://postgr.es/m/CAJTYsWWcLGmz0f8_QPP_Liq-fc7-geiFSCdqoq3XGeRHPPsWeA@mail.gmail.com  
Backpatch-through: 14  

commit   : 0dbfb8520f609f93f4fd05810be6f5bec601911f    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:47 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:47 -0700    

A two-phase transaction that is assigned an XID but produces no change  
to be decoded -- for example, one that only acquires row locks via  
SELECT ... FOR SHARE -- has no base snapshot in the reorder  
buffer. ReorderBufferReplay() already skips such a transaction at  
PREPARE time and never invokes the begin_prepare/change/prepare  
callbacks for it, but ReorderBufferFinishPrepared() still called the  
commit_prepared (or rollback_prepared) callback. As a result a  
spurious COMMIT/ROLLBACK PREPARED was sent to the output plugin with  
no preceding PREPARE. For the built-in subscriber this breaks  
replication (the apply worker fails to find the prepared transaction),  
and test_decoding could even crash.  
  
Fix this by detecting an empty transaction (base_snapshot == NULL) in  
ReorderBufferFinishPrepared() and cleaning it up without invoking the  
commit/rollback prepared callbacks, mirroring the existing empty  
transaction handling in ReorderBufferReplay().  
  
On v18 and newer versions, commit 072ee847ad4 changed  
ReorderBufferPrepare() to send the prepare whenever it had not already  
been sent, which also fires for empty transactions and emits a  
spurious PREPARE. On those branches ReorderBufferPrepare() is  
therefore additionally guarded with base_snapshot != NULL. This guard  
and the Assert(!rbtxn_sent_prepare()) added in  
ReorderBufferFinishPrepared(), are not necessary on v17 and older  
versions: there ReorderBufferPrepare() only sends a prepare for  
concurrently-aborted transactions (which never applies to an empty  
transaction) and the RBTXN_SENT_PREPARE flag does not exist.  
  
Back-patch to v14, where decoding of two-phase transactions was  
introduced.  
  
Bug: #19556  
Reported-by: Alexander Kozhemyakin <a.kozhemyakin@postgrespro.ru>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/19556-daa6d7ea65054d48@postgresql.org  
Backpatch-through: 14  

commit   : 7123abab776859257029bc04f89aab777df5e1d7    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 28 Jul 2026 10:50:13 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 28 Jul 2026 10:50:13 +0200    

Commit fd83c83d094 turned the recursive posting-tree cleanup in  
ginVacuumPostingTreeLeaves() into an iterative sweep that follows the  
tree's leaf pages via their rightlinks.  The recursive version called  
vacuum_delay_point() while processing the tree, but that call was removed  
and never re-added to the new loop.  As that commit only set out to fix a  
deadlock, the removal appears to have been unintentional.  
  
Consequently the leaf-page sweep of a single posting tree runs with no  
vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS().  A posting  
tree stores all the TIDs for one indexed key, so for a frequently  
occurring key it can span a large number of leaf pages.  While such a  
tree is being vacuumed the operation ignores vacuum_cost_delay and does  
not respond to query cancellation or statement_timeout; an autovacuum  
worker likewise cannot be interrupted mid-sweep when another backend  
requests a conflicting lock.  
  
Restore the call, placed after the current page has been unlocked and  
released so that no buffer content lock is held across a potential delay  
(cf. 21c27af65fb).  The sibling loops in ginbulkdelete() and  
ginvacuumcleanup() already call vacuum_delay_point() once per page.  
  
Author: Paul Kim <mok03127@gmail.com>  
Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: solai v <solai.cdac@gmail.com>  
Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com  
Backpatch-through: 14  

commit   : 5b3712e31565ab9be18b7f8e36cee61ba6fc951e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:19 +0900    

index_create_copy is used to create copy definitions of existing indexes.  
Currently, it passes 0 as constr_flags to index_create(), which results  
in the copied index to always be created as immediate (indimmediate set  
to true).  For deferrable unique constraints, it means that the  
transient index used during the phase 2 of REINDEX CONCURRENTLY forces  
immediate constraint checks on concurrent inserts, which can cause  
unexpected constraint violations based on the definition of the parent  
table, inconsistently set in the copied index.  
  
To fix this without violating the contract of constr_flags (which should  
only be used when creating constraints) and without relaxing the strict  
assertion in index_create(), this introduces a new index creation flag:  
INDEX_CREATE_DEFERRABLE.  If set, a copied index's indimmediate is set  
to false, meaning that unique constraints are not enforced immediately  
on insertion, but at transaction commit time.  
  
An isolation test for REINDEX CONCURRENTLY is added, based on an  
injection point waiting after phase 1 of the operation, where an index  
copy has been built and is able to accept DMLs for its validation in  
phase 2.  The test is tentatively backpatched down to v17.  
INJECTION_POINT() is outside a transaction context, which should be fine  
on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and  
older branches due to the wait facility depending on condition variables  
and a DSM setup, but let's see what the buildfarm tells.  
  
Author: Nitin Motiani <nitinmotiani@google.com>  
Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com  
Backpatch-through: 14  

commit   : eba7f1dc01fc635ce7905e2b094354831b7d2a99    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 6 Jul 2026 00:00:00 +0000    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 6 Jul 2026 00:00:00 +0000    

Documentation and any code paths related to VS are updated to keep the  
whole consistent. Similar to what was done for VS 2017, 2019 and 2022.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch: 14 through 16  
Discussion: https://postgr.es/m/CAD5tBc+nFmaqqCaxDdQUMtOmtTb3nrvXn2TiVjLQyy0FV1BcUQ@mail.gmail.com  

commit   : 5d18105cadb0ef5b937fe388eb4b109e4396b16f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:26 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:26 -0400    

Commit f9b7fc65 fixed a race when predicate-locking completely empty  
btrees: without a buffer lock held, a matching key could be inserted  
between _bt_search and the PredicateLockRelation call, so the scan would  
miss concurrently inserted tuples while the writer wouldn't see the  
reader's predicate lock.  That commit only fixed _bt_first's _bt_search  
path, though.  Scans without useful insertion scan keys return early  
from _bt_first via _bt_endpoint, which still didn't recheck if the  
relation was empty.  
  
To fix, add handling to _bt_endpoint that is analogous to the handling  
added to _bt_search by commit f9b7fc65.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-WzkNoTn3yXY0iGkSuavJ+sL8EROf+kitW+_2v2tJVWuKmA@mail.gmail.com  
Backpatch-through: 14  

commit   : e6e8a3078b094f209f6e40822c1655ebd34429f5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 25 Jul 2026 19:10:49 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 25 Jul 2026 19:10:49 +0900    

pg_database_size() allows access to users who have either CONNECT  
privilege on the target database or privileges of the pg_read_all_stats  
role. However, previously, psql's \l+ checked only for CONNECT,  
so users with privileges of pg_read_all_stats still saw "No Access" for  
databases they could not connect to.  
  
Fix this by making \l+ also check  
pg_has_role('pg_read_all_stats', 'USAGE'), matching  
pg_database_size()'s permission rules.  
  
For back branches, emit the pg_read_all_stats check only when  
connected to PostgreSQL 10 or later, since earlier releases do not have  
that predefined role.  
  
Backpatch to all supported versions.  
  
Author: Christoph Berg <myon@debian.org>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/amCo6qRmnfPVk4-V@msg.df7cb.de  
Backpatch-through: 14  

commit   : 0e69b44dc2c1d31b41d38c6c5c0ed5e29809a19b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 20 Jul 2026 13:36:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 20 Jul 2026 13:36:39 -0400    

It's always been the case that granting these privileges to users that  
you don't fully trust was a bad idea, but it hasn't always been  
obvious to people reading the documentation that this is the case.  
To prevent confusion, and also repeated reports to pgsql-security,  
mention it explicitly.  
  
Discussion: http://postgr.es/m/CA+TgmobrjCHBuWHrvX3=2vndUCO2thUOdevrCcMDFW86cqCYvw@mail.gmail.com  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Backpatch-through: 14  

commit   : 1261414252fbc7172711afc386cca8d2154b9db6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:52:58 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:52:58 -0400    

An index-only scan filled its result slot from the HeapTuple an index AM  
returns in scan->xs_hitup by deforming it with the virtual slot's own  
tuple descriptor (during GiST and SP-GiST index-only scans).  But index  
AMs form that heap tuple using their own descriptor, scan->xs_hitupdesc.  
The AM's descriptor may disagree with the IoS virtual slot's descriptor  
about each column's precise alignment, leading to "can't happen" errors  
in certain rare edge cases.  Hard crashes were possible but much less  
likely.  
  
To fix, deform the tuple with the descriptor it was formed with.  This  
is simpler, and makes xs_hitup handling (used by GiST and SP-GiST)  
uniform with the nearby existing xs_itup handling (used by nbtree).  
  
In practice this issue was very unlikely to be hit (it was found during  
testing of a patch that will change the table AM API used during index  
scans).  The only currently affected core opclass is GiST's range_ops.  
It was only possible for the datum to be accessed at an incorrectly  
aligned offset when reading the second or subsequent column from a  
multicolumn GiST index.  This couldn't happen in the common case where  
the datum used an unaligned short varlena header.  Moreover, an earlier  
column had to leave the range datum at an offset where the two  
alignments actually disagree (e.g., an odd-length varlena datum).  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/CAH2-WzkGXa2SKnebdW29RT1hCcQBo_p03v3iqif2u9bjzLB-aQ@mail.gmail.com  
Backpatch-through: 14  

commit   : ca22d7bab501016aae3604b15094b4e0950ea30d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:13:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:13:06 +0530    

The previous text claimed that once the slot is disassociated with  
ALTER SUBSCRIPTION ... SET (slot_name = NONE), DROP SUBSCRIPTION "will no  
longer attempt any actions on a remote host".  That is inaccurate:  
DROP SUBSCRIPTION may still connect to the publisher to drop  
internally-created table synchronization slots when some table  
synchronization is left unfinished.  Reword to describe this, and note  
that if the publisher is unreachable those slots (and the main slot, if  
it still exists) must be dropped manually to avoid indefinitely reserving  
WAL.  
  
Reported-by: Jeff Davis <pgsql@j-davis.com>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAA4eK1+tyYSpPxMBy1974kjivuGeR7YY=yopwRGrK3+vCTysdg@mail.gmail.com  
Discussion: https://postgr.es/m/D908370F-2695-4231-851D-17179A6A6F2A@gmail.com  

commit   : aaad61f5f2700252bf9d51ae79ebbb2fdec8c0ac    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:26 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:26 -0400    

Commit c7aeb775 rewrote the HOT-chain offset sanity checks in three  
places, but in heap_get_root_tuples it accidentally tested offnum -- the  
outer loop variable, which is already bounded by the loop condition --  
instead of nextoffnum, the offset actually passed to PageGetItemId.  The  
pre-c7aeb775 check tested nextoffnum.  
  
With the check ineffective, a stale t_ctid could make PageGetItemId read  
past the end of the line pointer array (which is data corruption that we  
expect to be able to catch here).  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Konstantin Knizhnik <knizhnik@garret.ru>  
Discussion: https://postgr.es/m/87c7d8a4-3a82-4334-bee6-e8c2ad3f3293@garret.ru  
Backpatch-through: 15  

commit   : 0a03b598e64f810bfc2c46b0097860ed380a923e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:38:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:38:34 +0900    

Previously, libpqrcv_create_slot() checked only that  
CREATE_REPLICATION_SLOT returned PGRES_TUPLES_OK before reading  
values from the first row. If the server unexpectedly returned an  
invalid result, such as zero rows, PQgetvalue() could return NULL,  
leading to a crash while parsing the LSN.  
  
Other replication commands, such as IDENTIFY_SYSTEM, already validate  
the response shape before accessing result values, but  
CREATE_REPLICATION_SLOT did not.  
  
Fix this by verifying that CREATE_REPLICATION_SLOT response contains  
exactly one row with four fields, and report a protocol violation otherwise.  
  
Backpatch to all supported versions.  
  
Bug: #19547  
Reported-by: Yuelin Wang <1217816127@qq.com>  
Author: Kenny Chen <kennychen851228@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19547-f7986f668f71e788@postgresql.org  
Discussion: https://postgr.es/m/CAPXstDtW2iqe+DJAOTQTX+rRziJp2UhZSo1+HRj1COAtbu+nKw@mail.gmail.com  
Backpatch-through: 14  

commit   : 840f1987426fdc85b40e46248d79ef4c75ba37f4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:35:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:35:36 +0900    

The documentation for log_parameter_max_length said it affects messages  
generated by log_duration. However, log_duration alone does not log bind  
parameter values, so this is misleading.  
  
This commit updates the documentation to reference log_min_duration_statement,  
which can log bind parameters, to better reflect actual behavior.  
  
Backpatch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Surya Poondla <suryapoondla4@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGnCVMVz8-LU9F8Sh57bkQX3jMZzx7age7M0LFEz5=Fog@mail.gmail.com  
Backpatch-through: 14  

commit   : 79abbc90a86e930a9ad69c918f2ce1c25549290e    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 15 Jul 2026 21:40:09 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 15 Jul 2026 21:40:09 +0200    

Commit 6f164e6d17616 accidentally mistyped --client as --clients in  
the error message.  Backpatch down to v15 where the it was introduced.  
  
Author: Semih Doğan <semih702do@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CALOtZ7tuWisV=v0cUY_q6PLHJ-fOiQ7ZN476JwmM0PyV0t5i7Q@mail.gmail.com  
Backpatch-through: 15  

commit   : 38d24d705ffda0d22628737cacc13034948594c0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:45 +0900    

equalPolicy() is used in the relation cache to check if two policy  
definitions are equivalent, but missed to check for polpermissive.  
  
ALTER POLICY cannot switch a policy to be PERMISSIVE or RESTRICTIVE, so  
this would need a dropped and then re-created policy, which would  
trigger a relcache invalidation.  Anyway, there is no harm in being  
consistent in the check, and if one decides to add an ALTER POLICY to  
switch PERMISSIVE or RESTRICTIVE, we would be silently in trouble.  
  
Author: Andreas Lind <andreaslindpetersen@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/CAMxA3rv1CS6R7JR5ojz-3CmCEnZEFrqu+XXTnGbLRWrjJRH7sA@mail.gmail.com  
Backpatch-through: 14  

commit   : 494f4f409c0d5866101dc232454e1187d50a84e0    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 11 Jul 2026 15:14:50 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 11 Jul 2026 15:14:50 +0200    

The pg_attribute_always_inline macro name is so long it forces pgindent  
to format the code in strange ways. Which may incentivize patch authors  
to either structure the code in strange ways (e.g. reorder prototypes),  
use shorter names, etc. Neither is very desirable for code readability.  
  
This shortens the name by removing the _attribute_ part. It also makes  
it more consistent with pg_noinline, which does not have the _attribute_  
part either.  
  
Backpatched to all supported branches, to prevent conflicts when  
backpatching other fixes. The backbranches however keep both the old and  
new macro name, so that existing code keeps working.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/bqqdehahpoa36igpictuqyn2s2mexk3t3ehidh2ffd2slb35e5@rzgksuiszgbg  
Backpatch-through: 14  

commit   : 5ba13f8c0488feefac4115e4efd22b522c983b21    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:27 +0300    

Check explicitly for pqsecure_read() returning an error. It shouldn't  
fail, and we would've caught it in the check for a short read, but  
better to be explicit so that the error message is more informative.  
We also shouldn't update 'inEnd' when the read fails, although that  
too is just pro forma as we will bail out and close the connection on  
error.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://www.postgresql.org/message-id/34844e8c-267c-4daf-b1e0-f26059a4a7d3@eisentraut.org  
Backpatch-through: 14  

commit   : 21a6c69eaadeca5f2bdd46803f2178cc44c4786e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:24 +0300    

When compiling against OpenSSL, the <limits.h> header is indirectly  
included via openssl/ossl_typ.h from openssl/conf.h, but the LibreSSL  
version of ossl_typ.h does not include <limits.h> which cause compiler  
failure due to missing symbol (since ffd080d94fe).  Fix by explicitly  
including <limits.h>.  
  
Author: Daniel Gustafsson <dgustafsson@postgresql.org>  
Discussion: https://www.postgresql.org/message-id/6A9E7815-BD5A-4C31-A515-48159823406B@yesql.se  
Backpatch-through: 14  

commit   : 8691659595b5d33eec0b7a539edd42ab827fda49    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 12:45:20 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 12:45:20 +0900    

Commit aa606b9316a disallowed generated columns in COPY FROM WHERE  
expressions, and commit 21c69dc73f9 disallowed system columns.  
However, the COPY reference page still mentions only the restriction  
on subqueries.  
  
Update the documentation to also list generated columns and system  
columns as unsupported in COPY FROM WHERE expressions.  
  
Backpatch the generated-column documentation change to all supported  
versions. Backpatch the system-column documentation change to v19,  
where that restriction was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwEgxErc54yVOAVWCsr1O=8pgw4oKRPuEQ9mfhkoYGR_XA@mail.gmail.com  
Backpatch-through: 14  

commit   : f974687c918c57ae26913985c9a91372b3046727    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 09:04:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 09:04:31 +0900    

Commit dcb00495236 accidentally changed the final expanded query's  
condition to > 2 while rewriting the example into SQL operator notation.  
  
The original query and the preceding rewritten forms all use >= 2,  
and view expansion should preserve that qualification. This commit  
changes the final condition from > 2 to >= 2.  
  
Backpatch to all supported versions.  
  
Reported-by: Yaroslav Saburov <y.saburov@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/178248467618.108999.9966122434342474006@wrigleys.postgresql.org  
Backpatch-through: 14  

commit   : 05908afcd42b92cf28957a773e0c63d5d44627f2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:37 +0300    

The previous commit strengthened a workaround for a hang when large  
messages are split across TLS records/GSS tokens. Because that  
workaround is implemented in libpq internals, it can only help us when  
libpq itself is polling on the socket. In nonblocking situations,  
where the client above libpq is expected to poll, the same bugs can  
show up.  
  
As a contrived example, consider a large protocol-2.0 error coming  
back from a server during PQconnectPoll(), split in an odd way across  
two records:  
  
    -- TLS record (8192-byte payload) --  
    EEEE[...repeated a total of 8192 times]  
    -- TLS record (8193-byte payload) --  
    EEEE[...repeated a total of 8192 times]\0  
  
The first record will fill the first half of the libpq receive buffer,  
which is 16k long by default. The second record completely fills the  
last half with its first 8192 bytes, leaving the terminating NULL in  
the OpenSSL buffer. Since we still haven't seen the terminator at our  
level, PQconnectPoll() will return PGRES_POLLING_READING, expecting to  
come back when the server has sent "the rest" of the data.  But there  
is nothing left to read from the socket; OpenSSL had to pull all of  
the data in the 8193-byte record off of the wire to decrypt it.  
  
A real server would probably not split up the records this way, nor  
keep the connection open after sending a fatal connection error. But  
servers that regularly use larger TLS records can get the libpq  
receive buffer into the same state if DataRows are big enough, as  
reported on the list. While the PostgreSQL server doesn't use larger  
TLS records like that, other non-PostgreSQL servers that implement the  
wire protocol are known to do that, as well as proxies that sit  
between the server and the client  
  
This is a layering violation. libpq makes decisions based on data in  
the application buffer, above the transport buffer (whether SSL or  
GSS), but clients are polling the socket below the transport buffer.  
One way to fix this in a backportable way, without changing APIs too  
much, is to ensure data never stays in the transport buffer. Then  
pqReadData's postconditions will look similar for both raw sockets and  
SSL/GSS: any available data is either in the application buffer, or  
still on the socket.  
  
Building on the prior commit, make pqReadData() to drain all pending  
data from the transport layer into conn->inBuffer, expanding the  
buffer as necessary. This is not particularly efficient from an  
architectural perspective (the pqsecure_read() implementations take  
care to fit their packets into the current buffer, and that effort is  
now completely discarded), but it's hopefully easier to reason about  
than a full rewrite would be for the back branches.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Reviewed-by: solai v <solai.cdac@gmail.com>  
Reported-by: Lars Kanis <lars@greiz-reinsdorf.de>  
Discussion: https://postgr.es/m/2039ac58-d3e0-434b-ac1a-2a987f3b4cb1%40greiz-reinsdorf.de  
Backpatch-through: 14  

commit   : 4ecba7fa3a637badde33480284ac57f92d476f62    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:34 +0300    

An extra check for pending bytes in the SSL layer has been part of  
pqReadReady() for a very long time (79ff2e96d). But when GSS transport  
encryption was added, it didn't receive the same treatment. (As  
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally  
hard to reproduce reliably.")  
  
Without that check, it's possible to hit a hang in gssencmode, if the  
server splits a large libpq message such that the final message in a  
streamed response is part of the same wrapped token as the split  
message:  
  
    DataRowDataRowDataRowDataRowDataRowData  
    -- token boundary --  
    RowDataRowCommandCompleteReadyForQuery  
  
If the split message takes up enough memory to nearly fill libpq's  
receive buffer, libpq may return from pqReadData() before the later  
messages are pulled out of the PqGSSRecvBuffer. Without additional  
socket activity from the server, pqReadReady() (via pqSocketCheck())  
will never again return true, hanging the connection.  
  
Pull the pending-bytes check into the pqsecure API layer, where both  
SSL and GSS now implement it.  
  
Note that this does not fix the root problem! Third party clients of  
libpq have no way to call pqsecure_read_is_pending() in their own  
polling. This just brings the GSS implementation up to par with the  
existing SSL workaround; a broader fix is left to a subsequent commit.  
  
In preparation for the broader fix, this patch already changes the  
*_read_pending() functions to return the number of bytes in the buffer  
rather than just a boolean. The current callers don't need that, but  
the subsequent fix will.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com  
Backpatch-through: 14  

commit   : 4c0d53791f13852be41f25cc80666b8ad4454eb0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:11:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:11:28 +0300    

ParallelBackupStart() stored _beginthreadex()'s return value as the  
worker's thread handle without checking it.  On failure that value is 0,  
which would later reach WaitForMultipleObjects() as a null handle, caught  
only by an Assert.  The fork() path already calls pg_fatal() when it  
fails; do the same for _beginthreadex(), as pgbench does.  
  
Author: Bryan Green <dbryan.green@gmail.com>  
Discussion: https://www.postgresql.org/message-id/8c712d76-ecf7-4749-a6d8-dddc01f298ec@gmail.com  
Backpatch-through: 14  

commit   : 842e34efa7cf851b28c0234fbad857cd8c34fdd8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Jul 2026 00:00:34 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Jul 2026 00:00:34 +1200    

9d9c02ccd added code to allow the executor to stop early when processing  
WindowAgg nodes where a monotonic window function starts producing  
values that result in a pushed-down qual no longer matching, and will  
never match again due to the window function's monotonic properties.  
  
That commit requires a SupportRequestWFuncMonotonic to exist on the  
window function and for it to detect when the function is monotonic.  For  
COUNT(ANY) and COUNT(*), the support function failed to consider some  
cases where the WindowClause used EXCLUDE to exclude certain rows from  
being aggregated.  Some WindowClause definitions mean we aggregate rows  
that come after the current row, and when processing those rows later,  
if we EXCLUDE certain rows, the monotonic property can be broken.  
Wrongly treating the COUNT(*) or COUNT(ANY) aggregate as monotonic could  
lead to rows being filtered that should not be filtered from the result  
set.  
  
Another issue was that the support function for the COUNT aggregate  
mistakenly thought that a WindowClause without an ORDER BY meant that  
the results would be both monotonically increasing and decreasing, but  
that's only true when in RANGE mode, where all rows are peers.  
  
It is possible to support various cases that do have an EXCLUDE clause,  
but getting the logic correct for the exact set of cases that are valid  
is quite complex and would likely better be left for a future project.  
  
Here, we mostly disable run condition pushdown when there is an EXCLUDE  
clause unless the clause is for EXCLUDE CURRENT ROW, uses COUNT(*)  
(rather than COUNT(ANY)), and the window aggregate has no FILTER clause.  
  
Bug: #19533  
Reported-by: Qifan Liu <imchifan@163.com>  
Author: Chengpeng Yan <chengpeng_yan@outlook.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Discussion: https://postgr.es/m/19533-413a1014e5d0e766@postgresql.org  
Backpatch-through: 15  

commit   : d39b9eed07e3ad72f3106dd76c348c9b3b0cff95    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jul 2026 12:12:41 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jul 2026 12:12:41 -0400    

Commit f3b0897a1213f46b4d3a99a7f8ef3a4b32e03572 fixed some  
related problems, but overlooked this one. That commit first  
appeared in PostgreSQL 11, so back-patch to all supported branches.  
  
Backpatch-through: 14  
Discussion: http://postgr.es/m/CA+TgmobsvQw3F+KRYT83=N3teh8D2t-oPR=U06QDZJE3viCJRg@mail.gmail.com  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  

commit   : a8fb98b7bfe5af3be68767c1ab7a988f2e17fd32    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2026 09:46:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2026 09:46:15 +0900    

Commit e7564ee8cdc, which fixed base backup progress reporting on  
backup failure, removed the external function basebackup_progress_done()  
because it was no longer used in core. When that change was backpatched  
to v15, it introduced an ABI break, which was reported by buildfarm  
member crake.  
  
This commit restores basebackup_progress_done() to preserve ABI  
compatibility, even though it is no longer used in core, rather than  
updating the .abi-compliance-history file. Because external backup  
tools may still call this function.  
  
Per buildfarm member crake.  
  
Reported-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://postgr.es/m/CAD5tBcJ+ktrEp=PT8Gq-f=8mA2cDtZMB-hDMV4mMJ+9V46qBeQ@mail.gmail.com  
Backpatch-through: 15-18  

commit   : eada45dd846d4324c33e3ae357fb4c8fbf01bc6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jul 2026 11:34:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jul 2026 11:34:26 -0400    

ON SELECT rules must be named "_RETURN", while other kinds of rules  
must not be; this ancient restriction is depended on by various client  
code.  We successfully enforced this convention in most places, but  
ALTER RULE allowed renaming a non-SELECT rule to "_RETURN".  Notably,  
that would break dump/restore, since the eventual CREATE RULE command  
would reject the name.  
  
While at it, remove DefineQueryRewrite's hack to substitute "_RETURN"  
for the convention that was used before 7.3.  We dropped other  
server-side code that supported restoring pre-7.3 dumps some time ago  
(notably in e58a59975 and nearby commits), but this bit was missed.  
  
Bug: #19543  
Reported-by: Adam Pickering <adamkpickering@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19543-461228e77f3b32fc@postgresql.org  
Backpatch-through: 14  

commit   : 8f2a1b3d3511aa07c19c0066d75c06e81496f7c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2026 13:50:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2026 13:50:14 -0400    

gbt_var_consistent() handled the <> (BtreeGistNotEqual) strategy without  
distinguishing leaf from internal pages, unlike every other strategy.  
In particular, it tried to apply the datatype-specific f_eq method,  
which is completely wrong since internal keys might not have the same  
representation as leaf keys.  This led to OOB reads and potentially  
crashes, and most likely to wrong query results as well.  
  
On leaf pages we can apply the inverse of what the Equal strategy does.  
On internal pages, use a correct implementation of what the previous  
code intended: we can descend if the query value equals both bounds,  
*so long as the bounds aren't truncated*.  With truncated bounds we  
don't quite know the range of what's below, so we must always descend.  
  
Adjust the code in gbt_num_consistent() to look similar, too.  This  
fixes a performance buglet in that there's no need to do two comparisons  
on a leaf entry, but the main point is just to keep code consistency.  
  
Reported-by: 王跃林 <violin0613@tju.edu.cn>  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/AH*AvQCYKhQGVvPWi1GiU4oY.8.1781609375063.Hmail.3020001251@tju.edu.cn  
Backpatch-through: 14  

commit   : c25737c8966329bbc1909de97f166f83e696eff5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 13:46:35 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 13:46:35 +0900    

Commit fb421231daa extended \df to include procedures, but its tab  
completion continued not to show procedures.  
  
Update \df tab completion to include procedures as well.  
  
Backpatch to all supported versions.  
  
Author: Erik Wienhold <ewie@ewie.name>  
Reviewed-by: Surya Poondla <suryapoondla4@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/10fbfdfe-80f6-4ef9-b8b3-f7be0eb53a50@ewie.name  
Backpatch-through: 14  

commit   : 814df787f68a2a75c7c7355c7fbaf135536e481a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 11:22:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 11:22:15 +0900    

Previously, MultiXactId wraparound hints suggested dropping stale  
replication slots. While that advice is appropriate for transaction ID  
wraparound, where replication slots can hold back XID horizons,  
it was misleading for MultiXactId wraparound. Following it could lead  
users to drop replication slots unnecessarily without helping resolve  
the MultiXactId wraparound condition.  
  
MultiXact cleanup is not directly delayed by replication slots.  
Instead, it depends on whether old MultiXactIds can still be seen  
as live by running transactions.  
  
This commit removes the replication slot advice from MultiXactId  
wraparound hints, and documents that stale replication slots are  
normally not relevant to resolving MultiXactId wraparound problems.  
  
Backpatch to all supported branches.  
  
BUG #18876  
Reported-by: Haruka Takatsuka <harukat@sraoss.co.jp>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/18876-0d0b53bad5a1f4c1@postgresql.org  
Backpatch-through: 14  

commit   : 98dd4406f7a44da9af56473fa22a03f885ea5e78    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jul 2026 13:27:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jul 2026 13:27:22 -0400    

The float4 and float8 btree_gist opclasses compared keys with raw C  
operators (==, <, >).  IEEE 754 makes every comparison involving NaN  
false, so GiST disagreed with the regular float comparison operators  
and with the btree opclass, which uses float[4|8]_cmp_internal()  
(so that all NaNs are equal and NaN sorts after every non-NaN value).  
  
In addition, the penalty and distance functions were not careful  
about NaNs, and the penalty functions could also misbehave for IEEE  
infinities.  Wrong answers from the penalty functions would probably  
do no more than make the index non-optimal, but the distance mistakes  
were visible from SQL.  
  
To fix, make the comparison functions rely on the same NaN-aware  
comparison functions the core code uses, and rewrite the penalty  
and distance functions to follow the rules that NaNs are equal  
but maximally far away from non-NaNs.  The penalty_num() code was  
formerly shared between integral and float cases, but I chose to make  
two copies so that the integral cases are not saddled with the extra  
logic for NaNs and infinities/overflows.  I also rewrote it as static  
inline functions instead of an unreadable and uncommented macro.  
  
The float penalty functions were previously unreached by the  
regression tests, so add new test cases to exercise them.  
  
There's no on-disk format change, but users who have NaN entries  
in a btree_gist index would be well advised to reindex it.  
  
Bug: #19501  
Bug: #19524  
Reported-by: Man Zeng <zengman@halodbtech.com>  
Reported-by: Yuelin Wang <3020001251@tju.edu.cn>  
Author: Bill Kim <billkimjh@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19501-3bff3bbc97f1e7c9@postgresql.org  
Discussion: https://postgr.es/m/19524-9559d302c8455664@postgresql.org  
Discussion: https://postgr.es/m/CAMQXxcgbtD2LXfX0tpgvOizxP-XxrCHV2ZDy4By_TZnJMsxXWQ@mail.gmail.com  
Backpatch-through: 14  

commit   : cf7530cf758af3e9c768dede995e53a7c49f69fd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Jul 2026 23:05:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Jul 2026 23:05:34 +0900    

Previously, if a base backup failed after it had started streaming  
files, pg_stat_progress_basebackup could continue to show a stale  
progress entry even though the backup was no longer running. This could  
be observed when the client kept the replication connection open after  
the error. It is normally not observable when using pg_basebackup,  
because the client disconnects after the error.  
  
The problem was that progress reporting was cleared only after  
successful completion.  
  
This commit moves the progress reporting cleanup into the progress  
sink's cleanup callback so that it is cleared after both successful  
and failed backups.  
  
Backpatch to v15. v14 has the same issue, but the fix does not apply  
cleanly because it lacks the base backup sink infrastructure. Since  
the bug does not affect the backup itself and is normally not  
observable when using pg_basebackup, skip the v14 backpatch.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/EA1A6CD2-EFA6-462B-9A02-03003555AB4A@gmail.com  
Backpatch-through: 15  

commit   : c754d9311509e3d3d2f22d264151e040e7a2d832    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Jul 2026 09:40:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Jul 2026 09:40:36 +0200    

off_t is most likely a 64-bit integer, so casting it to a 32-bit type  
for output could lose data.  There are more issues like this in the  
tree, but this is an instance where this could actually happen in  
practice, since base backups are routinely larger than 4 GB.  So this  
is separated out as a bug fix.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/20ce62fa-47fc-457b-b504-12f3c1651726%40eisentraut.org  

commit   : 225dd7ab4e6a48b1172bea26826a062f9d44f9cc    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 1 Jul 2026 08:50:08 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 1 Jul 2026 08:50:08 +0700    

Commit 4035cd5d4 added LZ4 compression for full-page writes in WAL, and  
retained "on" as a backward-compatible way to specify the builtin PGLZ  
method. Document this meaning of "on" and update postgresql.conf.sample  
to make the equivalence clear.  
  
Author: Christoph Berg <myon@debian.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/akJDHRtXwGLTppsQ@msg.df7cb.de  
Backpatch-through: 15  

commit   : d2980067bc3bcf44769cccbbdafb4e37099c890d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Jun 2026 08:52:50 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Jun 2026 08:52:50 +0900    

Previously, if an unlogged sequence was created on the primary and  
replicated to a standby, reading the sequence after promoting the  
standby (for example, with nextval()) could trigger the following  
assertion failure:  
  
    TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >= SizeOfPageHeaderData")  
  
In non-assert builds, the same operation could instead fail with an  
error such as:  
  
    ERROR:  bad magic number in sequence  
  
The problem was that seq_redo() updated the init fork page in shared  
buffers but did not flush it to disk. During promotion,  
ResetUnloggedRelations() recreates the main fork of unlogged  
relations by copying the init fork from disk, bypassing shared  
buffers. As a result, the main fork could be recreated from a stale  
init fork instead of the WAL-replayed page.  
  
Fix this by introducing a helper to flush init fork buffers  
immediately, and make seq_redo() use it. As a result, the main fork  
of an unlogged sequence is recreated from the up-to-date init fork on  
disk, allowing the unlogged sequence to be read successfully after  
standby promotion.  
  
Backpatch to v15, where unlogged sequences were introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com  
Backpatch-through: 15  

commit   : 12bff46ff3ebb639883679c89604e1c12dc895db    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 11:43:26 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 11:43:26 +0900    

PL/Python and its hstore and jsonb transforms build SQL values from  
Python containers by calling Python C API functions that can return  
NULL, and in several places the result was used without first checking  
it.  
  
On the sequence side, PySequence_GetItem() is used when converting a  
returned sequence into a SQL array or composite value, when reading  
the argument list passed to plpy.execute() or plpy.cursor(), and when  
reading the list of type names given to plpy.prepare().  On the  
mapping side, the hstore and jsonb transforms call PyMapping_Size()  
and PyMapping_Items() and then index the result with PyList_GetItem()  
and PyTuple_GetItem().  
  
All of these return NULL (or -1), with a Python exception set, for a  
broken object: for example one whose __getitem__() or items() raises,  
or which reports a length that disagrees with what it actually yields.  
The unchecked result was then dereferenced, crashing the backend.  
  
Fix this by checking the result of each call and reporting a regular  
error if it failed, so that the underlying Python exception is  
surfaced instead of taking down the session.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49BKM9wP6m8bCXEpHwQKp7usvOGV6Jf=J7FYr_BCpxLqg@mail.gmail.com  
Backpatch-through: 14  

commit   : 9b2a6ccc4793d19d06bd0926367011476157295c    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 24 Jun 2026 09:09:48 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 24 Jun 2026 09:09:48 +0900    

In get_perl_array_ref(), for a PostgreSQL::InServer::ARRAY object, we  
look up its "array" key with hv_fetch_string() and then inspect the  
returned SV.  However, hv_fetch_string() returns a NULL pointer when  
the key is absent, and the code dereferenced that result without first  
checking whether the pointer itself was NULL.  As a result, a plperl  
function returning a forged PostgreSQL::InServer::ARRAY object that  
lacks the "array" key would crash the backend with a segmentation  
fault.  
  
Fix this by checking the pointer returned by hv_fetch_string() before  
dereferencing it, matching how other callers in this file already  
guard the result.  With the check in place, such an object falls  
through to the existing error report instead of crashing.  
  
Author: Xing Guo <higuoxing@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CACpMh+DYgcnqZwQLXXuxQcehJTd7T8UmKWSLsK4mFBEp9G2ajA@mail.gmail.com  
Backpatch-through: 14  

commit   : b3e99a561f70cde0154867d576e7725093ce1071    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 16:52:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 16:52:19 +0900    

When ALTER TABLE ... ATTACH PARTITION matches partition indexes to the  
parent table's indexes, invalid indexes are skipped.  This commit  
improves the documentation to describe what e90e9275f56 has changed:  
invalid indexes are skipped, and only valid indexes are considered for a  
match.  
  
Author: Mohamed Ali <moali.pg@gmail.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAGnOmWpAMaE-BOkpwM6mJnHcpS2QZ8yLSSaqmz+vryEsbCWWWA@mail.gmail.com  
Backpatch-through: 14  

commit   : 9e47718250d8a57576843d1991e21c932c07c7d9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 07:59:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 07:59:03 +0900    

This routine acts as a wrapper of a new pgstat_drop_entry_ext(), used in  
the core code with a missing_ok argument.  
  
This includes an update of .abi-compliance-history, removing the latest  
entry that has documented the change of pgstat_drop_entry().  This  
change is applied across v15~v18.  HEAD keeps pgstat_drop_entry() as  
single entry point, with the new missing_ok.  
  
Per discussion with Álvaro Herrera and Lukas Fittl.  This is a follow-up  
of 850b9218c8e4.  
  
Discussion: https://postgr.es/m/ajZz_sVJVX7pmPHo@alvherre.pgsql  
Backpatch-through: 15-18  

commit   : 4647ac14230d716068d588d3048f1a6faa0f9061    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2026 12:52:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2026 12:52:00 -0400    

pg_mkdir_p creates each missing path component with a stat() followed  
by mkdir().  If the stat() reports the component as absent but another  
process creates it in the window before this process's mkdir(), mkdir()  
fails with EEXIST and pg_mkdir_p treated that as a hard error -- unlike  
"mkdir -p", which is meant to be idempotent and race-tolerant.  
  
This shows up when several processes concurrently create paths that  
share an ancestor directory: for example, parallel initdb runs whose  
data directories live under a common temporary directory.  One process  
wins the race to create the shared ancestor and the others fail with  
    could not create directory "...": File exists  
  
Fix this race condition by first trying mkdir() and only attempting  
stat() if it fails with EEXIST.  
  
On Windows, there's an additional problem: stat() opens a file handle  
and participates in share-mode locking, which means it can transiently  
fail on a directory another process is concurrently creating.  Use  
GetFileAttributes() instead: it requests only FILE_READ_ATTRIBUTES  
and is exempt from share-mode denial, so it reliably sees a  
concurrently-created directory.  
  
I (tgl) also chose to back-patch 039f7ee0f's effects on this function,  
so that pgmkdirp.c remains identical in all live branches.  
  
Author: Andrew Dunstan <andrew@dunslane.net>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3ca004de-e49b-4471-b8aa-fd656e70f68c@dunslane.net  
Backpatch-through: 14  

commit   : d0db43e880be7cd2113d78ad8500660050a949e7    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 18 Jun 2026 11:29:49 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 18 Jun 2026 11:29:49 -0500    

Newer gcc warns that this "actual_arg_types" variable may be used  
uninitialized, but visual inspection indicates there's no bug.  To  
silence the warning, initialize the variable to zeros.  
  
Bug: #19485  
Reported-by: Hans Buschmann <buschmann@nidsa.net>  
Tested-by: Erik Rijkers <er@xs4all.nl>  
Tested-by: Hans Buschmann <buschmann@nidsa.net>  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/19485-2b03231a775756f1%40postgresql.org  
Discussion: https://postgr.es/m/6c52a1a6612948519468d46cb224a8c4%40nidsa.net  

commit   : 4fbbabb0a729d643fcc3494f9c22cc700570c143    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jun 2026 12:22:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jun 2026 12:22:55 -0400    

Add CHECK_FOR_INTERRUPTS() to the while loop in plperl_to_hstore()  
that dereferences chains of Perl references, so that a circular  
reference (e.g. $x = \$x) can be cancelled by the user instead of  
spinning indefinitely.  (We looked at detecting such circular  
references, but it seems more trouble than it's worth.)  
  
This is a follow-up to da82fbb8f, which fixed the same issue in  
SV_to_JsonbValue() in jsonb_plperl.  
  
Author: Aleksander Alekseev <aleksander@tigerdata.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAJ7c6TPbjkzUk4qJ5dHvDNEz0hBuFue3A-XWz_=897z+BC+z8A@mail.gmail.com  
Backpatch-through: 14  

commit   : cfeb0b2b30f085fd24327a3950a8257ad8fa8c64    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 18 Jun 2026 09:31:27 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 18 Jun 2026 09:31:27 -0500    

Commit 6678b58d78 fixed a wrong "Prev" link by changing the link  
generation code to use [position()=last()] instead of [last()] in  
the predicate on the union of reverse axes.  Unfortunately, that  
caused documentation builds to take much longer.  To fix, combine  
the "preceding" and "ancestor" steps into one "preceding" step and  
one "ancestor" step, and revert the predicate back to [last()].  
The smaller union evades the libxml2 bug while avoiding the build  
time regression.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Tested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1132496.1781718007%40sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 8af173e2837084c462a5ee3478d1dbcd7cc9b1d6    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 18 Jun 2026 15:51:49 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 18 Jun 2026 15:51:49 +0900    

The two-argument jsonb @? and @@ operators invoke the jsonpath executor  
with no variable set.  In that case getJsonPathVariable() treated any  
"$name" reference as JSON null and continued evaluating, instead of  
reporting the variable as undefined.  
  
This produced incorrect results -- for example '42'::jsonb @? '$"x"'  
returned true -- and, for some malformed or hostile jsonpath expressions  
with deeply nested predicates, allowed essentially unbounded memory  
consumption that could get the backend killed by the OOM killer.  
  
Report the undefined variable as an error in this case as well, reusing  
the message already emitted when a variable is not found among supplied  
variables.  This matches the behavior of v17 and later, where the  
jsonpath executor was reorganized.  Stopping at the first undefined  
variable reference also resolves the reported memory-growth case.  
  
Note this is a user-visible change in the back branches: a jsonpath  
expression that references a variable while no variables are supplied now  
raises an error rather than silently evaluating it as NULL.  The previous  
behavior was incorrect, so the change is judged worthwhile.  
  
Bug: #19458  
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Nikita Malakhov <hukutoc@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/19458-a69c98bc498333ba@postgresql.org  
Backpatch-through: 14-16  

commit   : 75aca8b932e8c26f840a12c5fb7813d9fbcefcee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2026 14:48:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2026 14:48:43 +0900    

As noted in the commit message of 850b9218c8e4, this function has gained  
an extra called "missing_ok".  All the callers of this routine should be  
in core in the v15-v17 range.  For v18, I have found one custom stats  
kind that would be impacted by this change.  
  
Discussion: https://postgr.es/m/ajOE3uRxVgSlPRcw@paquier.xyz  
Backpatch-through: 15-18  

commit   : 1e9e62193c3fa66e39b50163f225388fcf6eb7d5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2026 11:49:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2026 11:49:41 +0900    

pgstat_drop_entry_internal() generates an ERROR if facing a pgstats  
entry already marked as dropped.  With a workload doing a lot of  
concurrent CALL and DROP/CREATE PROCEDURE, it could be possible for  
AtEOXact_PgStat_DroppedStats(), that wants to do transactional drops, to  
find entries that are already dropped, after a commit record has been  
written.  In this case, ERRORs are upgraded to PANIC, taking down the  
server.  
  
This issue is fixed by making pgstat_drop_entry() optionally more  
tolerant to concurrent drops, adding to the routine a missing_ok option  
to make some of its callers more tolerant (spoiler: some of the callers  
want a strict behavior, like replication slots and backend stats).  
pgstat_drop_entry_internal() cannot be called anymore for an entry  
marked as dropped, hence its error is replaced by an assertion.  
Functions are handled as a special case in core; this problem could also  
apply to custom stats kinds depending on what an extension does.  
track_functions is costly when enabled (disabled by default), which is  
perhaps the main reason why this has not be found yet.  
  
A similar version of this patch has been proposed by Sami Imseih on a  
different thread for a feature in development.  This version has tweaked  
here by me for the sake of fixing this issue.  
  
Reported-by: zhanglihui <zlh21343@163.com>  
Author: Sami Imseih <samimseih@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/19520-73873648d44793cf@postgresql.org  
Backpatch-through: 15  

commit   : a6f23c3ade0effb827255dd9f7df0d9515ce5b8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jun 2026 11:04:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jun 2026 11:04:41 -0400    

Add check_stack_depth() to Jsonb_to_SV, SV_to_JsonbValue,  
PLyObject_FromJsonbContainer, and PLyObject_ToJsonbValue.  Without  
this, deeply nested JSONB values can crash the backend with SIGSEGV  
instead of raising a proper error.  
  
Also add CHECK_FOR_INTERRUPTS() to the while loop in SV_to_JsonbValue  
that dereferences chains of Perl references, so that a circular  
reference (e.g. $x = \$x) can be cancelled by the user instead of  
spinning indefinitely.  (We looked at detecting such circular  
references, but it seems more trouble than it's worth.)  
  
Author: Aleksander Alekseev <aleksander@tigerdata.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAJ7c6TPbjkzUk4qJ5dHvDNEz0hBuFue3A-XWz_=897z+BC+z8A@mail.gmail.com  
Backpatch-through: 14  

commit   : e214cf509977e0b5219a6c103d62aa985c0946d6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Jun 2026 08:42:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Jun 2026 08:42:12 +0900    

The test did not wait for the standby to be connected to the primary.  
This breaks one assumption at the beginning of the test, where the  
primary is stopped to ensure that all its records are flushed to both  
standbys before moving on with its next steps.  
  
If standby_1 finishes ahead of standby_2, the test would be able work  
fine as the former waits for the latter.  The opposite is not true,  
standby_2 getting ahead of standby_1 would cause the test to fail on  
timeout when standby_1 attempts to connect to standby_2.  
  
This commit adds an additional polling query after the two standbys are  
started, checking that both standbys are connected to the primary before  
processing with the initial steps of the test.  
  
Like 7185eddf0522, backpatch down to v14.  
  
Author: Sergey Tatarintsev <s.tatarintsev@postgrespro.ru>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://postgr.es/m/fea4190e-f8b5-4432-a52d-bcbee5f34366@postgrespro.ru  
Backpatch-through: 14  

commit   : 1add4a41bc317b4efa053ad2f2d3347f94864789    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 16 Jun 2026 18:13:15 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 16 Jun 2026 18:13:15 +0200    

The error path in ReorderBufferProcessTXN was not freeing  
(reorderbuffer.c's representation of) a speculative insertion record  
correctly.  In assert-enabled builds, this leads to an assertion  
failure.  In production builds, I see no effect; there may be a small  
transient leak, but in an improbable code path such as this, such a leak  
is not of any significance.  For users running with assertions enabled,  
the crash is annoying.  
  
Fix by having ReorderBufferProcessTXN() free the speculative insert  
ahead of freeing the rest of the transaction, and no longer try to  
handle that insert as a separate argument to ReorderBufferResetTXN().  
  
This code came in with commit 7259736a6e5b (14-era).  Backpatch all the  
way back.  
  
In branches 14-16, also backpatch the assertion that originally fails in  
the problem scenario, which was added by dbed2e36625d (originally  
backpatched to 17), that at the end of ReorderBufferReturnTXN() the  
in-memory size of the transaction is zero.  
  
Author: Vishal Prasanna <vishal.g@zohocorp.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/19c7623e882.4080fd5426212.311756747309556767@zohocorp.com  

commit   : 1bec6b1c146cfd9ef52623178da0e873f1238d31    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 16 Jun 2026 09:27:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 16 Jun 2026 09:27:00 +0300    

The expression (len_diff * 10 * (an + 1)) used as the return value of  
ltree_compare() is computed at int32 width.  With LTREE_MAX_LEVELS =  
65535, the product can exceed INT32_MAX once an ltree has more than  
~14,653 levels, which causes the result to wrap and invert its sign.  
That corrupts btree ordering as well as the "magnitude" consumed by  
ltree_penalty() for GiST page splits.  
  
To fix, split ltree_compare() into two functions.  The new  
ltree_compare_distance() function returns a float, which won't  
overflow.  It's used by the ltree_penalty() caller.  All the other  
callers only care about the sign of the return value, i.e. which of  
the arguments is greater, so change ltree_compare() to not multiply  
the result with (10 * (an + 1)), which avoids the overflow for those  
callers.  
  
Existing btree or GiST indexes on ltree columns containing values with  
more than ~14,653 levels may be corrupt and should be REINDEXed.  
  
Add a regression test based on the reporter's PoC.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reported-by: 王跃林 <violin0613@tju.edu.cn>  
Discussion: https://www.postgresql.org/message-id/AI6AnABgKW93Qbx1jVzi84r9.8.1781322625756.Hmail.3020001251%40tju.edu.cn  
Backpatch-through: 14  

commit   : 819e5b964bbe97df4a08b29708c2e6db34f6c518    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2026 15:35:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2026 15:35:37 -0400    

Our handling of quoting within replication commands was pretty  
sloppy, typically looking like  
        appendStringInfo(&cmd, " SLOT \"%s\"", options->slotname);  
This is fine as long as options->slotname doesn't contain a double  
quote mark, but what if it does?  In principle this'd allow injection  
of harmful options into replication commands, in the probably-unlikely  
case that a slot name comes from untrustworthy input.  We ought to  
clean that up.  
  
Moreover, even the places that were trying to be more careful  
generally got it wrong, because they used quoting subroutines  
intended for SQL commands rather than something that will work  
with the replication-command scanner repl_scanner.l.  For example,  
several places naively use PQescapeLiteral() to quote option values  
for replication commands.  If the string contains a backslash,  
PQescapeLiteral() will produce E'...' literal syntax, which  
repl_scanner.l doesn't recognize.  Another near miss was to use  
quote_identifier() to quote identifiers.  That function won't quote  
valid lowercase identifiers unless they match SQL keywords ... but in  
this context, replication keywords are what matter.  Neither of these  
errors seem to risk string injection, but they definitely can cause  
syntax errors in replication commands that ought to be valid.  
  
We can clean all this up by using simple quoting logic that just  
doubles single or double quotes respectively.  
  
Or at least, we could if repl_scanner.l handled doubled double quotes  
in identifiers, but for some reason it doesn't!  So the first step in  
this fix has to be to fix that.  (The fact that we'll later reject  
slot names containing double quotes is very far short of justifying  
this omission.)  
  
Having done that, this patch runs around and applies correct  
quoting in all places that generate replication commands containing  
strings coming from outside the immediate context.  Probably some  
of these places are safe because of restrictions elsewhere, but it  
seems best to just quote all the time.  
  
This was originally reported as a security bug, which it could be  
if replication slot names or parameters were to originate from  
untrustworthy sources.  But the security team concluded that that  
was a very improbable situation, so we're just going to fix this  
as a regular bug.  
  
Reported-by: Team Dhiutsa  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/1648659.1781287310@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : d018e927bc89a85d1363e6b0d863003d0be0c7e0    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 15 Jun 2026 12:16:38 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 15 Jun 2026 12:16:38 -0500    

Presently, the "Prev" link on the page for background workers sends  
you to the middle of the previous chapter instead of the actual  
previous page.  This appears to be caused by a libxml2 bug, but  
regardless, a minimal fix is to change the link generation code to  
use [position()=last()] instead of [last()] in the predicate on the  
union of reverse axes.  
  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/aim4AZorFKaC7Wrf%40nathan  
Backpatch-through: 14  

commit   : 0f63b74a47307bf00fd6301cc3612f9db924a0d1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Jun 2026 11:28:45 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Jun 2026 11:28:45 +0300    

If a query has more than 7498 params, the ParameterDescription message  
exceeds the 30000 byte limit on messages that are not specifically  
marked as possibly being longer than that (VALID_LONG_MESSAGE_TYPE).  
To fix, add ParameterDescription to the list.  
  
Author: Ning Sun <classicning@gmail.com>  
Discussion: https://www.postgresql.org/message-id/dbfb4b65-0aa8-470a-8b87-b6496160b28a@gmail.com  
Backpatch-through: 14  

commit   : 2adc3c8ebdfbab1a794175a7df8354d1e6f6cd67    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2026 11:38:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2026 11:38:00 +0900    

This commit reduces the number of expected output files for the "xml"  
test from three to two (well, mostly one, see below for details).  
  
xml_2.out existed to handle some differences in output due to libxml2  
2.9.3, due to some error context missing (085423e3e326).  This file is  
removed, by tweaking the XML inputs to trigger the same error patterns  
for the problematic 2.9.3 and other libxml2 versions.  This part is  
authored by Tom Lane.  
  
xml_1.out (no libxml2 support) is reduced in size by adding an \if query  
that exits the test early.  This still checks NO_XML_SUPPORT() through  
xmlin().  The rest of the test is skipped if XML input cannot be  
handled by the backend.  This part has been written by me.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/aiu6CXO67q-s70n5@paquier.xyz  
Backpatch-through: 14  

commit   : 5be9f84fe37528515e2c92080ed0b73273ed813a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Jun 2026 11:01:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Jun 2026 11:01:48 -0400    

Commit 2f70fdb06 removed the deprecated containment operator  
~(aclitem[],aclitem) from the catalogs, but missed removing its entry  
from the documentation.  (Arguably the blame should fall on c62dd80cd,  
which added this entry in contravention of the longstanding policy  
that we don't document deprecated aliases in the first place.)  
  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAOzEurQSyR5psWukyhUz1LtxyO55C2Vfp0Fmt8w2jGKxhszQmQ@mail.gmail.com  
Backpatch-through: 14  

commit   : 4284476c0f67e9b3c4be36203193ca8ce8f21d40    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jun 2026 02:49:05 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jun 2026 02:49:05 +0300    

bt_normalize_tuple() uses VARSIZE() to get the size of varlena, even though  
it's not yet known, that it has a 4-byte header.  Fix this by replacing a  
accessor with a universal VARSIZE_ANY().  
  
Backpatch to all supported versions.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/7ckc7oka4bvafkf5bwlqs6ygrhlsbhz25ppozfch7zbuxcx3rf%40e4pr4oqenalc  
Author: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Backpatch-through: 14  

commit   : 8aede3600c84db3d66966ce78a13013911bb2619    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 Jun 2026 18:05:25 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 Jun 2026 18:05:25 -0400    

Commit 0e1f1ed157e taught seg_out() to print the certainty indicator  
on an interval's upper boundary, but it was back-patched only as far  
as v14.  When upgrading from an older release, the old server prints  
the one test_seg row exercising that case ('4.6 .. ~7.0') without the  
indicator, so the pre- and post-upgrade dumps do not match.  Make  
AdjustUpgrade.pm delete just that row; seg's comparison function does  
distinguish the certainty indicators, so the otherwise identical row  
'4.6 .. 7.0' is unaffected.  
  
Back-patch to all supported branches.  
  
Per buildfarm members crake and fairywren.  
  
Discussion: https://postgr.es/m/5ccbdbde-6467-4a10-bf4d-0be73a05ce8d@dunslane.net  

commit   : 10f087987741394254323bf0016ad1d631494a3d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 Jun 2026 10:20:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 Jun 2026 10:20:34 -0400    

Commit ca9e9b08e453 wrongly tried to import devnull from File::Spec, but  
it's not exported, you just call the method via the class. This was  
harmless until modern perls complained, so stop doing that.  
  
Per buildfarm failures.  
  
Backpatch 14 thru 16  

commit   : c7f70fa1b58d0fc22a49779e1b1f30f8b7065d79    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 12 Jun 2026 13:57:22 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 12 Jun 2026 13:57:22 +0200    

OpenSSL 4.0.0 changed some parameters and returnvalues to const, so  
we need to update our declarations and subsequently cast away const-  
ness from a few callsites to make libpq build without warnings. This  
is tested with OpenSSL 1.1.1 through 4.0.0 as well as with LibreSSL.  
No functional change is introduced, this commit only allows postgres  
to be compiled against OpenSSL 4.0.0 without warnings.  
  
There is also an errormessage change in OpenSSL 4.0.0 which needed  
to be covered by our testharness.  
  
This will be backpatched to all supported branches since they are  
all equally likely to be built against OpenSSL 4.0.0 as it becomes  
available in distributions.  Backpatching will be done once it has  
been in master for a few days without issues.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/066B07BB-85FA-487C-BE8C-40F791CFC3C4@yesql.se  
Backpatch-through: 14  

commit   : 9618e790c37a47485f6d2b5b9b43ff18d6a17223    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 12:37:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 12:37:21 +0900    

This one has been forgotten in 8bf257aebac1.  Per report from buildfarm  
member massasauga.  
  
Backpatch-through: 14  

commit   : 87432b56b21d94a282c7fc2b7a12601421081d48    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 11:08:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 11:08:33 +0900    

Commit a70bce43fb added instructions on how to recover if PostgreSQL  
refuses to issue new transaction IDs because of imminent wraparound,  
but when describing how to find replication slots that should be dropped,  
it referred to pg_stat_replication where it should have referenced  
pg_replication_slots.  
  
In passing, decorate references to views with <structname> tags.  
  
Backpatch to all supported versions.  
  
Reported-By: Sanjaya Waruna <sanjaya.waruna@gmail.com>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/176767268098.1084085.10345048667224193115@wrigleys.postgresql.org  
Backpatch-through: 14  

commit   : 1d8c72b2eff61202f3b35c0c130a52231cb3590a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:54 +0900    

xpath() attempted to call xmlCopyNode() and xmlNodeDump() on a  
XML_NAMESPACE_DECL, finishing with a confusing error:  
=# SELECT xpath('//namespace::foo', '<root xmlns:foo="http://127.0.0.1"/>');  
ERROR:  53200: could not copy node  
CONTEXT:  SQL function "xpath" statement 1  
  
xpath() is changed so as it goes through xmlXPathCastNodeToString()  
instead, that is able to handle namespace nodes.  xml2 uses the same  
solution.  This issue has been discovered while digging into  
9d33a5a804db.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aioT7ui_ZJ9RMlfM@paquier.xyz  
Backpatch-through: 14  

commit   : b3aa2083a4dabdcfa4b240f956c49784ec0fb34d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Jun 2026 12:33:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Jun 2026 12:33:48 +0300    

When printing the upper boundary of a seg interval, seg_out() decided  
whether to emit the certainty indicator ('<', '>' or '~') by testing the  
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower  
indicator (l_ext) for '~'.  This is a copy-and-paste slip from the  
symmetric code that prints the lower boundary a few lines above.  
  
The consequences for valid input were:  
  
  * A '~' on the upper boundary was dropped on output, e.g.  
    '1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.  
  
  * When the lower boundary carried '~' but the upper boundary had no  
    indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)  
    wrote a NUL byte (u_ext == '\0'), which truncated the result string  
    and silently lost the entire upper boundary, e.g.  
    '~6.5 .. 8.5'::seg printed as '~6.5 .. '.  
  
Certainty indicators are documented to be preserved on output (they are  
ignored by the operators, but kept as comments), so this broke the  
input/output round-trip for the affected values.  
  
The bug has existed since seg was added.  It went unnoticed because the  
existing regression tests only exercised certainty indicators on  
single-point segs, which are printed by a different branch of seg_out().  
Add tests that place indicators on both boundaries of an interval.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail.com  
Backpatch-through: 14  

commit   : bc5775149f59cc6d80c2a5ceb410bba473a12407    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 14:29:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 14:29:28 +0900    

pgxmlNodeSetToText() passed nodeTab[i]->doc to xmlNodeDump() without  
checking the node type, which could cause a crash as a  
XML_NAMESPACE_DECL maps to a xmlNs struct.  The passed-in code would  
then be dereferenced in xmlNodeDump().  
  
This commit switches the code to render XML_NAMESPACE_DECL nodes with  
xmlXPathCastNodeToString(), like xpath_table().  Some tests are added,  
written by me.  
  
Author: Andrey Chernyy <andrey.cherny@tantorlabs.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20260611031436.5afde3cb@andrnote  
Backpatch-through: 14  

commit   : a7e0e42a226dc99f62987237d8356a7536f1890a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2026 11:47:40 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2026 11:47:40 -0700    

Previously, outlen was miscalculated if case_sensitive was false and  
str_tolower() changed the byte length of the string. If outlen was too  
large, pnstrdup() would stop at the NUL terminator, preventing  
overrun. But if outlen was too small, it would cause truncation.  
  
Fix by just removing outlen. It was only used in a single site, which  
could just as well use pstrdup().  
  
Discussion: https://postgre.es/m/1101e1a3afbbabb503317069c40374b82e6f4cac.camel@j-davis.com  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Backpatch-through: 14  

commit   : caebac5f16f97e258da07e1fb0d3dfcb56ecce8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Jun 2026 11:48:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Jun 2026 11:48:07 -0400    

The operators for array_eq, record_eq, range_eq, and multirange_eq  
are all marked oprcanhash, but there's a pitfall: their hash functions  
can fail at runtime if the contained type(s) are not hashable.  
Therefore, the planner has to check hashability of the contained types  
before deciding it can use hashing in these cases.  Not every place  
had gotten this memo, and noplace at all had considered the issue  
for ranges or multiranges.  In particular we could attempt to use  
hashing for a ScalarArrayOpExpr on a container type when it won't  
actually work, leading to "could not identify a hash function ..."  
runtime failures.  
  
For the most part we should fix this in the lookup functions provided  
by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable.  
But there's a problem: get_op_hash_functions is not passed the input  
data type it would need to check.  We mustn't change the API of that  
exported function in a back-patched fix, and even if we wanted to,  
its call sites in the executor mostly don't have easy access to the  
required data type OID.  Fortunately, the executor call sites don't  
actually need fixing, because it's expected that the planner verified  
hashability before building a plan that requires it.  Therefore,  
leave get_op_hash_functions as-is and invent a wrapper function  
get_op_hash_functions_ext that does the additional checking needed  
in the planner's uses.  
  
We also need to fix hash_ok_operator (extending the fix in 647889667).  
  
While at it, neaten up a couple of places in lookup_type_cache where  
relevant code for multirange cases was written differently from the  
code for other container types.  
  
Note: while this touches pg_operator.dat, it's only to add oid_symbol  
macros.  So there's no on-disk data change and no need for a  
catversion bump.  
  
Reported-by: Andrei Lepikhov <lepihov@gmail.com>  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com  
Backpatch-through: 14  

commit   : 668ecfda7250995b8ff4c8a59c3f6371b0efe2a2    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 8 Jun 2026 10:33:52 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 8 Jun 2026 10:33:52 -0500    

The security team has received a couple of reports about potential  
SQL injection via refint's trigger arguments.  We discussed this  
while preparing CVE-2026-6637 and concluded that forcibly quoting  
these arguments is more likely to break working code than to  
prevent exploits.  Unlike data values, the table/column names come  
from trigger arguments, and there is little reason for a trigger  
author to put hostile inputs into those arguments.  So, let's  
document it accordingly.  
  
Reported-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reported-by: Alex Young <alex000young@gmail.com>  
Reported-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com>  
Suggested-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com>  
Discussion: https://postgr.es/m/ahXP7z7nsfGPOZ3T%40nathan  
Backpatch-through: 14  

commit   : bfeddcf09b684ddb83895f7daaf1e28630718463    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 8 Jun 2026 17:11:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 8 Jun 2026 17:11:12 +0900    

Previously, ecpg accepted multiple descriptor header items in GET DESCRIPTOR  
and SET DESCRIPTOR, but generated broken C code when they were used.  
Although the grammar allowed this syntax, the implementation did not actually  
support it.  
  
This commit tightens the ecpg grammar so the header form of GET/SET DESCRIPTOR  
accepts only a single header item, matching the implementation and preventing  
generation of broken C code.  
  
Also update the documentation synopsis accordingly.  
  
Backpatch to all supported versions.  
  
Author: Masashi Kamura <kamura.masashi@fujitsu.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Lakshmi G <lakshmigcdac@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/OS9PR01MB13174AD7D1829D0644B6BB90E9447A@OS9PR01MB13174.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : 022ba5c61412765d6aa3792b4dcfadc1ccbd72d3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 14:38:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 14:38:00 +0900    

When a table's columns are narrower than the record header line, the  
expanded aligned format produced misaligned output because the data  
column width was not adjusted to match the record header width, leading  
to output like:  
+-[ RECORD 1 ]-+  
| a | 10 |  
| b | 20 |  
+---+----+  
  
This commit adjusts the output so as the column width match with the  
header line, giving:  
+-[ RECORD 1 ]-+  
| a | 10       |  
| b | 20       |  
+---+----------+  
  
Author: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAFj8pRCzGpsr9zTHbtTd4mGh2YPJqOEgLgt8JLiopuYA9_1xGw@mail.gmail.com  
Backpatch-through: 14  

commit   : eeed86523bb9cd7064e540f29e057d123e18914a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:53:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:53:00 +0900    

Before v17, WAL senders can shut down after the checkpointer.  If a WAL  
sender still has pending statistics when the checkpointer has already  
exited, its shutdown callback may attempt to report those statistics and  
trigger assertions in pgstats.  In that case, the pending statistics are  
lost.  
  
This commit adjusts the assertion handling so that attempts to report  
pending WAL sender statistics after the checkpointer has completed its  
final stats flush are skipped.  
  
Preserving the existing assertion would require backpatching an  
equivalent of 87a6690cc69, ensuring that the checkpointer is always the  
last process to exit.  Such a change would be considerably more invasive  
and risky for stable branches because it alters the shutdown sequence,  
and the consequence is only some loss of stats data for the WAL sender.  
  
This assertion failure was periodically detected in the buildfarm,  
leading to spurious failures.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/18158-88f667028dbc7e7b@postgresql.org  
Backpatch-through: 15-17  

commit   : 51f63ba2bf7f4a619f9e4251450ee462ba8505dc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:16:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:16:44 +0900    

heap_force_common() declared a boolean array indexed with an  
OffsetNumber for a size of MaxHeapTuplesPerPage.  OffsetNumbers are  
1-based, so an input TID whose offset number equals MaxHeapTuplesPerPage  
wrote one byte past the end of the stack array, crashing the server.  
  
Like heapam_handler.c, this commit changes the array so as it uses a  
0-based index, substracting one from the OffsetNumbers.  
  
Reported-by: Wang Yuelin <violin0613@tju.edu.cn>  
Reviewed-by: Ashutosh Sharma <ashu.coek88@gmail.com>  
Discussion: https://postgr.es/m/20260604002256.40f1fd544@smtp.qiye.163.com  
Backpatch-through: 14  

commit   : b7b513d9afabf43124edda3dff7dd8af39906951    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 5 Jun 2026 12:08:05 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 5 Jun 2026 12:08:05 -0500    

Presently, refint stores plans in a per-backend cache to avoid  
re-preparing in each call.  This has a few problems.  For one,  
check_foreign_key() embeds the new key values in its cascade-UPDATE  
queries, so a cached plan reuses the values from preparation.  
Also, the cache is never invalidated, so it can return stale  
entries that cause other problems.  There may very well be more  
bugs lurking.  
  
We could spend a lot of time trying to address all these problems,  
but this module is primarily intended as sample code, and by all  
indications, it sees minimal use.  Furthermore, there is a growing  
consensus for removing refint in v20.  However, since we'll need to  
support it on the back-branches for a while longer, it probably  
still makes sense to fix some of the more egregious bugs.  
  
Therefore, let's just remove refint's plan cache entirely.  That  
means we'll re-prepare on every call, but that seems quite unlikely  
to bother anyone.  On v17 and older versions, the regression test  
for triggers fails after this change, so I've borrowed pieces of  
commit 8cfbdf8f4d to fix it.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAJTYsWXU%2BfhuzrEd_bnrxyGH3%2Bny8QRQC2QHf3ws6s9iki3c2Q%40mail.gmail.com  
Backpatch-through: 14  

commit   : c391375ba4964dad9cbeedf700ae4df1d6af8b5b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 07:50:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 07:50:16 +0900    

The NFC recomposition incorrectly included TBASE as a valid T syllable,  
which is incorrect based on the Unicode specification (TBASE is one  
below the start of the range, range beginning at U+11A8).  
  
This would cause the TBASE to be silently swallowed in the  
normalization, leading to an incorrect result.  
  
A couple of regression tests are added to check more patterns with  
Hangul recomposition and decomposition, on top of a test to check the  
problem with TBASE.  Diego has submitted the code fix, and I have  
written the tests.  
  
Author: Diego Frias <mail@dzfrias.dev>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/B92ED640-7D4A-4505-B09F-3548F58CBB16@dzfrias.dev  
Backpatch-through: 14  

commit   : b3a86eb6d42753cbf65e690050bdc442ae136729    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 12:24:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 12:24:51 -0400    

This commit addresses two related issues:  
  
tsvector_filter() assumed it could print an incorrect weight value  
with %c.  This could result in an invalidly-encoded error message  
if the database encoding is multibyte and the char value has its  
high bit set.  Weight values that are ASCII control characters  
could render illegibly too.  Fix by printing such values in octal  
(\ooo), similarly to how charout() would render them.  
  
tsvector_setweight() and tsvector_setweight_by_filter() reported  
the same unrecognized-weight error condition with elog(), as though  
it were an internal error.  That'd not translate, would produce an  
unwanted XX000 SQLSTATE code, and also reported the bad value as a  
decimal integer which seems unhelpful.  Fix by refactoring so that  
all three functions share one copy of the code that interprets a  
weight argument.  
  
The invalid-encoding aspect seems to me (tgl) to justify  
back-patching.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAON2xHNaeLAUzRCXL5AmXLcXaSE_gWAVjWQRmLzc_oZ=1_Vf4Q@mail.gmail.com  
Backpatch-through: 14  

commit   : 96d68502801dcfe7165e3a586bed20979dda51e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 11:37:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 11:37:43 -0400    

Like 8f1791c61, this fixes a case of implicitly casting away  
const by not treating the result of strrchr() on a const pointer  
as const.  This was missed at the time because the machines  
reporting those warnings weren't building with --with-llvm.  
  
While here, clean up another infelicity: in the probably-  
impossible case that the input string contains only one dot,  
this function would call pnstrdup() with a length of -1  
and thereby emit a module name equal to the function name.  
It seems to me we should emit modname = NULL instead.  
  
Also remove a useless Assert and two redundant assignments.  
  
Back-patch, as 8f1791c61 was, so that users of back branches  
don't see this warning when building with late-model gcc.  
  
Reported-by: hubert depesz lubaczewski <depesz@depesz.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aiGNJ89PBqvq2Yyz@depesz.com  
Backpatch-through: 14  

commit   : a4eb59d40f278471d5b83a25cef6e56bc997e696    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2026 18:47:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2026 18:47:31 +0900