PostgreSQL 16.15 commit log

commit   : 7d3e000c5961a544302072058a1184e9a588837b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:56:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:56:00 -0400    

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

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

commit   : e849295075905ece6c1cba1bfddb1774ab5db8f7    
  
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   : 33d0c63fb345f6b06893610a4a19644dd2450262    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : ba2a63faffff826d3e2c25cf6396904fc8a4e2fd    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : 6ca6023ca0d94f94c4a30c5a23a5daec8b8882b0    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : ac450853d5d0694a9071504d588dd60e28209198    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : 2bdfd5cdcc09a04d281da6b731715016417f466e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : db96e87f93016930b9bc2cf5ec46188f27837e3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : f5f2da795b395449ca2970330bbdc88f8366bf68    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : 7a761fe408d51b43e42393c4b4fbcff9462229fa    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:25 -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   : 7ce056b1798b81a287ae00e2c06f210fd0e59be2    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 24855357c32faa0acfdc9da0a229d969d79ae124    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 61481aa0e4aa66c32a8826732f30d17d4c488d06    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 7d150b5c94ce04fbed318d75efec35c4fe4f6a92    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 4e1252ee56c33b8a1144b25b5803f47276662519    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 2cc14731825ec94017a3717e510f1f6780160c8a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : fadbe882d16112fd8c5ccf2b73eb9621dbfe130a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    

Presently, mock_scram_secret() always uses  
SCRAM_SHA_256_DEFAULT_ITERATIONS, which poses an observable  
response discrepancy hazard when scram_iterations is set to  
something else.  To fix, use the value of the configuration  
parameter instead, and document that unauthenticated users can  
discover the existence of roles with passwords created with  
different iteration counts.  
  
Reported-by: Radim Marek <radim@boringsql.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Jacob Champion <champion.p@gmail.com>  
Security: CVE-2026-14672  
Backpatch-through: 16  

commit   : 5e5ea74e389b0736adfc5aea3dd2ca102a997d65    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 39f855e0e6b461d41680552c40e7f3a3bfd4511f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 8bbdc054043af64add7ac4ec544efb1219d9901d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 24c88cd39d0174790b657bbaba88d557c09856b8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 7c3367ab5dc42c34788cf9a4c768d46d4acf1041    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:24 -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   : 7f308dd7ca11251a056444d66dd97a842e1b16b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 4c0c1b2cdf8d0702cca8de87e1ee87eb31aa1a4c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 32e0d25d4c7d2f5a0d3ffd3edaa6eafdde2e223e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 3299c2ba0cc5034d102eaf2f146e2794e00620e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 8c67c4cf59041a6ec2a1fa40e47b1490d75908bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 591192e2ec76922f847e39e01d4d4d3ababc5178    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 477a6bdb086106fb5b0bf5b87f01fffd8393d340    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 3179253c20e0e90398589d7dff9d8630bacb271c    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 84b6a7a06197600e8c9ea4f542066602c80fae4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : 7c1a8805a3ab9a8827621f833cbc4415adfcb9ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:23 -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   : ed3dcc92251d82d15a3eb5969df83ca8540eac8b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:20:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:20:36 +0200    

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

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

commit   : 894da35b3e8bfa81101e6946deefc12785ffac44    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:04 +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   : 636bcd6a56a84bec591961cbf1e773025607a4bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Aug 2026 14:23:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Aug 2026 14:23:38 +0900    

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

commit   : 36ae59dc995bf19b256e410711784ed94c9eedb8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Aug 2026 11:19:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Aug 2026 11:19:08 +0530    

Buildfarm member olingo intermittently failed this test, timing out while  
waiting for the subscriber log to report an ERROR because  
max_prepared_transactions is zero there. The test captured the log offset  
only after issuing the publisher's  
BEGIN/INSERT/PREPARE TRANSACTION/COMMIT PREPARED sequence.  
  
