PostgreSQL 14.24 commit log

commit   : 6b3806732b7c5df06bdd0ed150e8a07b4ad62315    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:59:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:59:18 -0400    

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

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

commit   : fa01ab74775543a92885843861bafdcb536ad9dd    
  
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   : 2006fca401e07fc116a5d1777fc0f22bf49c9fae    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:37 -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   : e2c48c81fcf858266625e835becff3f17478beea    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:37 -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   : 7e29eb6f4a154124602658531df2555e2693e4dc    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:37 -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   : 42d333a78233599a25b34b66af940a87446d58c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 5c51ae4556f1e058779f48f95d3ddcf305fb6e8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 7215c7e9643f21c51a73b0d2eecd0bc3110b683c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : f4174aa84a3ce73ac8dd20f0a6b495d00028d3f0    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : b6e45b4f82481b54134640887fc1cdf4791f9b3a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 1a358b8f2a28aaf3a7bfc8cf710de7a39c98436d    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 323af0a4ee5e7d2ccebb85d4bd5615a1a6b6fd1f    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 9505175f2a782bb63acd11d8d473a0ccedb719ea    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 1f49beef271ef920f129fcb8513c56347803444a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : bf3842a64f5df489fab31b82aaeb9067ac938fde    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 39d792040c7cc02b8a805b96b718e723a15f1641    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:36 -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   : 967acab87f01933859fd73ee206898b4b320e186    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 74c59d062ad7a99fb90e38390e7d5b90e7a69527    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : aff9dac1c198767d997cd8099f9154169168f272    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : a74aa0854d5e7c6c14c7d31f41bc7adc366f3ef7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 70a3b4e1831c06b0cbce601c3361db5140b9daf1    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 913fe0c316a6d024434e66f084acbb605293265a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 155dacbc5479a9bfbcb47e88ff68a758c73b6a8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : c7f4628382071ef87f5e7fee8939f09db1e5e022    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 57aa21f69127d21e284c5db8eb488b1eccbb6a1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : cf44ff5e66353264451ac239b39e9053e8d138e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 59205c7e9b4a3afbdab4d677c16036cdd1bd080d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : d7fcfead3da81843a800f8bb046d4cb09d1c662d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 890327639962a0ebbb2cc2b81ba747cc381876c3    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:35 -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   : 1e3014f373c77c2bdd52766b5c14c7ea2653b838    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:34 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:34 -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   : 7c2ba321d35f18f2c5dc7b5c4a212467f7fb2fc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:34 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:34 -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   : 7eb5ad4c367a29ba8c73d35f7587d10995064496    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:28:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:28:48 +0200    

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

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

