PostgreSQL 18.5 commit log

commit   : 724edf9bde9d356724ad384a2e196edc3c9f80f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:38:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:38:31 -0400    

commit   : 841d0cb0f9b8b1b25e7b299ac0eb134074b45a08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:37:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Aug 2026 14:37:01 -0400    

Farewell, 18.5; we hardly knew ye.  

commit   : 5f003855e7f05bd03c5531a58838540f62b8b19e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 11 Aug 2026 21:18:45 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 11 Aug 2026 21:18:45 +0300    

Starting with commit 011384ba45, calling to_date() or to_timestamp()  
with "TMMonth" or other TM-prefixed format keyword, with the C locale,  
would crash.  
  
In REL_19_STABLE and above, pg_strupper(), pg_strlower(),  
pg_strtitle(), and pg_strfold() functions have a special case for the  
C locale, but that was missing in REL_18_STABLE.  On REL_18_STABLE,  
the functions call the libc function even in C locale, even though the  
native locale object is NULL.  On Linux, the underlying libc functions  
will crash when called with NULL locale.  (On macOS, they reportedly  
do not, but even then it's not clear if they will do what you'd  
expect.)  
  
This went unnoticed because until commit 011384ba45, we never called  
these functions in C locale, all the callers had a special codepath  
for C locale.  We could add a special path in the new callers too, but  
it's an accident waiting to happen, so let's backport the C  
locale-specific handling from REL_19_STABLE to REL_18_STABLE.  Older  
versions did not have these functions at all, hence no problem.  
  
This applies to REL_18_STABLE only.  
  
Reported-by: Masashi Kamura <kamura.masashi@fujitsu.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://www.postgresql.org/message-id/OS9PR01MB1317436E07D06281AD1A0452F94DD2%40OS9PR01MB13174.jpnprd01.prod.outlook.com  

commit   : 17fae4fbdd677b5a2e712734ed5ef21c052b68a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:52:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 16:52:29 -0400    

commit   : e35db2cd88da91391c55670d17e275085478f2de    
  
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   : cf6c2adec81358460d38ece9be9b9dbe0309927d    
  
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   : 71ca694c73cd1a808a393b2d5076e0518404468e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : 4c5128ca0b308c37a91ea7dcc4c10a98c672d592    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : fe32b10fca5342b9f86848a55288f6143b3afa04    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : 08e812c02ae14bbfb03d787884e4c6087419ecf7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : 29921259e83b613a14d71d8b26fd5d0419944297    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : 900894d35ca72bfba853447ca986bdced4ad993b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : 0b12f56bfac12e5930ee22071722082b0a45346b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:13 -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   : 57f59ca1d954f2de7ac3ef8971046778c955613a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 2780538433fc3b40b4e1e7bc7cbd350e37b6d550    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 2e91f8548daa7c7c7d5848f3812fac95fe9e9db5    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : e88eb4e766381070f42e5b84e583a1d0288983f7    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 37b8f3b0e05e85d4338f04c71caa156ba21d5015    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 2a29b607dbbba47c8e1c97458708e775bfa0e9bb    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 82fd688012954d8254b6e14ead997eb0e9223d86    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    

This is needed so that all versions of pg_upgrade that migrate logical  
replication slots can parse the new output_plugin_libraries GUC.  
  
Backpatch-through: 17  
Security: CVE-2026-6471  

commit   : 0a61fcde03257739d59d9b96e4c77f6c65e070e3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 822143c4d1dce62a43b98341eacbd4429eca7e59    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 0ddd9098a310ed711c6cba758c06dfe38f9654ff    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -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   : 08454e8b2defdf8a0b61e550606f78b8f184f2e6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:12 -0700    

statatt_get_type() unconditionally converted multirange types to their  
underlying range type.  This choice affected all the type information,  
like atttypid, atttyptype and operators.  
  
This made the bounds histogram work correctly (range type is required),  
but it was wrong for all the other stat kinds.  MCV values for a  
multirange column should be parsed as multirange arrays, not range  
arrays.  It also made the TYPTYPE_MULTIRANGE check for the range stats  
validation as dead code, since atttyptype was always TYPTYPE_RANGE  
after the conversion due to the centralized statatt_get_type().  
  
pg_restore_extended_stats() handles the same case correctly: it keeps  
the original type and explicitly converts to the range type only at the  
point where range_histogram_bounds is built.  
  
The fix of this issue is simple: the multirange-to-range conversion  
needs to be moved from the centralized statatt_get_type() up to where  
attribute stats build their range_histogram_bounds, matching what is  
done for extended statistics restore.  
  
The regression tests for multiranges with attribute stats are extended  
to cover this case.  
  
Author: OpenAI Security Research Team  
Backpatch-through: 18  
Security: CVE-2026-16238  

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

This commit adds a test for pg_restore_attribute_stats() with the  
injection of statistics related to a multirange type.  This case is  
supported in statatt_get_type() since its introduction in ce207d2a7901,  
but there was no test in the main regression test suite to check for the  
case where attribute stats is restored for a multirange type, as done by  
multirange_typanalyze().  
  
Note that this has been originally applied as d4504d6f60e0 in v19 and  
newer branches.  This will be used for the test of a follow-up commit.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CADkLM=c3JivzHNXLt-X_JicYknRYwLTiOCHOPiKagm2_vdrFUg@mail.gmail.com  
Security: CVE-2026-16238  
Backpatch-through: 18  

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

When a direct SSL connection was established, ProcessStartupPacket()  
still accepted GSSEncRequest messages.  The GSSAPI negotiation would  
then use raw writes and reads, bypassing the TLS encryption layer.  
After the GSS encryption was established, the connection continued to  
use TLS.  This could betray the HBA rules so as the backend does  
protocol exchanges inconsistent with the connection policies in place,  
with TLS taking priority over GSS in the backend.  
  
The SSL negotiation path already guarded against attempts to request  
SSL after a direct SSL request has been processed.  The GSS path is now  
guarded the same way when receiving a startup packet.  
  
Reported-by: p4p3r <kbfanta@naver.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Jacob Champion <champion.p@gmail.com>  
Backpatch-through: 17  
Security: CVE-2026-14681  