Since streaming is enabled, the subscriber can receive and apply the  
transaction, and log the expected ERROR, before that publisher SQL command  
even returns, i.e. before the test captures the offset. The subsequent  
wait_for_log() calls then searched only from a point after the message had  
already been written, and timed out waiting for it.  
  
Fix by moving the offset capture to before the publisher's transaction is  
issued, ensuring it always precedes the point where the ERROR can appear  
in the subscriber log.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where test was introduced  
Discussion: https://postgr.es/m/c43753d8-5265-4f77-83ff-9b1167276ec5@gmail.com  

commit   : b594efe52b4cbf952e63805078df4e28ff634c76    
  
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   : eb28b6f24b347985e61aa293bb4efc6c74a5765a    
  
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   : 34785a0d510321ab03a7ddb751341ca52bd21a04    
  
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   : 86f42357c281bea857dc5c048beb08413622bf3b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:01:10 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:01:10 +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   : b48a8cc0e50ad2cfa604ca89765b9fbec58b0717    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 16:10:39 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 16:10:39 +1200    

Fix missing NULL check in MemoryContextAllocAligned().  The underlying  
call to MemoryContextAllocExtended() could return NULL when  
flags contains MCXT_ALLOC_NO_OOM and the underlying malloc fails.  
  
There are no current callers using MemoryContextAllocAligned() that pass  
the MCXT_ALLOC_NO_OOM in core, so no live bug fix in core here. However,  
an extension might use this pattern, so we'd better fix.  
  
Fix this so we correctly pass the NULL to the caller rather than trying  
to write to a NULL memory address.  
  
This also fixes the same bug in AlignedAllocRealloc(), which is also  
unused in core.  
  
Backpatch to v16, where these functions first appeared.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/07DAC4C3-120D-4F3C-8FEE-BA236F7E9C1D@gmail.com  
Backpatch-through: 16  

commit   : e61d44fdee7e299dcbd4e168bda1e6670680aebc    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 3 Aug 2026 12:21:05 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 3 Aug 2026 12:21:05 -0700    

Commit 6566133c5f5 added a case for AuthMemRelationId in  
AcquireDeletionLock(), but not ReleaseDeletionLock(). The fall-through  
case would go to UnlockDatabaseObject(), which would raise a WARNING;  
and the lock would be retained until the end of the transaction.  
  
Add the missing branch.  
  
Discussion: https://postgr.es/m/2487ddcd737d4fc8e408e87aa9ad4365eed3bbb3.camel@j-davis.com  
Backpatch-through: 16  

commit   : d16728b01efc8a4c158f9bf1f5f85594a89ff8fe    
  
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   : 83336e3ed30b0d0b021900429e5bfde8367e2729    
  
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   : 444038bb78d5d5f950e9f9bd5166c4f79bc3d4c0    
  
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   : 796c275a018b778b0ff5b82a2eff87d7d75e6a7d    
  
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   : 9a0cd8e73f52307162f0c81e2d6e52c79f5592c3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:38:34 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:38:34 +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   : b7224a6e9427685455a8b7020c86ee7e332c26f2    
  
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   : 5dbeb69bcb0313f20731f43b682e04a663f39d27    
  
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   : 6fcee189bc5cd62d53b584fe2741723667ac44b0    
  
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   : 7446183463b45f0c9ec45ad1a9ad4cc08190218c    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:43 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:43 -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   : 6c760f6b6a3a8c1c49cdc54be62363af4308d62c    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 10:39:50 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 10:39:50 -0700    

pg_get_publication_tables() collects the OIDs of the published tables  
on its first call, without locking them, and then reopens each table  
later, once per result row, to compute its column list and fetch its  
row filter. The reopen used table_open(), which errors out with "could  
not open relation with OID" if the table has been dropped in the  
meantime. This could happen for any published table without an  
explicit column list, which is every table in FOR ALL TABLES and FOR  
TABLES IN SCHEMA publications, but also FOR TABLE entries without a  
column list. The failure is common in environments where many tables  
are created and dropped while publication tables are being queried,  
e.g. by table synchronization on a subscriber.  
  