commit   : cec48686a0d781806a262c548adb7d0fb06868fc    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:06 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:06 +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   : 49a712f32ceebfeecac9017a49f5b1fe89ae399f    
  
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   : e9d53cf459419cc7fd32dc85c59ee08ee5bbf1f4    
  
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   : cad17745edbf1234cd53293260b6e681eb8f6dd3    
  
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   : fec40878c8702ff4e58241d00a1914d8568bec03    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:01:55 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:01:55 +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   : 529fc19ccc9c6044e6123274ffeef606bbf6a6b5    
  
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   : dda622edcdba673e90d7b2cafe747ab78249368b    
  
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   : cfc720ef4b1d1643f73ffd60621a7a332a7faf7b    
  
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   : 812cc1a734bb86ab6cedfd168e3e415eed463e3b    
  
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   : 6098f35f44ef7df3ec829c4c1e69d015a0136ad3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:39:21 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:39:21 +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   : 01a6119af074a3d346e3f749df7f63cd45acbaaf    
  
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   : 5fb3c638910cdac2e00861e6f6806d9e03e5831d    
  
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   : 13b627a3e1811577e830c8b0a4a2cc095b22ac47    
  
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   : c2d34db0a5eced16cf8d7e1004674b20b8fa383d    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:50 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:50 -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   : 15fd7a3e2eeb6de915cae6ea30f40a8e9100cbfe    
  
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   : 55adef7abbe8ecfa329335640b598cbb57be0f93    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:21 +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   : f1c579fc45fdbf28949e9caa21ec357f0e44ac29    
  
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   : 2fc3e1b44a4b4bb9b01adced7b040b51dc9606a0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:24 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:24 -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   : 4e19081da88677a6f2e9b6d100768f4f715f95d6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 25 Jul 2026 19:11:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 25 Jul 2026 19:11:34 +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   : 665bf40a132a857f1790de2aebffb14f85da7b6a    
  
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   : e4ad22eb02f0c41c8d14977f91ea7a36f8e23e81    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:52:56 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:52:56 -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   : d7b62e3c22102898a6106baa129a2e6b838b4bc1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:06:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:06:02 +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   : 2f4f193fdbe057029b87ae45822e22e7a8b85693    
  
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   : e6e8277f420f3b348ad5e414761196c5d02acb82    
  
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   : 99eb806ab48f77d06b9e902742d0b91f289b1ffa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:46 +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   : 5c1004b0d33426f642808133c282c09cdd0a4f86    
  
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   : 7532f2117c4e422ca08896473689f589309219c3    
  
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   : f5f569713b871ca6771e6fbaf5d4de16d4df1728    
  
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   : fd224fe90823de3df4f209c09a5794606ff70dc7    
  
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   : 1e8f393f2d037d3821e79349c8fac22ce697e8cd    
  
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   : d3888c90a07f1a2134a162eace20d6e32eb38038    
  
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   : 1b018b5d10561a49fcd987a0a659ec06fbd6ee8f    
  
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   : f59a592f9b2fe64affdbc63187d2da763df0caf0    
  
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   : 0115650de9374888f2e64d8dae5fbfd06ec45c7e    
  
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   : 1b17a6e3cd89f76ea5db6260c79db620d5a7793b    
  
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   : 286f9a3cec4b9c4b1d1c49d0b35b6ef074ed2629    
  
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   : 2d44bb9009cdc0454d863a03a78812b4259b3381    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 13:50:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 13:50:51 +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   : 802dc79df63b6af33429e99c497a7ecc8dca378d    
  
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   : 255bce44884ec5e12414760e5865a95dedb39925    
  
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   : 309dc4526de5ca4cb871fae80a1470feb0fad231    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 14:21:15 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 14:21:15 +0900    

Commit 0b7719f74 added regression tests that spell the language name  
as plpython3u.  That works on the master branch, but on v14 the  
plpython tests must use the unversioned name plpythonu: the plpython3u  
extension is built only in Python 3 builds, and for those builds  
regress-python3-mangle.mk rewrites plpythonu to plpython3u in the test  
files.  In a Python 2 build the new tests instead failed with  
"language \"plpython3u\" does not exist".  
  
Spell the language as plpythonu in the new tests, matching every other  
plpython test in this branch, so they work in both Python 2 and Python  
3 builds.  This is needed only in v14; later branches no longer  
support Python 2 and have dropped the mangling step.  
  
Per buildfarm member hippopotamus.  

commit   : 0b7719f744e694a2a1946f7ddf230bf4fdfad20c    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 11:44:35 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 11:44:35 +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   : e520ad34b482cc3a441f10ded0320d42db2625ed    
  
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   : e8fbe5d838f50d0641d40f98b44f3698ad0846c1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 16:52:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 16:52:21 +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   : 4b3bc6b714531438cee299648f12e70c5cc38ebb    
  
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   : b2a6a27bac38272231d096f41250193e0301d759    
  
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   : 1f6b2295f95263a5e5767fb4af6440153a7f02af    
  
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   : 1d216f1e772369c0275b46029821de6802fe40b9    
  
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   : 3640143270a9f1f115cf03a16bee3fd469ba1116    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 18 Jun 2026 15:51:38 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 18 Jun 2026 15:51:38 +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   : 639fff5118a846fdb604824a87f4d77cc286d89d    
  
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   : d75146456fa5ebcb50a084cd4e2db61ab108c233    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Jun 2026 08:42:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Jun 2026 08:42:13 +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   : 0939aad564029ff78e1fb9b79bf8b1dd1c0b38d6    
  
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   : f528a5606a836289c8cf3faa09874439b6f79c8f    
  
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   : 2a00840e8c9772b5b22accd652a495d7c654693e    
  
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   : 924172c56549c39362d64cf01e312a8be229509f    
  
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   : 1b79c8d1a58195c1c6bedd336ce509f0b01c14d7    
  
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   : 102689827fa7253e4a46ec76603f2148a6bbbfee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2026 11:38:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2026 11:38:02 +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   : b94996ddd70bbabb2c5ce2a3078751b4f4552dad    
  
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   : af09b18cbadbb91ffe617b9ee5549de420e9b21a    
  
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   : 7974f94a02a1b39d7c84737ced41890386aaae67    
  
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   : b31fa1f87f373d8d2fdc43a489ef5611de7a2af7    
  
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   : 086652c02f49ca04c3123faf14b2f5cabdf31f7d    
  
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   : a17f39aa2f5f5867f5e2afc87ec280caa1f65e62    
  
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   : e3a4e9edd5c0ed1d1ae1ec00fbc27cf8f8598515    
  
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   : 41876c8d77834021d9b1f2b4f62c27c886f47c3b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:59 +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   : 58b91fc73a8679a78e7dc1430169a555ee5c8a81    
  
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   : f3f901a53a17da5c4f21c1df628d187b6aff1889    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 14:29:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 14:29:29 +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   : 1e04581729421944e18f4a4a10f6d7a8a8e95169    
  
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   : 64778fac724ac4e70473937f2d94d397af5a2785    
  
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   : 673161b63e245674a1bebf5583264ba8ca283946    
  
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   : 9e8fd9f7ab56965dfe012d6be1df152ea8f62aec    
  
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   : a4ca91ea18916c66fa3539c2fd19d8ba571ce7e8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 14:38:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 14:38:01 +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   : 1eda3eb0753ac6c788c11830e9abc0821f7afd48    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:16:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:16:46 +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   : 5b72d0279be1f1e981abddff95bbf1913b2b16fc    
  
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   : 8bb935d619f6397ca91742195965d20b0ee5df6c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 07:50:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 07:50:18 +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   : 262cc4df28976622aed47239c66f0bf56b1ce7bf    
  
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   : 7bdff3e890e3d1149e9753b61667ccd14f15e6f4    
  
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   : 968c508457b3542387c5ee47426565dd20846ab0    
  
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    