commit   : a14ba29b15a8b342808702e9da3e4a4532044f61    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 028ee716a7902bd2a68843a5d317a6821a0500e2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 849019a50a0ccbc7a7fe2ab3db53078ec2f99131    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 8a31ffc2d4cc5e2f3fb42b6a41b7db802716615d    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    

Since commit 62d712ecfd94, pg_stat_statements has been underestimating  
the size of the result buffer possible for a normalized query, in cases  
where the query includes many squashable lists, causing the normalized  
query to write past the allocated area.  
  
The allocated buffer size forgot to account for the comment appended in  
a squashable list, "/*, ... */".  Instead of trying to track down  
precisely how much space we need, fix by switch to using an expansible  
StringInfo.  This not only fixes the bug, but it also makes the code  
simpler to follow.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Sajeeb Lohani with TrendAI Zero Day Initiative  
Reported-by: Yuelin Wang <3020001251@tju.edu.cn>  
Diagnosed-by: Michaël Paquier <michael@paquier.xyz>  
Backpatch-through: 18  
Security: CVE-2026-14676  
Discussion: https://postgr.es/m/19528-7290dd7e6f7dcc22@postgresql.org  

commit   : a1fa24127d6a24611e5ec8e5b00584b333a3a06c    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 722695db18b6540a3757811436116f928c71b763    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 54649de65f0822ee0678cc2b2df6ad47de0a748e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 2a03f21daf59c6d00a01d553b75bb74448a9593d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 3392cce5c92ea4c84b8a5088b4717066fd280056    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 7f0e1aac7a7b54b6b575a3b4d6c90088dd90c38b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : a2cb5a1cfbae3c002f382ec22781c8f7c284f9d0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : 87c4b821972c9b66ced5520636c8ad4b60f8fd81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:11 -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   : b7e5c3f63464211f055d21f4f5196afa5905af8f    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 10 Aug 2026 06:38:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:10 -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   : dddc8a69ff8bde575ce950e9074439ccfd975336    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:10 -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   : e251350573e2ceb846b3b992f483d2d0de7a8a20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:10 -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   : 4fafe23805c4c75c2e85e8a0c1675fd17d92977b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2026 06:38:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2026 06:38:10 -0700    

While typical abbreviations are only a few bytes long, a user-supplied  
time_zone setting could specify a much longer abbreviation, enough to  
overflow to_char's allocation of 12 bytes per format character. If so,  
throw an error in the same style as commit 9241c84cb (CVE-2015-0241).  
  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Reported-by: Amjad Shahzad <amjadshahzad2000@gmail.com>  
Reported-by: Tan Zhen of AntAISecurityLab <TanZhen.AntAI@outlook.com>  
Reported-by: Tomer Fichman <tomer@irregular.com>  
Reported-by: Zheng Yu <zheng@depthfirst.com>  
Reported-by: Amy Burnett (OpenAI Codex Security)  
Reported-by: Rick de Jager <rick@v12.sh>  
Reported-by: Heewon Song <asteria121@78researchlab.com>  
Reported-by: Sylvie Mayer <smayer@cloudflare.com>  
Reported-by: Aleksander Alekseev <aleksander@tigerdata.com>  
Reported-by: Hillai Ben Sasson <hillai.bensasson@wiz.io>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-14669  

commit   : 3d3462a6d9c719591e2f130318bc3f00ba837e41    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:14:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2026 12:14:04 +0200    

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

commit   : a4c41bbcc7b0aed721950303338d75b09eddc295    
  
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   : 828d602f21156de916397b5df52397f18da7f759    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Aug 2026 13:11:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Aug 2026 13:11:52 -0400    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : 311e66df9cc857dcbb02024270f5130815682d63    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 8 Aug 2026 00:09:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 8 Aug 2026 00:09:05 +0900    

Commit b53b88109f9 made the postmaster maintain reachedConsistency in  
addition to the startup process.  Since the startup process is forked  
from the postmaster, it begins life holding whatever value the  
postmaster last set.  
  
On a crash reset the postmaster re-forks the startup process while its  
own copy still says true: it clears that copy only on receipt of  
PMSIGNAL_RECOVERY_STARTED, which the replacement process cannot send  
before it exists.  The replacement therefore starts out believing the  
database is already consistent.  
  
CheckRecoveryConsistency() then skips the minRecoveryPoint comparison  
altogether, so hot standby is announced at redo start while replay may  
be arbitrarily far behind minRecoveryPoint.  Read-only connections are  
accepted and answer from heap pages that were flushed ahead of the  
replay position, returning wrong results with no error raised.  The  
same branch also runs XLogCheckInvalidPages() and  
CheckTablespaceDirectory(), which are skipped as well, and  
log_invalid_page() treats page references that are normal before  
consistency as a PANIC.  
  
Fix by clearing reachedConsistency in InitWalRecovery(), so that a  
startup process never depends on the value it inherited.  The  
postmaster's own copy is deliberately left alone: forked backends read  
it to choose the "not yet accepting connections" errdetail, and it  
converges once the new startup process sends PMSIGNAL_RECOVERY_STARTED  
and, on reaching minRecoveryPoint, PMSIGNAL_RECOVERY_CONSISTENT.  
  
Successive crash resets alternate.  A startup process that skips the  
branch never sends PMSIGNAL_RECOVERY_CONSISTENT, so the postmaster's  
copy stays false and the next reset forks a process holding the correct  
value; that pass reaches consistency properly, which sets the  
postmaster's copy back to true and re-arms the problem for the reset  
after it.  Roughly every other crash reset is therefore affected, not  
just the first one.  EXEC_BACKEND builds are unaffected, as  
reachedConsistency is not carried in BackendParameters.  
  
Backpatch to v18, where commit b53b88109f9 introduced this issue.  
  
Reported-by: Eric Ridge <eebbrr@planetscale.com>  
Author: Nikhil Sontakke <nikhil@planetscale.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CA+UBoq2n2Zg9rKgMfUtUohzGssisF9cDeyjKqPrnRNFprEyX1Q@mail.gmail.com  
Backpatch-through: 18  

commit   : 7c25cdb1ebf64b1e1c9053ca27f9552c9a528a12    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Fri, 7 Aug 2026 09:59:55 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Fri, 7 Aug 2026 09:59:55 -0400    