Fix by opening every table with try_table_open(), which returns NULL  
if the relation no longer exists, and skipping the table in that  
case. Concurrently dropped tables are thus simply absent from the  
result set, which is the expected point-in-time behavior.  
  
As a side effect, tables with an explicit column list, which were  
previously returned without being opened, are now also locked with  
AccessShareLock, so the function can block behind concurrent DDL on  
such tables where it previously did not.  
  
Backpatch to v16, where we added the table_open() call in  
pg_get_publication_tables().  
  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Ajin Cherian <itsajin@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CALj2ACVYYooWH-5tJ6cPKkU%2BmutVxwb_z4S%2BqAi-zdrFqxXE2Q%40mail.gmail.com  
Backpatch-through: 16  

commit   : 006ac761e5080de9934fde8aac027d8c0ac82048    
  
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   : ac222bea5b46b0498a0807edba2d780e42f80ea1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:17 +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   : bc5a873a8ab34e7f5059d5611a0d8de05f51ad72    
  
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   : e321faaaef54cd1b93186046d4c98b43a59a8f1e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:28 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:28 -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   : 844bc718ac39c05c6b84ac72e95c5f2d80ad9f28    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 25 Jul 2026 19:09:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 25 Jul 2026 19:09:19 +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   : cbf2779e70bd18eaab0ccd2eea70bcf8edd37444    
  
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   : d610d8e8be5678f828e07aa99c16c1dcc2e4ef63    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 20 Jul 2026 12:13:11 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 20 Jul 2026 12:13:11 +0900    

Commit 1df9e8d96 made remove_useless_result_rtes() compute the set of  
baserels in the jointree, to pass down to the find_dependent_phvs()  
checks.  But those checks are no-ops when the query contains no PHVs,  
since find_dependent_phvs() and find_dependent_phvs_in_jointree() both  
return early in that case.  So we can avoid the  
get_relids_in_jointree() scan altogether when root->glob->lastPHId is  
zero, leaving baserels as NULL.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAMbWs49H275KzgZr3Cd1Hy+6Lmwp35bZ+5PrVc62k3HDLj6hNQ@mail.gmail.com  
Backpatch-through: 16  

commit   : 3e1fe25e686d788a32c926e2aa79bc8d9312841b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2026 14:09:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2026 14:09:10 -0400    

find_dependent_phvs() and find_dependent_phvs_in_jointree() decide  
whether a PlaceHolderVar depends on the RTE_RESULT rel we're  
considering removing by comparing the PHV's phrels to a singleton set  
containing that rel's RT index, reasoning that if phrels contains any  
other relid bits then those define an appropriate place where we can  
evaluate the PHV.  But since this code was originally written, we've  
redefined phrels to include outer-join relids, and that breaks this  
logic, potentially allowing us to remove an RTE_RESULT that leaves no  
valid place to evaluate the PHV.  The planner doesn't throw an error  
when that happens, but it does produce an incorrect plan that will not  
replace the PHV's value with NULL when needed.  
  
In the known test case for this bug, the "extra" OJ relid is one that  
we've actually decided to remove but haven't yet cleaned out of the  
query's PHVs.  It's not entirely clear though that that would always  
be the case.  Let's restore this code to the way it was designed to  
work, by considering only base relids within the PHV's phrels.  
  
Bug: #19553  
Reported-by: Viktor Leis <leis@in.tum.de>  
Author: Matheus Alcantara <matheusssilv97@gmail.com>  
Co-authored-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19553-4561747f93f368a7@postgresql.org  
Backpatch-through: 16  

commit   : e58192546f94c76bbecc545e2a941bec8c813ceb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:53:00 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:53:00 -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   : 42413e702913135efafa9180d0f101c455101ac5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 17 Jul 2026 11:23:18 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 17 Jul 2026 11:23:18 -0400    

Unfortunately the combination of gcc, precompiled headers, ccache and meson  
currently is not safe without further options. The dependencies emitted by gcc  
are insufficient to trigger rebuilds when headers "below" the precompiled  
headers are changed. Whether that's a ccache, gcc or meson bug is  
debatable. Luckily gcc's -fpch-deps option fixes the issue.  
  