When releasing an ephemeral replication slot, ReplicationSlotRelease()  
drops the slot via ReplicationSlotDropAcquired().  
  
However, after dropping the slot, ReplicationSlotRelease() continued  
to use its local "slot" pointer, which still referenced the dropped  
slot's former shared-memory entry. It could then update fields such as  
effective_xmin in that entry.  
  
Once an ephemeral slot has been dropped (via ReplicationSlotDropAcquired()),  
its slot array entry can be reused immediately by another backend  
creating a new slot. As a result, those updates could corrupt  
the state of an unrelated replication slot.  
  
Fix by skipping those shared-memory updates for phemeral slots and  
performing them only for non-ephemeral slots, whose shared-memory  
entries remain valid after release.  
  
Backpatch to all supported versions.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Masao Fujii <masao.fujii@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : 74d3482f45dd8924579a9e5d10f8b15756e9db24    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 12:47:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 12:47:34 +0900    

The code failed to initialize the second isnull argument passed to  
FunctionCallInvoke().  This is harmless for existing in-core extended  
hash support functions, since FunctionCallInvoke() does not use the  
value (note that all the in-core extended hash functions are strict),  
examining only the argument values.  However, extension-provided  
extended hash functions could be affected if they inspect  
PG_ARGISNULL(1).  
  
Oversight in 01e658fa74cb.  
  
Author: Man Zeng <zengman@halodbtech.com>  
Discussion: https://postgr.es/m/tencent_7818173C01E01836109848C3@qq.com  
Backpatch-through: 14  

commit   : d616e741fe61838f15d22bf470bca86b786b3554    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2026 21:27:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2026 21:27:50 +0300    

Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/20260528.114608.488039299811669368.horikyota.ntt@gmail.com  
Backpatch-through: 14  

commit   : b67b2cd702725f79ff16b7e01b3d49e54a360a2a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2026 11:34:14 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2026 11:34:14 -0400    

With address sanitizer's stack-use-after-return check, stack variables are  
moved to heap allocations, to allow to detect references to the memory at a  
later time. That broke our stack-depth check, which is why we had to disable  
detect_stack_use_after_return in CI. Luckily __builtin_frame_address() works  
correctly, even under asan, so use that.  
  
We started using __builtin_frame_address() with de447bb8e6fb, however as of  
that commit we just used it for the stack base address, not for the value to  
compare to the base address.  Now we use it for both.  
  
When building without __builtin_frame_address() support, we continue to use  
stack variables for the stack depth determination.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2kk4z4odvuyrg7qlwjd7ft4eron4cle4btb33v4qatgsdkayir@gj6e62rgsel4  
Backpatch-through: 14  