112c2683807b4d690 restored failsafe vacuum's abandonment of a buffer  
access strategy by clearing the ReadBuffersOperations' strategy  
references. But it did so in lazy_scan_heap()'s main loop, meaning it  
looped through all the ReadBuffersOperations once per block after  
failsafe was engaged. Track it with a local flag and clear the strategy  
only once.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAAKRu_Zse14nSNeCgtnE1LUAH8Of7OmYR%2BCc3O_DAzxt3m6T-g%40mail.gmail.com  
Backpatch-through: 18  

commit   : 4ea497a9263efe17d809b844a8cc0c71e99f5cc4    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2026 17:30:02 +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   : 2fd8d45ecf7cee94613483f073c821b8834426c7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Aug 2026 14:23:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Aug 2026 14:23:35 +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   : 585181e077486324e12f6071a70955a0a48906aa    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 6 Aug 2026 17:16:23 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 6 Aug 2026 17:16:23 -0400    

VACUUM's wraparound failsafe mode exists to reclaim transaction IDs as  
quickly as possible. 4830f1024325 made the failsafe stop using the  
BAS_VACUUM buffer access strategy so that the rest of the vacuum could  
make use of all of shared buffers rather than being confined to the  
small strategy ring.  
  
However, when 9256822608f3 made vacuum's first heap pass use the read  
stream, this was accidentally disabled. The read stream keeps its own  
references to the buffer access strategy, so clearing vacrel->bstrategy  
in lazy_check_wraparound_failsafe() no longer had any effect on the  
reads issued by the first pass.  
  
Fix this by adding clearing the BufferAccessStrategy reference actually  
being used by the ongoing scan -- those in the ReadBuffersOperations  
structs themselves.  
  
Two things we accept rather than fix, as neither is worth the added  
complexity given how rarely failsafe mode is reached:  
  
- A small amount of read time for IOs that were already in progress when  
  the strategy was cleared may be attributed to IOCONTEXT_NORMAL instead  
  of IOCONTEXT_VACUUM. WaitReadBuffers() derives the IOContext from the  
  (now cleared) strategy, so the wait time of these in-flight IOs is  
  misattributed. This is bounded by the stream's look-ahead window and  
  happens at most once per vacuum, when the strategy is first cleared.  
  
- The stream's buffer pin limit stays lower than it would have been had  
  no strategy been used at all. max_pinned_buffers is capped by the  
  strategy's pin limit when the stream is created and is not recomputed  
  when the strategy is cleared. Raising it would mean building a new,  
  larger ring, which would require first waiting for all in-progress IOs  
  to complete. That didn't seem worth it.  
  
Reported-by: Jingtang Zhang <mrdrivingduck@gmail.com>  
Discussion: https://postgr.es/m/CAPsk3_APRYVLhAJ5TMwdmpSx8W_%3DPHMm%3DPmKAvnC3gBrfNommQ%40mail.gmail.com  
Backpatch-to: 18  

commit   : b37f14875a284b7bf3c5ec2e3691aa5d8bf8e736    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Aug 2026 11:26:57 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Aug 2026 11:26:57 +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   : ed8050370b7cf117dfb0de218695b1e003a51f36    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 5 Aug 2026 11:44:01 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 5 Aug 2026 11:44:01 -0400    

GetLocalPinLimit() and GetAdditionalLocalPinLimit(), currently in use  
only by the read stream, previously allowed a backend to pin all  
num_temp_buffers local buffers. This meant that the read stream could  
use every available local buffer for read-ahead, leaving none for other  
concurrent pin-holders.  
  
In 18, this was reported as a sequential scan of a temporary table  
failing with "no empty local buffer available": with  
effective_io_concurrency >= 64 and default io_combine_limit and  
temp_buffers, the scan's read stream budget,  
(effective_io_concurrency + 1) * io_combine_limit, meets or exceeds  
num_temp_buffers, so look-ahead could pin the entire local buffer pool.  
Any additional pin request made while returning tuples -- such as  
fetching TOASTed values from the table's (also temporary) TOAST table --  
then found no unpinned buffer to evict.  
  
Cap the local pin limit to num_temp_buffers / 4, providing some  
headroom. This doesn't guarantee that all needed pins will be available  
-- for example, a backend can still open more cursors than there are  
buffers -- but it makes it less likely that read-ahead will exhaust the  
pool.  
  
This is a backpatch of commit da6874635db, which was applied to master  
only during the 19 development cycle, where the issue surfaced as a  
regression test failure after on-access pruning began setting the  
visibility map. Reports of the failure above on 18 prompted  
backpatching it now.  
  
No backpatch to 17, even though its read stream also allows a single  
stream to pin the whole pool in principle. There, sequential scans pass  
READ_STREAM_SEQUENTIAL, which disables fadvise-based look-ahead, so the  
look-ahead distance cannot grow past io_combine_limit (at most 32  
buffers, versus a minimum temp_buffers of 100) and the reported failure  
is unreachable. The remaining theoretical paths require adversarial  
settings and have never been reported. Moreover, 17 predates these  
functions; the fix would have to be reimplemented in  
LimitAdditionalLocalPins(), making the change not a simple cherry-pick.  
  
Reported-by: Induja Sreekanthan <indujas@google.com>  
Reported-by: Eduard Stepanov <crtxcz@gmail.com>  
Reported-by: Feike Steenbergen <feikesteenbergen@gmail.com>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/97529f5a-ec10-46b1-ab50-4653126c6889%40gmail.com  
Discussion: https://postgr.es/m/flat/CAFMO8-rYPSJbXsDdWDzDdpNi-fQ%2B6bKvgbXwE%2BR%3DsGko4epq0Q%40mail.gmail.com  
Backpatch-through: 18  

commit   : 011384ba45fe193131f92c2d16c45f20d909301d    
  
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   : 13a9be148e530b9b5c0af2b499e3a08c1f5eb053    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 5 Aug 2026 11:36:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 5 Aug 2026 11:36:43 +0900    

Commit edee0c621de, and the equivalent v17 commit f2353dd71724,  
changed the runtime XID wraparound messages to use "transaction IDs"  
terminology, but one corresponding error example in maintenance.sgml  
still used the older XID wording.  
  
Update that documentation example in line with the current runtime  
message.  
  