This problem occasionally leads to build failures, e.g. if only c.h,  
postgres.h or pg_config_manual.h change. That's e.g. the case when creating a  
new major version branch.  
  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://postgr.es/m/CAN55FZ0tqR6Xz%3DiVFLc1BBoLOEHU775ARhcGYwggHA3XLA%3DoQg%40mail.gmail.com  
Discussion: https://postgr.es/m/CA+hUKG+s7Yvt0PUnSQUEjCjysV-7-51n9B1h468Le3VJi0x4ZQ@mail.gmail.com  
Discussion: https://postgr.es/m/phsrssp75npoyalqsolcd7fmnmlbzbmquc2p7w7mqjlw7432jk@bzskz3luyjvb  
Discussion: https://github.com/ccache/ccache/issues/1686  
Backpatch-through: 16, where meson support was added  

commit   : 44fc102c003f44e5238000c26a884e0e000c441e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:18:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:18:50 +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   : 656711398a6952b8d3258a337a06f85ec8dfabf6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:28 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:28 -0400    

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

commit   : d7bb9f643b374112cf806b40def8e3783493ebc2    
  
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   : daf029831d6b89e1a98f72aebcd5023759f6f3c9    
  
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   : 0fd5595aa3e71e54a297b18bc104f487c8555550    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 15:49:59 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 15:49:59 -0400    

When bulk-extending a relation, we add the newly-added blocks that we  
won't immediately use to the free space map and then call  
FreeSpaceMapVacuumRange() to propagate that free space up the FSM tree,  
so other backends can find and reuse it.  
  
However, the end block argument to FreeSpaceMapVacuumRange() is  
exclusive, and we passed the number of the last added block (since  
00d1e02be24). If that block was the first one covered by a new FSM page,  
its free space wasn't propagated up the tree and was therefore invisible  
to FSM searches until the next FSM vacuum.  
  
Fix by passing the block number one past the last added block, so the  
full range is vacuumed.  
  
Author: Jingtang Zhang <mrdrivingduck@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/flat/CAPsk3_Bx_vdybN%3D-DZu8HLStf%2BXnuFUBkLwxouONSMkWuO9oug%40mail.gmail.com  
Backpatch-through: 16  

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

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

commit   : ddce02d353f3b955287a833f13eef1abeb8d8200    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:43 +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   : 0bb484a7ec5cf7d73baaa7d0cf95f086b7188b3d    
  
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   : 56988064bcaf91c9526e2b42b19228fc48fff539    
  
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   : 6243ea6c34ac81ed97d9590f21587462eb50d330    
  
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   : 497d2ebbfb9a79f493ed43b1fe98853b05b45d63    
  
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   : 4eccaa8d23a249369e72443d9cfffd2cc3576ef6    
  
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   : 485527190a97f7eb57a1ce28e140d9e5f3f60f0a    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 08:50:14 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 08:50:14 +0900    

If an expression containing an aggregate is evaluated above the plan  
node that computes the aggregate, as happens with window functions or  
with expressions postponed to above the final sort, setrefs.c replaces  
the Aggref or WindowFunc with a Var referencing the lower node's  
output.  For SQL/JSON aggregates such as JSON_ARRAYAGG and  
JSON_OBJECTAGG, deparsing the containing JsonConstructorExpr then  
failed with "invalid JsonConstructorExpr underlying node type", since  
get_json_agg_constructor() did not expect a Var there.  
  
Fix by resolving the Var back to the underlying Aggref or WindowFunc  
and deparsing the constructor as if the aggregate were computed at the  
current node.  The JsonConstructorExpr retains the RETURNING clause  
and the ABSENT/NULL ON NULL and WITH UNIQUE options, and the arguments  
come from the resolved aggregate, so the original JSON aggregate  
syntax is reproduced in full.  This mirrors how get_agg_expr() already  
looks through such a Var when deparsing a combining aggregate.  
  