commit   : 5100bdbd3ba20caf00c8074b61326f80d9255a65    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:58 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:58 +0300    

Concurrent DDL can leave behind objects referencing other objects that  
no longer exist. This can happen if an object is dropped, while a new  
object that depends on it is created concurrently. For example:  
  
session 1: BEGIN; CREATE FUNCTION myschema.myfunc() ...;  
session 2: DROP SCHEMA myschema;  
session 1: COMMIT;  
  
DROP SCHEMA does check that there are no objects dependending on the  
schema being dropped, but it does not see objects being concurrently  
created by other sessions. Even if it did, this scenario would still  
fail:  
  
session 1: BEGIN: DROP SCHEMA myschema;  
session 2: CREATE FUNCTION myschema.myfunc() ...;  
session 1: COMMIT;  
  
When the DROP SCHEMA runs, the schema was empty, but the new function  
is created in it before the dropping transaction completes. The CREATE  
FUNCTION does not see that the schema is concurrently being dropped.  
  
In both of these scenarios, the function is left behind in the schema  
that no longer exists.  
  
To fix, acquire AccessShareLock on all referenced objects when  
recording dependencies. This conflicts with the AccessExclusiveLock  
taken by DROP, preventing the race. After acquiring the lock, verify  
that the object still exists, and if it was dropped concurrently,  
report an error. We already had such a mechanism for shared  
dependencies, but for some reason we didn't do it for in-database  
dependendies.  
  
Ideally the locks would be acquired much earlier when creating a new  
object, but that will require modifying a lot of callers. This check  
while recording the dependency is a nice wholesale protection, and  
even if we change all the CREATE commands to acquire locks earlier,  
it's still good to have this as a backstop to catch any cases where we  
forgot to do so.  
  
The patch adds a few tests for some cases that left behind orphaned  
objects before this. It also adds a test for roles, which already had  
such protection, although that test is partially disabled because the  
error message includes an OID which is not predictable.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 14  

commit   : 36b6ed2606e18066ca1ae95d877aef8e98fad31d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:55 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:55 +0300    

When creating a relation with a dropped column, we called  
recordDependencyOn() also on the datatype of the dropped column, which  
is always InvalidOid. In versions 15 and above, that was harmless  
because recordDependencyOn() considers InvalidOid as a pinned object,  
and skips over it. On version 14, isPinnedObject() does not consider  
InvalidOid as pinned, so we created a bogus pg_depend entry with  
refobjectid == 0.  
  
As far as I can tell, the only case when AddNewAttributeTuples() is  
called with dropped columns is when performing a table-rewriting ALTER  
TABLE command. That temporarily creates a new relation with the same  
columns, including dropped ones, then swaps the relations, and drops  
the newly created table again. So even on version 14, the bogus  
pg_depend entry was only on the transient relation that was dropped at  
the end of the ALTER TABLE command, which was harmless.  
  
Even though this is harmless, let's be tidy, similar to commit  
713bce9484. The reason I noticed this now and why I backported this,  
is because the next commit will add code to acquire locks on the  
referenced objects, and we don't want to acquire a lock on InvalidOid.  
  
Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 14  

commit   : 2bb60eb4feab76ac5ea2ea6f15111b569ea48b62    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 11:49:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 11:49:50 +0300    

Commit 77dff5d937 introduced a SimpleLruWriteAll() call when replaying  
multixact WAL records generated by older minor versions. However,  
SimpleLruWriteAll() acquires the SLRU lock and on v16 and below, it's  
called while already holding the lock, leading to self-deadlock.  
Version 17 and 18 did not have that problem, because in those versions  
the lock is acquired later in the function.  
  
To fix, acquire MultiXactOffsetSLRULock later in RecordNewMultiXact(),  
at the same place where it's acquired on version 17 and 18.  
  
Author: Andrey Borodin <x4mmm@yandex-team.ru>  
Reported-by: Radim Marek <radim@boringsql.com>  
Discussion: https://www.postgresql.org/message-id/19490-9c59c6a583513b99@postgresql.org  
Backpatch-through: 14-16  

commit   : db4d12fc97ab2f4542092782fbcc934d584d0850    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 17:20:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 17:20:00 +0900    

DisownLatch() was executed after the PGPROC entry of the process  
terminated is pushed back into a freelist.  A newly-forked backend that  
recycles the slot could call OwnLatch() and PANIC with a "latch already  
owned by PID", taking down the server.  
  