Backpatch to v17, where the runtime messages were changed.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/CAHGQGwHTN-Xc5iDtbzNSjfxuab5Y9qAArw8cB4PrrDJpZ+1fgA@mail.gmail.com  
Backpatch-through: 17  

commit   : 19f0391df48202e2c6ac2e30a4c1c284aab5681b    
  
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   : 6b46a5d1b6164f2fdb15229dea9f3ed94ef20760    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 4 Aug 2026 17:03:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 4 Aug 2026 17:03:27 +0900    

Commit f6f0542266f0 changed getNotify(),  
getParameterStatus(), and related libpq message-processing paths to  
abandon the connection on out-of-memory errors.  
  
However, getCopyDataMessage() and pqFunctionCall3() did not handle  
this new fatal-error state. Both can process asynchronous  
NotificationResponse and ParameterStatus messages while waiting for  
other responses. If one of those messages triggered a fatal error, these  
loops continued processing instead of reporting it immediately.  
  
Fix this by checking for a saved fatal error after processing an  
asynchronous message. If the connection has been abandoned, return the  
appropriate error immediately instead of continuing to parse input.  
  
Backpatch to v18, where commit f6f0542266f0 introduced this issue.  
  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAO6_XqpGfm+XHE1OzS=_+jroeDOxhhGa11P3cbm9q2gT05yorA@mail.gmail.com  
Backpatch-through: 18  

commit   : c374f2807c236dd8fb4bee9f4ebfe4af300491f9    
  
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   : 6298a41b4e34773dbc0c50c26de825a4efe31f07    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:00:27 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 18:00:27 +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   : bf048f0e17a1ea82dc22c8ad446d14670b52451c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 16:09:55 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 4 Aug 2026 16:09:55 +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   : a0daa0b4127dffe99a92c6606ad778f89ec3239f    
  
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   : 9a8c9338377c397714bb2cc44b46a430dce5bdfe    
  
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   : d04a24d9ead0d47f772d5a416813259af5a36e98    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 3 Aug 2026 13:52:41 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 3 Aug 2026 13:52:41 +0200    

The is_valid parameter was never referenced in the function body, and  
the 'thisatt' local variable is set but never used.  Remove both.  
  
Oversight in a379061a22a8.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAA5RZ0tHnvSrfUy4jWJchjvkL_aJe0hCnZpMsFRdLrSxCne5qQ@mail.gmail.com  

commit   : 81b1e79166a524b95628f8d459571f1b029fe19e    
  
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   : 4689ea9ceee362efe2569cd3b0e5c7072a8a24bc    
  
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   : 5f67124fa43448702acc0f9448e0ad118fe5e791    
  
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   : 74169d3a1d695556ad81ef7a9c256daf0d554da1    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 31 Jul 2026 11:19:44 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 31 Jul 2026 11:19:44 -0700    

The slow_down interval parsing code checks explicitly for overflow, but  
since it does that after the signed overflow has already occurred, we  
end up inviting undefined behavior from the compiler anyway.  
  
Use checked arithmetic instead. set_timer() takes a long int in order to  
interface nicely with libcurl, so use an int32 as the interval counter  
and clamp to LONG_MAX during conversion to milliseconds.  
  
Backpatch to 18, where libpq-oauth was introduced.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/qtclihmrkq67ach3xjxyi4qcksstin5qxwsnkqefkmotxwh4g6%40ae2bj6jvcmry  
Backpatch-through: 18  

commit   : fff8c86759659a070e014ffd7295e93a11a1479c    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 31 Jul 2026 11:19:37 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 31 Jul 2026 11:19:37 -0700    

(This is a late cherry-pick of 4e1e41733, now that the new suite has  
proven its stability, to ensure coverage for this code in PG18 as the  
later branches diverge.)  
  
To better record the internal behaviors of oauth-curl.c, add a unit test  
suite for the socket and timer handling code. This is all based on TAP  
and driven by our existing Test::More infrastructure.  
  
This commit is a replay of 1443b6c0e, which was reverted due to  
buildfarm failures. Compared with that, this version protects the build  
targets in the Makefile with a with_libcurl conditional, and it tweaks  
the code style in 001_oauth.pl.  
  
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://postgr.es/m/CAOYmi+nDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA@mail.gmail.com  
Discussion: https://postgr.es/m/CAOYmi+m=xY0P_uAzAP_884uF-GhQ3wrineGwc9AEnb6fYxVqVQ@mail.gmail.com  

commit   : 18f0de6b885a017dfba620e0b9a5f42a1bc16d25    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Jul 2026 11:57:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Jul 2026 11:57:07 -0400    

As previously coded, walsummarizer only wants to read WAL from a file  
where the TimeLineID in the filename exactly matches the TimeLineID being  
summarized. But in some cases, when a timeline switch occurs, the WAL file  
from the old timeline is not archived, because it's never completely  
filled, so the only way to obtain the contents of that last partial  
segment is to read from the first segment on the new timeline. Teach  
WAL summarizer to do that, and add a test case to make sure that it  
works.  
  
Reported-by: Nick Ivanov <nick.ivanov@enterprisedb.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Tested-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Thom Brown <thom@linux.com>  
Discussion: http://postgr.es/m/CA+Tgmobr27GpKDZx3_ezW2+C5_g18i+jSK3sGF_cR-_ESv5N5A@mail.gmail.com  
Backpatch-through: 17  

commit   : 4cc49cb70396e5a0941eabbe9b23f9c4a3b85c3a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 31 Jul 2026 10:34:40 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 31 Jul 2026 10:34:40 -0500    

When db_comparator() was updated to use pg_cmp_s32(), the arguments  
were listed in the wrong order.  This caused autovacuum to sort the  
databases by their scores in ascending order instead of descending  
order.  To fix, swap the arguments to pg_cmp_s32().  
  
Oversight in commit 3b42bdb471.  
  
Reported-by: Хамидуллин Рустам <r.khamidullin@postgrespro.ru>  
Author: Хамидуллин Рустам <r.khamidullin@postgrespro.ru>  
Discussion: https://postgr.es/m/5c5a7984-b149-b505-7ad9-2a7766c65b55%40postgrespro.ru  
Backpatch-through: 17  

commit   : f70acc8a2b96e0b565836799b6ccc3bacba8068a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 23:24:46 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 23:24:46 +1200    