Reported-by: Thom Brown <thom@linux.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAA-aLv5QYTaMOk=Qhv6cgwceeHETZV8YJvWZ_rH+yVZCuchATA@mail.gmail.com  
Backpatch-through: 16  

commit   : 477bc27a593ffb929b5c44bc449ba1132a08f036    
  
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   : d3f329656cdceab148a0711aab266d91f4640be6    
  
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   : 0e93895f02c0d696d78eea610435d4fa8e3293e0    
  
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   : a857321625ec9ca9ef56a3c8f20a73a7c5dec17d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Jul 2026 00:00:03 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Jul 2026 00:00:03 +1200    

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

commit   : 6de480156ba00ea2b847d86f3127addb09209095    
  
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   : fffa4d870b70a30ccd799a71689cd2ece183c30c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2026 09:46:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2026 09:46:15 +0900    

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

commit   : a69503fb1e26ae95d90fd1b9ddfb57cdf2081a14    
  
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   : 0663382c9bf9aac58ccd1586c92f10eac794b191    
  
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   : cc3fe7e2a7471c541df7ff168bc41a3435f61fb0    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 3 Jul 2026 15:53:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 3 Jul 2026 15:53:03 +0300    

Commit ce146621 ensures that ERROR is raised if a session tries to read  
pages of another session's temp table.  But there is a corner case where  
the other session's temp table is empty -- in this case the INSERT  
command bypasses our checks and executes without any errors.  
  
Such behavior is inconsistent and erroneous: it leaves an invalid buffer  
in the temp buffers pool.  Since the buffer was created for another  
session's temp table, we get an error "no such file or directory" when  
trying to flush it.  
  
This commit fixes it by adding a RELATION_IS_OTHER_TEMP check in the  
relation-extension path.  
  
Backpatch to 16, because it is the first release after 31966b151e6, which  
introduced a separate local relation extension function  
ExtendBufferedRelLocal(), which lacks of RELATION_IS_OTHER_TEMP() check.  
As this fix introduces more checks to 013_temp_obj_multisession.pl, backpatch  
the whole test script to 16.  
  
Discussion: https://postgr.es/m/CAJDiXgiX2XZBHDNo%2BzBbvku%2BtchrUurvPRaN1_40mEQ1_sG90g%40mail.gmail.com  
Author: Daniil Davydov <3danissimo@gmail.com>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Imran Zaheer <imran.zhir@gmail.com>  
Reviewed-by: ZizhuanLiu X-MAN <44973863@qq.com>  
Backpatch-through: 16  

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

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

commit   : 82427eea4ddcfe906b1262469ac07aca63425ce5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 11:21:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2026 11:21:10 +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   : d569ccd408587b488cb33b8fdfb76341225fbbc2    
  
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   : 7cbd80340b4a2da9045eee7545f3583abf37a5ce    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Jul 2026 23:05:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Jul 2026 23:05:34 +0900    

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

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

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

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

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

commit   : 913d3b610ccdebe16178300327d0ba63d27d88a4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Jun 2026 08:51:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Jun 2026 08:51:51 +0900    

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

commit   : e92f23bde60ef53e1b3edf9fa78e651e69d76dd6    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 11:38:39 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Jun 2026 11:38:39 +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   : 3854f4afca68c57df1289f0852a9e4481e153100    
  
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   : 767142b8a8be1f181edbb8c97b826a1f6e7e0c13    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 16:52:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 16:52:18 +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   : e34b1ff5d89494810a870861505f1b29a731f1ce    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 07:59:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jun 2026 07:59:02 +0900    

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

commit   : 9951e3d382c6a2f9af1e397c178f5326edd05f35    
  
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   : e86b7a05fd0121a2e143b64b1b2bee28129351ff    
  
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   : 60a1d712a4726fdb44842fd06168715d8534b403    
  
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   : 6776978ce8ff8f6d17cdafeff0451889423e2357    
  
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   : 1daeef6e0db548f81543065a535ce1b3ec62fe26    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 18 Jun 2026 15:51:13 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 18 Jun 2026 15:51:13 +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   : 7c457ea15c6db282cf78a8d45d6d19c17ec432af    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2026 14:48:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2026 14:48:42 +0900    

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

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

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