There were two scenarios related to lock groups where this issue could  
be reached:  
* A follower pushes the leader's PGPROC back to the freelist while the  
leader has not yet called DisownLatch() in its own ProcKill().  
* A leader outliving all its followers pushes its own PGPROC onto the  
freelist before reaching DisownLatch(), which would be the most common  
scenario.  
  
This issue is fixed by calling SwitchBackToLocalLatch() and  
DisownLatch() at an earlier phase of ProcKill(), before any freelist  
manipulation happens, so that the slot of the backend terminated is  
never exposed as owning a latch.  
  
Note that pgstat_reset_wait_event_storage() is kept at a later stage.  
An upcoming commit will take advantage of that by introducing a test  
able to check the original PANIC scenario.  
  
Author: Vlad Lesin <vladlesin@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com  
Backpatch-through: 14  

commit   : 8007d118524a5d43568217341fab58b590930322    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 14:52:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 14:52:31 +0900    

This commit fixes two bugs in ProcKill()'s lock-group teardown freelist  
publication:  
* a double push of the leader's PGPROC that corrupts the freelist.  
* a leak of the last follower's PGPROC slot.  
  
ProcKill()'s lock-group teardown had two PGPROC freelist updates  
scattered through the function, done under two separate freeProcsLock  
acquisitions:  
* A follower's push of the leader's PGPROC, done when a follower is the  
last group member exiting.  
* Every backend's self-push at the bottom of the function.  
  
The two freelist updates were coordinated only by inspecting  
proc->lockGroupLeader, which a follower could clear as a side effect of  
pushing the leader.  This coordination was broken.  For example, with  
two concurrent backends:  
* The follower clears leader->lockGroupLeader and pushes the leader's  
PGPROC under leader_lwlock.  
* The follower does not clear its own proc->lockGroupLeader, being  
skipped.  
* When the leader reaches the bottom of ProcKill(), it sees a NULL  
proc->lockGroupLeader (the follower cleared it) and pushes itself,  
causing a second dlist_push_tail() of the same node onto the same  
freelist.  
* The follower at the bottom sees its own proc->lockGroupLeader being  
not NULL (never cleared) and skips its own push, causing its own slot  
to leak.  
  
This commit refactors the freelist manipulation to be done in two  
distinct phases, each step using its own lock acquisition to ensure that  
each freelist operation happens in an isolated manner for each backend  
(follower or leader):  
- First, under a single leader_lwlock acquisition, check the state of  
the lock-group.  Depending on if we are dealing with a follower and/or a  
leader, and if the leader has exited before a follower, then set some  
state booleans that define which actions should be taken with the  
freelist.  
- Second, under a single freeProcsLock acquisition, perform the cleanup  
actions, self-push of a backend and/or push of the leader back to the  
freelist.  
  
This is an old issue, dating back to 9.6 where parallel workers and lock  
grouping has been added.  
  
Author: Vlad Lesin <vladlesin@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com  
Backpatch-through: 14  

commit   : a96b051a98e346fe03f5fb27f21b539842295745    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2026 18:15:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2026 18:15:49 -0400    

Given a WHERE clause like "int[] @@ query_int" or "query_int ~~ int[]"  
where the query_int side is a table column having statistics,  
_int_matchsel() exited without remembering to free the statistics  
tuple.  This would typically lead to warnings about cache refcount  
leakage, like  
  WARNING:  resource was not closed: cache pg_statistic (73), tuple 42/12 has count 1  
It's been wrong since this code was added, in commit c6fbe6d6f.  
  
Bug: #19492  
Reported-by: Man Zeng <zengman@halodbtech.com>  
Author: Man Zeng <zengman@halodbtech.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19492-ddcd0e22399ef85a@postgresql.org  
Backpatch-through: 14  

commit   : 75710266732e049adc7fac6d885a3cba1474825b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 May 2026 14:39:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 May 2026 14:39:07 +0900    

The check for the minimum expected bytea size of a MVDependencies object  
was using SizeOfItem() for its calculation.  This macro uses the number  
of attributes in a single dependency.  
  
This minimum size calculation should be based on MinSizeOfItems(), that  
computes the minimum expected size as the header plus the  
minimally-sized number of dependency items.  
  
Oversight in d08c44f7a4ec.  
  
Author: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>  
Discussion: https://postgr.es/m/4b8d299d-2505-4c30-bf80-0f697410db35@tantorlabs.com  
Backpatch-through: 14