adf97c156 allowed expression evaluation to perform hashing, and  
subsequently 9ca67658d fixed a memory stomping bug in that commit  
that caused unrelated-to-hashing expression op steps to stomp on the  
intermediate hash value.  The intermediate hash value needs to be  
maintained when hashing multiple hash keys.  9ca67658d didn't quite get  
things right when in "strict" mode when it aborted hashing early after  
encountering a NULL hash key.  What was meant to happen was that the  
expression returns NULL directly to indicate to the caller the value  
hashed to NULL.  The problem was that any EEOP_HASHDATUM_FIRST_STRICT or  
EEOP_HASHDATUM_NEXT32_STRICT op step that didn't belong to the final  
key to be hashed would have its op->resnull and op->resvalue pointing to  
the location to store the intermediate hash value.  That's correct for  
non-NULLs since we bit-rotate the intermediate value and continue hashing,  
but with the strict case, when we get a NULL key, we immediately jump to  
the "jumpdone" step.  The problem is the jumpdone step expects the  
ExprState resnull and resvalue fields to be set (as they would be if we  
didn't abort hashing early due to the NULL), but when we aborted early,  
the ExprState fields never got set.  This would result in inserting  
records into the hash table that would never match to any join partner,  
which is a waste of CPU and memory.  
  
Here we fix this by having EEOP_HASHDATUM_FIRST_STRICT and  
EEOP_HASHDATUM_NEXT32_STRICT populate the ExprState resnull and resvalue  
fields directly when the value to hash is NULL.  
  
Although Hash Agg and Hashed Subplans do use hashing from ExprStates,  
those were unaffected by this bug, as neither of those uses the STRICT op  
steps.  
  
Thanks to Tomas Vondra for finding the offending commit.  
  
Reported-by: Dan Stefura <dstefura@bluecatnetworks.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/YQBPR0101MB89738FB972FBD02A3640C6D3D6C92@YQBPR0101MB8973.CANPRD01.PROD.OUTLOOK.COM  
Backpatch-through: 18  

commit   : 02e69be47c05c10c8ee8ac5d7634a4048c037ebc    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:37:42 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Jul 2026 15:37:42 +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   : a0369dd8448fba99d22068f533764bf2fb001278    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 Jul 2026 15:30:19 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 Jul 2026 15:30:19 +0200    

When restoring relation stats, pg_restore_relation_stats() rejected  
calls with (reltuples < -1.0). But that is insufficient - Infinity and  
NaN values both pass that check, and get stored in pg_class verbatim.  
This can have various undesirable consequences.  
  
Fixed by rejecting non-finite reltuple values, in the same non-fatal way  
as for the existing checks (emit WARNING and skip the update). Adds a  
regression test to stats_import for these non-finite values, and to  
check the -1.0 special value is still accepted.  
  
Backpatch to 18, where pg_restore_relation_stats() was introduced.  
  
Patch by Jan Nidzwetzki, minor commit message tweaks by me.  
  
Author: Jan Nidzwetzki <jan@planetscale.com>  
Discussion: https://postgr.es/m/518BA772-8026-412A-AA8F-A7FE4C6B3717@planetscale.com  
Backpatch-through: 18  

commit   : d4420a97206cad5bcf63405062db5b4ebaa7f2b1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 Jul 2026 14:06:20 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 Jul 2026 14:06:20 +0200    

Index builds update pg_class.reltuples for the table. In parallel GIN  
builds, workers track the number of processed rows, and report it to  
the leader, who then updates the pg_class with a total. However,  
gin_parallel_build_main failed to initialize the bs_reltuples field,  
leaving it set to whatever happens to be on the stack (which may be  
bogus values like Infinity or NaN, or just impossibly high values).  
  
If such values get reported to the leader and stored in pg_class, that  
can have serious consequences. The pg_class.reltuples field is used to  
decide when a table is due for autovacuum or autoanalyze, and if it  
happens to be set to a bogus value, that may never happen. The field is  
also used by the optimizer when calculating costs.  
  
Fixed by initializing bs_reltuples together with the rest of the build  
state. The bs_numtuples was initialized later, but it seems cleaner to  
just initialize all the fields at once.  
  
After a bogus value gets persisted in pg_class, affected systems are  
unlikely to self-heal. That would require an ANALYZE, but preventing  
that is one of the consequences. We have considered forcing autoanalyze  
in these cases, but there's not a good way to reliably identify bogus  
values (except for a small minority like Infitiny/NaN).  
  
A manual ANALYZE on (possibly) affected tables is the only solution.  
  
Backpatch to 18, where parallel GIN builds were introduced.  
  
Reported-by: Jan Nidzwetzki <jan@planetscale.com>  
Discussion: https://postgr.es/m/518BA772-8026-412A-AA8F-A7FE4C6B3717@planetscale.com  
Backpatch-through: 18  

commit   : 0abdb3e3610e171993e2951523a2d11284c23b7d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 30 Jul 2026 11:25:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 30 Jul 2026 11:25:12 +0530    

pg_dump in --binary-upgrade mode emits "SUBSCRIPTION TABLE" TOC entries to  
preserve pg_subscription_rel state across pg_upgrade.  When such a dump  
was restored with --no-subscriptions, _tocEntryRequired() skipped the  
"SUBSCRIPTION" entry but not the associated "SUBSCRIPTION TABLE" entries,  
so the restore would try to apply subscription-relation state for a  
subscription that was never created.  
  
Skip "SUBSCRIPTION TABLE" entries as well when no_subscriptions is set.  
  
This can happen when pg_subscription_rel has entries, the dump is taken  
with --binary-upgrade, and it is restored with --no-subscriptions.  
  
Reported-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/OS9PR01MB121493DA4C1A7748B11A646D8F5C02@OS9PR01MB12149.jpnprd01.prod.outlook.com  

commit   : 050e9d94d81bb1f6f5b34cb7794f201611fc9afa    
  
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   : 33101632235ad064b2bd7bc04a5066048dc48023    
  
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   : 277122036c3382c5ab47034a180fde1176728c43    
  
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   : b563fc6bd926fd9dca86d0c1a16fbf2e3e63dee9    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:35 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 12:33:35 -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   : 73d63d1c1f676f4fcb289cdf9d052881719eb02f    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 10:39:43 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 28 Jul 2026 10:39:43 -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   : 7becb647da743fc3ca059181fef94419cd8167d6    
  
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   : e4527519b77e0f158e452fcbbcb2ac902d01ad44    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Jul 2026 08:35:12 +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   : d560e730e813343b8d3f4a336244f2bc09ca84fc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:32 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Jul 2026 12:01:32 -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   : f2d6cf880240b1dcbb8791c2687b017bff23b156    
  
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   : bb0a3ca8d218b6c0792235d7306117e5bc36294a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jul 2026 14:37:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jul 2026 14:37:44 +0900    

injection_wait() only clears its slot in the waiter array after the  
wait loop finishes.  When the waiting query is canceled or the backend  
is terminated (wait look has a CHECK_FOR_INTERRUPS), the slot leaks.  
Later wakeups of the same point then bump the counter of the leaked slot  
instead of the real waiter, that sleeps forever.  Repeated leaks can  
exhaust all the slots.  
  
The code is changed so as the waiting loop is wrapped with  
PG_ENSURE_ERROR_CLEANUP, so as the injection point slots, that are  
shared resources, can be cleaned up on ERROR as much as a FATAL.  
  
An isolation test is added: cancel one waiter, terminate another waiter,  
then check that a later waiter still receives a wakeup.  Without the  
fixed code, the test would fail on timeout.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Discussion: https://postgr.es/m/CAN4CZFO+KF=cc0-iEg28RhqRBp_fTs6D4b8b7D7DB-pGYP3Ccg@mail.gmail.com  
Backpatch-through: 17  

commit   : 1d299d6abfcdcd9400dd1e14b4213a9f39e41691    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 22 Jul 2026 08:47:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 22 Jul 2026 08:47:44 -0400    

SummarizeWAL documents that maximum_lsn should be passed as "the switch  
point when reading a historic timeline, or the most-recently-measured end of  
WAL when reading the current timeline." But the caller always passed the  
most recently measured end-of-WAL even when reading from a historic  
timeline, due to an oversight on my part. Fix that.  
  
As far as I can determine, for this to become an issue in practice, it's  
necessary to have a corrupted WAL file in the archive.  SummarizeWAL checks  
that every record it processes both starts and ends before switch_lsn; so if  
all the WAL files in the archive are valid, SummarizeWAL will still discover  
where it should stop summarizing and do the right thing.  However, if  
there's a corrupted file in the WAL archive, and if it is also the case that  
the end of the current timeline has advanced past the switch point, then the  
incorrect maximum_lsn value can result in trying to read an invalid record  
and erroring out, which leads repeatedly retrying and failing with an error  
every time.  
  
One way this could occur is if a new primary is promoted and creates a  
.partial file, and the user manually renames that file to remove the suffix,  
and it is then archived. In that situation, the tail end of the file need  
not be valid WAL, and that could lead to a stuck WAL summarizer.  
  
Reported-by: Fabrice Chapuis <fabrice636861@gmail.com>  
Analyzed-by: Thom Brown <thom@linux.com> (using claude)  
Discussion: http://postgr.es/m/CAA5-nLDdvGMkN6Z-GaHGHG5T7QWEgv4YoHO7XvOJbeD00cghNg@mail.gmail.com  
Backpatch-through: 17  

commit   : 545e2a9d74c3ccca3189e56a515a5793b782eb9b    
  
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   : 19e3aa704126f34f8fa4b36109478a7e6727a5e5    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 20 Jul 2026 17:21:20 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 20 Jul 2026 17:21:20 +0200    

Commit 8c852ba9a4 allowed exclusion constraints to be added to  
partitioned tables, but wasn't careful to verify that pg_restore worked  
correctly for them.  Fix that by making CompareIndexInfo() more  
selective about what needs to be rejected.  
  
Author: Japin Li <japinli@hotmail.com>  
Reported-by: Keith Paskett <keith.paskett@logansw.com>  
Discussion: https://postgr.es/m/2A40921D-83AB-411E-ADA6-7E509A46F1E4@logansw.com  

commit   : 9e40d07e140bc21186a8bdd1cb8b35d4d5f65979    
  
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   : 21f5e659e7587abf640f9c4aaff2238e3c3ff683    
  
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   : 959b7fa2cd603ec353aaef715993d0f0816febd2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:53:05 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2026 15:53:05 -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   : 125893ce83b8218db8446f5f6f416cdbf9e80f7b    
  
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   : aa572d521a1116b2c8902b98f44baf402a3e5246    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:33:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:33:16 +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   : 8af1f527842170a257ae0684dd02907135d8d2e5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:33 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:33 -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   : c31b0fca059cf081679be1689b59b21912b0d29e    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 11:50:13 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 11:50:13 -0700    

uuidv7(interval) shifts the current time by the given interval before  
encoding it into the 48-bit Unix-millisecond timestamp field of the  
generated UUID. Two cases were mishandled:  
  
An infinite interval ('infinity' or '-infinity') produced an infinite  
timestamp, which overflowed during the conversion to Unix-epoch  
microseconds and yielded a garbage UUID. Reject infinite intervals up  
front, before any timestamp arithmetic.  
  
A shift that moved the timestamp outside the range representable by  
the 48-bit field was silently accepted. Timestamps before the Unix  
epoch wrapped when cast to unsigned, and timestamps beyond  
approximately year 10889 overflowed the field; both produced UUIDs  
with bogus timestamps that break sort ordering. Reject any shifted  
timestamp outside the supported range.  
  
Also document that infinite intervals and out-of-range shifts are  
rejected.  
  
Although raising a new error changes behavior in a stable branch, this  
is back-patched to 18 (where uuidv7(interval) was introduced) because  
the previous behavior can silently corrupt data. Failing loudly is far  
safer than silently accepting the wraparound; otherwise users may not  
discover that their UUIDv7 values are no longer sortable until years  
later, when recovery is painful. It also matches how PostgreSQL  
already handles timestamp + interval overflow, which raises an  
error. The change only affects applications passing an interval large  
enough to push the result outside the representable range.  
  
Backpatch to 18, where uuidv7(interval) was introduced.  
  
Reported-by: Christophe Pettus <xof@thebuild.com>  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/799A70FA-6E5C-4118-99EB-2FBBE1CBAC54@thebuild.com  
Backpatch-through: 18  

commit   : a00e43ac32d4f7367567791a68b2cf815f8c4d3f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 00:49:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 00:49:26 +0900    

The regression test for postgres_fdw_get_connections(true) assumed that  
a terminated remote connection would still remain visible in the FDW  
connection cache long enough to be reported as closed with a nonzero  
remote_backend_pid.  
  
That assumption is not always valid. postgres_fdw_get_connections()  
reports only entries that are still present in ConnectionHash, while  
pgfdw_inval_callback() may immediately discard an idle cached connection  
(xact_depth == 0) when a relevant invalidation arrives. In CI, that can  
happen between terminating the remote backend and querying  
postgres_fdw_get_connections(true), causing the function to return no  
rows.  
  
Adjust the idle-connection test to accept either outcome: if the cache  
entry is still present, verify that it reports the expected server name,  
closed status, and nonzero remote backend PID; otherwise treat zero rows  
as a legitimate result.  
  
To preserve coverage of the terminated-backend reporting path, add a  
separate check inside an explicit transaction. In that case, concurrent  
invalidation may mark the connection invalid but cannot discard it  
before transaction end, so postgres_fdw_get_connections(true) should  
still report the terminated connection as in-use, closed, and associated  
with a nonzero remote backend PID.  
  
Backpatch to v18, where the affected postgres_fdw_get_connections(true)  
test was introduced.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA+Tgmoax3cHXHsm9OidN4F-xiu16y8q2W8T5dTNFic1Zoo2cOw@mail.gmail.com  
Backpatch-through: 18  

commit   : 30c0442eb308cdb9a0d1b8551758775ec4d0e75d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 16 Jul 2026 16:05:36 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 16 Jul 2026 16:05:36 +0200    

Commit 67846550dc6d removed the xreflabels for initdb options, which  
turned the sentence "The second field contains the page checksum if  
data checksums are enabled" into "The second field contains the page  
checksum if -k are enabled", as well "Only has effect if data checksums  
are enabled" into "Only has effect if -k are enabled".  
  
Fix by setting an explicit link text, and while there also change the  
link to point to the data checksum page which has more information  
than just the initdb option.  
  
The original report was for one instance, further inspection turned  
up quite a few more cases.  Also redirect the link in the amcheck  
docs which albeit was reading right, but will be more helpful if  
linking to the main page on data checksums.  Backpatch to v18 where  
the xreflabels were removed.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: y.saburov@gmail.com  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/178350739237.73862.4549076173872335741@wrigleys.postgresql.org  
Backpatch-through: 18  

commit   : a6a2eb9f602490ca215371ba2497b07efccaace7    
  
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   : 4a4d6d1d1d997cb46b2931abb99a1a67e59cf5ca    
  
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   : 4d7feebfbd2f4ed84f95912be12225749ddf6e76    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:37:34 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:37:34 -0400    

The WAL summarizer only tracks registered buffers, so unregistered VM  
clears are ommitted from incremental backups, corrupting the restored  
visibility map. Test those cases are now fixed.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/oqcsevg35xjan2327x5kdfth6q4fgeqboxfo3v3imeyih2uiny%406sez5dzxl6nt  
Backpatch-through: 17  

commit   : f581fa729d8e108fef853c3156267b1f753d0210    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:37:34 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:37:34 -0400    

Heap WAL records that clear bits on the visibility map (like inserts and  
deletes) did not register the visibility map blocks they modified.  
Because the WAL summarizer only records registered blocks, an  
incremental backup taken over such operations would omit the changed VM  
pages. On restore, the VM would retain stale all-visible/all-frozen  
bits, which can cause wrong results from index-only scans and incorrect  
relfrozenxid advancement due to vacuum page skipping.  
  
Not registering the VM buffer also meant we never emitted FPIs of VM  
pages when clearing bits. A torn VM page won't raise an error because  
the VM is read with ZERO_ON_ERROR; with checksums on, it would be  
detected and zeroed, but with checksums off, it is accepted as-is and  
can lead to data corruption.  
  
Fix this by registering the VM buffer in the WAL record when clearing VM  
bits. The VM buffer must now be locked throughout the critical section  
that modifies the VM and heap pages and emits the WAL record. This can  
slow down operations that clear the VM, since the VM lock is held longer  
and VM FPIs may be emitted, but it is required for correctness.  
  
Note that this fix does not repair existing incremental backups.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/flat/CAAKRu_bn%2Be7F4yPFBgFbnP%2BsyJRKyNK092bjD2LKvZW7O4Svag>  
Backpatch-through: 17  

commit   : d0fb1da21bbcc7bdf13632cd080628757cd008e3    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:37:34 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:37:34 -0400    

When registering a buffer with the WAL machinery, the caller assigns it a  
block reference ID, and replay must read each block back by that same ID.  
Today these IDs are bare integers assigned by convention (0, 1, 2, ...),  
which is easy to follow when a record registers a single block, or when the  
blocks are handled during replay in their registration order.  
  
An upcoming bug fix registers up to two visibility map blocks in addition  
to the heap block(s) when clearing the VM, and these are not handled during  
replay in a straightforward 1:1, in-registration-order fashion. Relying on  
bare integers for the block IDs in that case is error-prone.  
  
Introduce macros naming the block reference IDs for the heap record types  
that the upcoming commit extends to register visibility map blocks, so the  
registration and replay sites refer to the same block by a meaningful name.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/66mqpfyti3qhfttcsv6r2lbvqqd32rrmpn6i47ovrsnvguts46%40gou54xc>  
Backpatch through: 17  

commit   : eabc9a9dd908a1be7d66dc26b378b1488fd14847    
  
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   : a1b962b366210ab8d8d220582ad1c32620f35935    
  
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   : bcc428a23a69ee6f3bcc2ce20655da68eed0e7aa    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jul 2026 13:04:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jul 2026 13:04:32 -0400    

Code elsewhere in the system assumes that fork numbers and chunk sizes  
are within bounds, so the code that reads those quantities from disk  
should validate that they are. Without these additional checks, a  
corrupted file can cause us to index off the end of fork number or chunk  
entry arrays, potentially resulting in a crash.  
  
Reported-by: oxsignal <awo@kakao.com> (chunk sizes)  
Reported-by: Robert Haas <rhaas@postgresql.org> (fork numbers)  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: http://postgr.es/m/CA+TgmoYP8RKoBGosS7C6Fdr-GNCfyz_W1zmK=Tx1Fe0ZvzGh0g@mail.gmail.com  
Backpatch-through: 17  

commit   : ae8c4bd558c5d55c5a357e910d496eea8ff33647    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Jul 2026 21:22:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Jul 2026 21:22:38 +0900    

pg_clear_attribute_stats() checks its required arguments manually  
because the function is not strict. Previously, when schemaname or  
relname was passed as NULL, the error incorrectly reported the  
argument name as "relation" in both cases:  
  
    ERROR:  argument "relation" must not be null  
  
This was misleading, especially for schemaname, and inconsistent with  
the function's SQL-visible argument names.  
  
The cause is that cleararginfo[] in attribute_stats.c used  
"relation" for both the schema-name and relation-name arguments.  
  
This commit fixes the issue by using "schemaname" and "relname" instead,  
matching the function's declared argument names so that the error reports  
the correct argument name.  
  
Backpatch to v18, where pg_clear_attribute_stats() was introduced.  
  
Author: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/4bf66c5e-8dd7-4ef3-8691-db67ecff6f16@tantorlabs.com  
Backpatch-through: 18  

commit   : 36c6b499761878d40fd5f62b698546374a8aa5bc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:39 +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   : 18105e6db5e5314a575fdb23a99cf4809d8ef062    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 15 Jul 2026 09:22:58 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 15 Jul 2026 09:22:58 +0900    

Commit 9a60f295b stripped the stale PlaceHolderVars left behind by  
left-join removal from the surviving rels' baserestrictinfo and from  
EquivalenceClass member expressions, but it overlooked join clauses.  
A PlaceHolderVar embedded in a join clause can likewise retain the  
removed rel and join in its phrels, since remove_rel_from_query()  
fixes up the RestrictInfo's own relid sets but not the PHVs inside its  
expression.  
  
As before, this is normally harmless, because later processing  
consults those relid sets rather than the embedded PHVs.  However, a  
restriction clause derived from such an OR join clause inherits the  
stale PlaceHolderVar, and when the derived clause is translated for an  
appendrel child, pull_varnos() recomputes its relids and folds the  
removed relation back in.  The rebuilt clause then references a  
no-longer-existent relation, tripping an assertion during path  
generation.  
  
Fix by also stripping the removed relation from the PlaceHolderVars in  
the surviving rels' join clauses, including the sub-clauses of any OR  
clause.  
  
Like 9a60f295b, this is only reachable on v18 and later, where  
match_index_to_operand() began ignoring PlaceHolderVars.  
  
Author: Arne Roland <arne.roland@malkut.net>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/27a44087-3d65-473e-8d88-7c12228e0d7e@malkut.net  
Backpatch-through: 18  

commit   : d1d9688b1f92590110cb868ce4f65f39da0af2a8    
  
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   : 87c3a79ea206410f34f326eb63c36d8679edeb8b    
  
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   : 27761c0151b3b9b57e58597fa027a26619c9608e    
  
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   : 4908225bebdc31c9b8f735ad1db3d08d9bc85148    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 8 Jul 2026 20:46:26 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 8 Jul 2026 20:46:26 +0100    

When executing an UPDATE with a RETURNING clause on a table with a  
BEFORE UPDATE row trigger, the computation of the OLD values in the  
RETURNING list was incorrect if the target tuple was concurrently  
updated by another session, at isolation level READ COMMITTED.  
  
The problem was that the trigger code would lock the target tuple,  
waiting for the other session to commit, and then fetch the updated  
target tuple, but ExecUpdate() would not realise that the target tuple  
had changed, and use the outdated target tuple for computing OLD  
values. Fix by having ExecUpdate() check the TM_FailureData from  
trigger execution and re-fetch the target tuple if necessary.  
  
Re-fetching the target tuple like this is a little inefficient, but  
probably negligible compared to the trigger execution and update. A  
better long-term fix might be to move the EPQ code out of trigger.c,  
and let ExecUpdate() handle it, like ExecMergeMatched() does, but that  
would likely mean changing the trigger API, which seems a bit much for  
back-patching.  
  
Backpatch to v18, where support for RETURNING OLD/NEW was added.  
  
Bug: #19536  
Reported-by: Jonas Boberg <bobergj@gmail.com>  
Diagnosed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://postgr.es/m/19536-73ce5847e6c0e7b1@postgresql.org  
Backpatch-through: 18  

commit   : abecdbc6af0192eb8fc017af5c7a3bb3d5da1ae3    
  
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   : 1383cbd03141316d98329341191d856c65d7c2c2    
  
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   : 45364e49688a2a845c6b43b182da3b5f3d10cff8    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 08:46:43 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 08:46:43 +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   : 66ec24276b18d111b916e6189b25e5c0a998a1f2    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 15:04:31 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 15:04:31 -0700    

If the string is preceded only by Case Ignorable characters, don't  
consider it to be a final sigma.  
  
In the process, refactor so that the preceding and following  
characters are found first, and then the rule is applied, to improve  
clarity.  
  
Discussion: https://postgr.es/m/c355354e6c3f4a7aafb047361b73db247260fca0.camel@j-davis.com  
Backpatch-through: 18  

commit   : 9021c8f3cabc42839329e3ab0dfed4137557d19f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 13:35:15 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 13:35:15 -0700    

Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/c355354e6c3f4a7aafb047361b73db247260fca0.camel@j-davis.com  
Backpatch-through: 17  

commit   : bb0a54518176cfb513a9df4a9cf69ba189701fe6    
  
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   : 2167302b748fb8fa9112710014b50910b19b9f15    
  
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   : 50313f8f015efd8d4f2de89e4d7fa83a8205aa6d    
  
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   : cf184ec77a04bf164692a0c7bcd148f1e96b71f2    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 7 Jul 2026 23:59:08 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 7 Jul 2026 23:59:08 +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   : 441e4c8d699910ea21f7f31ae7e76dbc1e572e05    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Tue, 7 Jul 2026 08:13:42 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Tue, 7 Jul 2026 08:13:42 +0900