commit   : b0f3465b6f6aff7809c54b2587d0a85ec4d8452f    
  
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   : 1316c166faf69d57d281d2d8939f5044fc841524    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Jun 2026 08:42:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Jun 2026 08:42:11 +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   : 813b0d8f455d38356a7c643e9c5170a185e2a21d    
  
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   : aca944e3378614bacd2eb6ceb20afab7c4892de9    
  
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   : 26d6c19d0f44355988176e3b9cb4342db0df87da    
  
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   : 9fc2f1995f53d05d53a38713dd564daa0a388b68    
  
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   : 82140a71dbf869ca2d7173af601f801cdd8b0044    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2026 12:22:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2026 12:22:55 -0400    

Late-model clang complains that these functions should be labeled  
with "format(printf, 2, 3)", and it's right.  But let's go a bit  
further and also make use of varargs, to remove duplication and  
allow these functions to be used with non-integer input values.  
  
Since no good deed goes unpunished, I had to also adjust a couple  
of call sites.  They weren't wrong as-is, since the size_t-sized  
arguments were coerced to int on the way into diag3().  But  
without that, we have to adjust the format strings.  
  
The point of this is to suppress compiler warnings, so back-patch  
into branches containing pg_bsd_indent, even though there's no  
functional change.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/1645041.1781283554@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 8d516d2b99b355bc1fb6b84f7dd0d5460c00c93f    
  
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   : f7fc53d938689668529c33f2830c066900a99082    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2026 11:37:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2026 11:37:58 +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   : cbca4d3a83d914a079662e45bb861a3bfd2432c2    
  
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   : c89a1ca01344b6015ab43904f88aef03ad965157    
  
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   : d266413293462334b12d387ca826a8d65c955691    
  
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   : 87df6e665edb3de2892293d4e84372b18cecbfd8    
  
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   : fb8befa7b57038ebdaaf6f15626ca62bdaaf1519    
  
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   : fac26fd41c06c85b8aa6ea27a884211dd9059b40    
  
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   : d9b49e5b4fc246d6f067f15b84c82086c0a74f1f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 11:44:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 11:44:19 +0900    

read_local_xlog_page_guts has the same race as logical_read_xlog_page:  
RecoveryInProgress() can return true during promotion, impacting the  
availability of the operations doing WAL page reads with this callback.  
  
This problem is similar to eb4e7224a1c6 that has addressed the issue for  
logical replication, impacting more areas of the code where this WAL  
page callback can be used (same narrow window during promotion, same  
availability issue):  
- pg_walinspect.  
- Slot advance (SQL function).  
- Slot creation.  
  
Repack workers (v19~) and 2PC files (since forever) can also use this  
callback, but they are irrelevant as far as I know.  A test is added  
with the SQL lookup functions.  This part relies on injection points,  
and is backpatched down to v18, like the test added for eb4e7224a1c6.  
  
This issue could probably be fixed as well in v14 and v15 for  
pg_walinspect.  However, I also feel that there is a conservative  
argument about consistency here due to the support of logical decoding  
on standbys, so let's limit ourselves to v16 for now.  pg_walinspect is  
used less in the field compared to the two other operations, making  
addressing this problem less attractive in these two older branches.  
  
Reported-by: Xuneng Zhou <xunengzhou@gmail.com>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/7daef094-abf3-4672-bc23-3df4763b16a3%40gmail.com  
Backpatch-through: 16  

commit   : eb6190f197f4d63b6842ee9a436803c870d22851    
  
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   : 1740766012e6432be639e0da98c5f4a917bfeafd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:53 +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   : 60abb3c7317586911606f35ac192a647a699ac12    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 11 Jun 2026 16:17:58 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 11 Jun 2026 16:17:58 +0200