PostgreSQL 14.23 commit log

commit   : 4e1a23c0ea0be0214c6806baa212886cee8f14a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 15:51:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 15:51:39 -0400    

commit   : 93741c9db09709ebe05d5f59ee7852c3ad4981a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 14:54:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 14:54:40 -0400    

Security: CVE-2026-6472, CVE-2026-6473, CVE-2026-6474, CVE-2026-6475, CVE-2026-6476, CVE-2026-6477, CVE-2026-6478, CVE-2026-6479, CVE-2026-6575, CVE-2026-6637, CVE-2026-6638  

commit   : c9447b8bd078f40c8b4969c63bebbb2cc228582b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 11 May 2026 21:18:06 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 11 May 2026 21:18:06 +0300    

These could overflow on 32-bit systems.  
  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 479823a71042423ad832e0d17ba11ff4c2bfa588    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 12:12:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 12:12:03 -0400    

These checks are failing in the buildfarm, reporting stack overflows  
rather than the expected errors, though seemingly only on ppc64 and  
s390x platforms.  Perhaps there is something off about our tests  
for stack depth on those architectures?  But there's no time to  
debug that right now, and surely these tests aren't too essential.  
Revert for now and plan to revisit after the release dust settles.  
  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 2b026df29c1e1caafb259a2021528a28ec484018    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 May 2026 05:13:52 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:52 -0700    

Maliciously crafted key value updates could achieve SQL injection  
within check_foreign_key().  To fix, ensure new key values are  
properly quoted and escaped in the internally generated SQL  
statements.  While at it, avoid potential buffer overruns by  
replacing the stack buffers for internally generated SQL statements  
with StringInfo.  
  
Reported-by: Nikolay Samokhvalov <nik@postgres.ai>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Security: CVE-2026-6637  
Backpatch-through: 14  

commit   : 8ac723b2bc992fd86b09ae73c7c610242c4c037e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

When result_is_int is set to 0, PQfn() cannot validate that the  
result fits in result_buf, so it will write data beyond the end of  
the buffer when the server returns more data than requested.  Since  
this function is insecurable and obsolete, add a warning to the top  
of the pertinent documentation advising against its use.  
  
The only in-tree caller of PQfn() is the frontend large object  
interface.  To fix that, add a buf_size parameter to  
pqFunctionCall3() that is used to protect against overruns, and use  
it in a private version of PQfn() that also accepts a buf_size  
parameter.  
  
Reported-by: Yu Kunpeng <yu443940816@live.com>  
Reported-by: Martin Heistermann <martin.heistermann@unibe.ch>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Security: CVE-2026-6477  
Backpatch-through: 14  

commit   : 8e81995de30c5a1834d7dae56a6396067d491975    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

If you accumulate many arrays full of NULLs, you could overflow  
'nitems', before reaching the MaxAllocSize limit on the allocations.  
Add an explicit check that the number of items doesn't grow too large.  
With more than MaxArraySize items, getting the final result with  
makeArrayResultArr() would fail anyway, so better to error out early.  
  
Reported-by: Xint Code  
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : bcfd848e7a4082d52b1b5c4a4e6aeca1c499b078    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

pg_locale_icu.c was full of places where a very long input string  
could cause integer overflow while calculating a buffer size,  
leading to buffer overruns.  
  
It also was cavalier about using char-type local arrays as buffers  
holding arrays of UChar.  The alignment of a char[] variable isn't  
guaranteed, so that this risked failure on alignment-picky platforms.  
The lack of complaints suggests that such platforms are very rare  
nowadays; but it's likely that we are paying a performance price on  
rather more platforms.  Declare those arrays as UChar[] instead,  
keeping their physical size the same.  
  
pg_locale_libc.c's strncoll_libc_win32_utf8() also had the  
disease of assuming it could double or quadruple the input  
string length without concern for overflow.  
  
Reported-by: Xint Code  
Reported-by: Pavel Kohout <pavel.kohout@aisle.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 498829dca45ad207a23954fe2e5a30ed2ef4b363    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

pg_rewind and pg_basebackup could be fed paths from rogue endpoints that  
could overwrite the contents of the client when received, achieving path  
traversal.  
  
There were two areas in the tree that were sensitive to this problem:  
- pg_basebackup, through the astreamer code, where no validation was  
performed before building an output path when streaming tar data.  This  
is an issue in v15 and newer versions.  
- pg_rewind file operations for paths received through libpq, for all  
the stable branches supported.  
  
In order to address this problem, this commit adds a helper function in  
path.c, that reuses path_is_relative_and_below_cwd() after applying  
canonicalize_path().  This can be used to validate the paths received  
from a connection point.  A path is considered invalid if any of the two  
following conditions is satisfied:  
- The path is absolute.  
- The path includes a direct parent-directory reference.  
  
Reported-by: XlabAI Team of Tencent Xuanwu Lab  
Reported-by: Valery Gubanov <valerygubanov95@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-6475  

commit   : 98675336195b526edc69890d68a1dc0408d63b3f    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

A few functions in this file were incautious about multiplying a  
possibly large integer by a factor more than 1 and then using it as  
an allocation size.  This is harmless on 64-bit systems where we'd  
compute a size exceeding MaxAllocSize and then fail, but on 32-bit  
systems we could overflow size_t, leading to an undersized  
allocation and buffer overrun.  To fix, use palloc_array() or  
mul_size() instead of handwritten multiplication.  
  
Reported-by: Sven Klemm <sven@tigerdata.com>  
Reported-by: Xint Code  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tatsuo Ishii <ishii@postgresql.org>  
Security: CVE-2026-6473  
Backpatch-through: 14  

commit   : 8bca85e9ff14fd4c24acd049cf9ff00c304001e4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

This omission allowed roles to create multirange types in any  
schema, potentially leading to privilege escalations.  Note that  
when a multirange type name is not specified in CREATE TYPE, it is  
automatically placed in the range type's schema, which is checked  
at the beginning of DefineRange().  
  
Reported-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Security: CVE-2026-6472  
Backpatch-through: 14  

commit   : 2c8226f52b4258e9e55185dce11d58a40c66663a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

Although pg_strftime() has defined error conditions, no callers bother  
to check for errors.  This is problematic because the output string is  
very likely not null-terminated if an error occurs, so that blindly  
using it is unsafe.  Rather than trusting that we can find and fix all  
the callers, let's alter the function's API spec slightly: make it  
guarantee a null-terminated result so long as maxsize > 0.  
  
Furthermore, if we do get an error, let's make that null-terminated  
result be an empty string.  We could instead truncate at the buffer  
length, but that risks producing mis-encoded output if the tz_name  
string contains multibyte characters.  It doesn't seem reasonable for  
src/timezone/ to make use of our encoding-aware truncation logic.  
Also, the only really likely source of a failure is a user-supplied  
timezone name that is intentionally trying to overrun our buffers.  
I don't feel a need to be particularly friendly about that case.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-6474  

commit   : a50ae8306fb0f4d646259f62471f73fb25afb564    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

timeofday() assumed that the output of pg_strftime() could not contain  
% signs, other than the one it explicitly asks for with %%.  However,  
we don't have that guarantee with respect to the time zone name (%Z).  
A crafted time zone setting could abuse the subsequent snprintf()  
call, resulting in crashes or disclosure of server memory.  
  
To fix, split the pg_strftime() call into two and then treat the  
outputs as literal strings, not a snprintf format string.  The  
extra pg_strftime() call doesn't really cost anything, since the  
bulk of the conversion work was done by pg_localtime().  
  
Also, adjust buffer widths so that we're not risking string truncation  
during the snprintf() step, as that would create a hazard of producing  
mis-encoded output.  
  
This also fixes a latent portability issue: the format string expects  
an int, but tp.tv_usec is long int on many platforms.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-6474  

commit   : 4608619a1cf578f16e799510eaa0a21c0f1f08e3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

This commit applies timingsafe_bcmp() to authentication paths that  
handle attributes or data previously compared with memcpy() or strcmp(),  
which are sensitive to timing attacks.  
  
The following data is concerned by this change, some being in the  
backend and some in the frontend:  
- For a SCRAM or MD5 password, the computed key or the MD5 hash compared  
with a password during a plain authentication.  
- For a SCRAM exchange, the stored key, the client's final nonce and the  
server nonce.  
- RADIUS (up to v18), the encrypted password.  
- For MD5 authentication, the MD5(MD5()) hash.  
  
Reported-by: Joe Conway <mail@joeconway.com>  
Security: CVE-2026-6478  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Backpatch-through: 14  

commit   : b282280e9b69cae988c0c69cce3eda4d4bd38fff    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

timingsafe_bcmp() should be used instead of memcmp() or a naive  
for-loop, when comparing passwords or secret tokens, to avoid leaking  
information about the secret token by timing. This commit just  
introduces the function but does not change any existing code to use  
it yet.  
  
This has been initially applied as of 09be39112654 in v18 and newer  
versions, and will be used in all the stable branches for an upcoming  
fix.  
  
Co-authored-by: Jelte Fennema-Nio <github-tech@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/7b86da3b-9356-4e50-aa1b-56570825e234@iki.fi  
Security: CVE-2026-6478  
Backpatch-through: 14  

commit   : 0747025259d6219e215dc1ff7924eabdc39c1749    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

contrib/intarray's query_int type uses an int16 field to hold the  
offset from a binary operator node to its left operand.  However, it  
allows the number of nodes to be as much as will fit in MaxAllocSize,  
so there is a risk of overflowing int16 depending on the precise shape  
of the tree.  Simple right-associative cases like "a | b | c | ..."  
work fine, so we should not solve this by restricting the overall  
number of nodes.  Instead add a direct test of whether each individual  
offset is too large.  
  
contrib/ltree's ltxtquery type uses essentially the same logic and  
has the same 16-bit restriction.  
  
(The core backend's tsquery.c has a variant of this logic too, but  
in that case the target field is 32 bits, so it is okay so long  
as varlena datums are restricted to 1GB.)  
  
In v16 and up, these types support soft error reporting, so we have  
to complicate the recursive findoprnd function's API a bit to allow  
the complaint to be reported softly.  v14/v15 don't need that.  
  
Undocumented and overcomplicated code like this makes my head hurt,  
so add some comments and simplify while at it.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 6a423a256907066f1f50583d34729d7502ba21da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

Define MaxAllocSize in src/include/common/fe_memutils.h rather  
than having several copies of it in different src/common/*.c files.  
This also provides an opportunity to document it better.  
  
Back-patch of commit 11b7de4a7, needed now because assorted security  
fixes are adding additional references to MaxAllocSize in frontend  
code.  
  
Backpatch-through: 14-17  
Security: CVE-2026-6473  

commit   : 3b4e66739aa5bad84ad439ab9776e3b8dc4ef290    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

The handling of SSL and GSS negotiation messages in  
ProcessStartupPacket() could cause a recursion of the backend,  
ultimately crashing the server as the negotiation attempts were not  
tracked across multiple calls processing startup packets.  
  
A malicious client could therefore alternate rejected SSL and GSS  
requests indefinitely, each adding a stack frame, until the backend  
crashed with a stack overflow, taking down a server.  
  
This commit addresses this issue by modifying ProcessStartupPacket() so  
as processed negotiation attempts are tracked, preventing infinite  
recursive attempts.  A TAP test is added to check this problem, where  
multiple SSL and GSS negotiated attempts are stacked.  
  
Reported-by: Calif.io in collaboration with Claude and Anthropic  
Research  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Security: CVE-2026-6479  
Backpatch-through: 14  

commit   : 14a4a70406ee65104a9f0bc79b3ff1642c83b30a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

These two routines will be used in a test of an upcoming fix.  This  
commit affects the v14~v17 range.  v18 and newer versions already  
include them, thanks to 85ec945b7880.  
  
Security: CVE-2026-6479  
Backpatch-through: 14  

commit   : e31ef072073f6b36e82197accd704ae428e6dd18    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

multirange_recv and BlockRefTableReaderNextRelation were incautious  
about multiplying a possibly-large integer by a factor more than 1  
and then using it as an allocation size.  This is harmless on 64-bit  
systems where we'd compute a size exceeding MaxAllocSize and then  
fail, but on 32-bit systems we could overflow size_t leading to an  
undersized allocation and buffer overrun.  
  
Fix these places by using palloc_array() instead of a handwritten  
multiplication.  (In HEAD, some of them were fixed already, but  
none of that work got back-patched at the time.)  
  
In addition, BlockRefTableReaderNextRelation passes the same value  
to BlockRefTableRead's "int length" parameter.  If built for  
64-bit frontend code, palloc_array() allows a larger array size  
than it otherwise would, potentially allowing that parameter to  
overflow.  Add an explicit check to forestall that and keep the  
behavior the same cross-platform.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 3e0eba19675404ce873cbeadfaff8c99ec94d012    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

Some UTF8 characters decompose to more than a dozen codepoints.  
It is possible for an input string that fits into well under  
1GB to produce more than 4G decomposed codepoints, causing  
unicode_normalize()'s decomp_size variable to wrap around to a  
small positive value.  This results in a small output buffer  
allocation and subsequent buffer overrun.  
  
To fix, test after each addition to see if we've overrun MaxAllocSize,  
and break out of the loop early if so.  In frontend code we want to  
just return NULL for this failure (treating it like OOM).  In the  
backend, we can rely on the following palloc() call to throw error.  
  
I also tightened things up in the calling functions in varlena.c,  
using size_t rather than int and allocating the input workspace  
with palloc_array().  These changes are probably unnecessary  
given the knowledge that the original input and the normalized  
output_chars array must fit into 1GB, but it's a lot easier to  
believe the code is safe with these changes.  
  
Reported-by: Xint Code  
Reported-by: Bruce Dang <bruce@calif.io>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Co-authored-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 39bc8f2cacae226dca9b0c9a6eac88df14e98f3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

The number of NFA states, number of NFA arcs, and number of colors  
are all bounded to reasonably small values.  However, there are  
places where we try to allocate arrays sized by products of those  
quantities, and those calculations could overflow, enabling  
buffer-overrun attacks.  In practice there's no problem on 64-bit  
machines, but there are some live scenarios on 32-bit machines.  
  
A related problem is that citerdissect() and creviterdissect()  
allocate arrays based on the length of the input string, which  
potentially could overflow.  
  
To fix, invent MALLOC_ARRAY and REALLOC_ARRAY macros that rely on  
palloc_array_extended and repalloc_array_extended with the NO_OOM  
option, similarly to the existing MALLOC and REALLOC macros.  
(Like those, they'll throw an error not return a NULL result for  
oversize requests.  This doesn't really fit into the regex code's  
view of error handling, but it'll do for now.  We can consider  
whether to change that behavior in a non-security follow-up patch.)  
  
I installed similar defenses in the colormap construction code.  
It's not entirely clear whether integer overflow is possible  
there, but analyzing the behavior in detail seems not worth  
the trouble, as the risky spots are not in hot code paths.  
  
I left a bunch of calls as-is after verifying that they can't  
overflow given reasonable limits on nstates and narcs.  Those  
limits were enforced already via REG_MAX_COMPILE_SPACE, but  
add commentary to document the interactions.  
  
In passing, also fix a related edge case, which is that the  
special color numbers used in LACON carcs could overflow the  
"color" data type, if ncolors is close to MAX_COLOR.  
  
In v14 and v15, the regex engine calls malloc() directly instead  
of using palloc(), so MALLOC_ARRAY and REALLOC_ARRAY do likewise.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 61a9b4b6e4f80725216b8234364acdaa7a72a1b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

Sufficiently large "count" arguments could result in undetected  
overflow, causing the allocated memory chunk to be much smaller  
than what the caller will subsequently write into it.  This is  
unlikely to be a hazard with 64-bit size_t but can sometimes  
happen on 32-bit builds, primarily where a function allocates  
workspace that's significantly larger than its input data.  
Rather than trying to patch the at-risk callers piecemeal,  
let's just redefine these macros so that they always check.  
  
To do that, move the longstanding add_size() and mul_size() functions  
into palloc.h and mcxt.c, and adjust them to not be specific to  
shared-memory allocation.  Then invent palloc_mul(), palloc0_mul(),  
palloc_mul_extended() to use these functions.  Actually, the latter  
use inlined copies to save one function call.  repalloc_array() gets  
similar treatment.  I didn't bother trying to inline the calls for  
repalloc0_array() though.  
  
In v14 and v15, this also adds repalloc_extended(), which previously  
was only available in v16 and up.  
  
We need copies of all this in fe_memutils.[hc] as well, since that  
module also provides palloc_array() etc.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : 37842f3dc6c2da8eb71816698e99391a0e0d4441    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

Commit 600086f47 added (several bespoke copies of) size_t addition with  
overflow checks to libpq. Move this to common/int.h, along with  
its subtraction and multiplication counterparts.  
  
pg_neg_size_overflow() is intentionally omitted; I'm not sure we should  
add SSIZE_MAX to win32_port.h for the sake of a function with no  
callers.  
  
Back-patch of commit 8934f2136, done now because pg_add_size_overflow()  
and friends are needed more widely for security fixes.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAOYmi%2B%3D%2BpqUd2MUitvgW1pAJuXgG_TKCVc3_Ek7pe8z9nkf%2BAg%40mail.gmail.com  
Backpatch-through: 14-18  
Security: CVE-2026-6473  

commit   : 2d267ffc449ad9e8a1fbc2e23d4b55754a5a6e02    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

The options "StartSel", "StopSel" and "FragmentDelimiter" given by a  
caller of the SQL function ts_headline() have their lengths stored as  
int16.  When providing values larger than PG_INT16_MAX, it was possible  
to overflow the length values stored, leading to incorrect behaviors in  
generateHeadline(), in most cases translating to a crash.  
  
Attempting to use values for these options larger than PG_INT16_MAX is  
now blocked.  Some test cases are added to cover our tracks.  
  
Reported-by: Xint Code  
Author: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 14  
Security: CVE-2026-6473  

commit   : b545c3787671ccbc54e76198da57424636a34f80    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:51 -0700    

The lquery parser in contrib/ltree/ had two overflow problems:  
- A single lquery level with many OR-separated variants (e.g.,  
'label1|label2|...'), could cause an overflow of totallen, this being  
stored as a uint16, meaning a maximum value of UINT16_MAX or 65k.  Each  
variant contributes MAXALIGN(LVAR_HDRSIZE + len) bytes.  With enough  
long variants, the value would wraparound.  This would corrupt the data  
written by LQL_NEXT(), leading to a stack corruption, most likely  
translating into a crash, but it would allow incorrect memory access.  
- numvar, labelled as a uint16, counts the number of OR-variants in a  
single level, and it is incremented without bounds checking.  With more  
than PG_UINT16_MAX (65k) variants in a single level, and a minimum of  
131kB of input data, it would wrap to 0.  When a (wildcard) '*' is  
used, this would change the query results silently.  
  
For both issues, a set of overflows checks are added to guard against  
these problematic patterns.  
  
The first issue has been reported by the three people listed below,  
affecting v16 and newer versions due to b1665bf01e5f.  Its coding was  
still unsafe in v14 and v15.  The second issue affects all the stable  
branches; I have bumped into while reviewing the code of the module.  
  
Reported-by: Vergissmeinnicht <vergissmeinnichtzh@gmail.com>  
Reported-by: A1ex <alex000young@gmail.com>  
Reported-by: Jihe Wang <wangjihe.mail@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Security: CVE-2026-6473  
Backpatch-through: 14  

commit   : e46ec738b54ffb26e59e901154488bd874ac6199    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2026 13:23:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2026 13:23:46 +0200    

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

commit   : 80cfa4c2a869c539dfaf2c83de139292c35b06b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 May 2026 12:07:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 May 2026 12:07:32 -0400    

commit   : fd5b36ab1891b6fa44d4a039ede518b952129855    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 5 May 2026 18:55:06 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 5 May 2026 18:55:06 +0900    

As connections that failed abort cleanup can't safely be further used,  
if a remote query tries to get such a connection, we reject it.  
Previously, this rejection involved dropping the connection if it was  
open, without accounting for the possibility of open cursors using it,  
causing a server crash when such an open cursor tried to use an  
already-dropped connection, as a cursor-handling function  
(create_cursor, fetch_more_data, or close_cursor) was called on a freed  
PGconn.  To fix, delay dropping failed connections until abort cleanup  
of the main transaction, to ensure open cursors using such a connection  
can safely refer to the PGconn for it.  
  
Oversight in commit 8bf58c0d9.  
  
Reported-by: Zhibai Song <songzhibai1234@gmail.com>  
Diagnosed-by: Zhibai Song <songzhibai1234@gmail.com>  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK176y6JP017-Cn%2BhS9CEJx_6iVhRoYbAqzuLU4d8-XPPNg%40mail.gmail.com  
Backpatch-through: 14  

commit   : 172034f6e08847219239b5fa45f2d4117aadf11b    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 5 May 2026 10:31:17 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 5 May 2026 10:31:17 +0900    

rel_is_distinct_for()'s RTE_SUBQUERY branch passed only the equality  
operator from each join clause to query_is_distinct_for(), discarding  
the operator's input collation.  query_is_distinct_for() then verified  
opfamily compatibility but never checked collations, so a DISTINCT /  
GROUP BY / set-op operating under one collation was trusted to prove  
uniqueness for a comparison performed under an unrelated collation.  
As with the recent fix in relation_has_unique_index_for(), this is  
unsound for nondeterministic collations and yields wrong query results  
in any optimization that consumes the proof.  
  
Fix by carrying each clause's operator input collation into  
query_is_distinct_for() and validating it at every check-site against  
the subquery target expression's collation.  
  
Back-patch to all supported branches.  query_is_distinct_for() is  
declared in an installed header, so on stable branches the existing  
two-list signature is retained as a thin wrapper that forwards to a  
new collation-aware entry point; external callers continue to receive  
the historical collation-blind answer.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAMbWs4_XUUSTyzCaRjUeeahWNqi=8ZOA5Q4coi8zUVEDSBkM6A@mail.gmail.com  
Backpatch-through: 14  

commit   : 8395446dff08a027f11fd0cbbd98150d5e5aa0bb    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 5 May 2026 10:30:37 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 5 May 2026 10:30:37 +0900    

relation_has_unique_index_for() has long had an XXX noting that it  
doesn't check collations when matching a unique index's columns  
against equality clauses.  This was benign as long as all collations  
in play reduced to the same notion of equality, but has been incorrect  
since nondeterministic collations were introduced in PG 12: a unique  
index under a deterministic collation does not prove uniqueness under  
a nondeterministic collation, nor vice versa.  
  
The consequence is wrong query results for any planner optimization  
that consumes the faulty proof, including inner-unique join execution  
(which stops the inner search after the first match per outer row),  
useless-left-join removal, semijoin-to-innerjoin reduction, and  
self-join elimination.  
  
Fix by requiring the index's collation to agree on equality with the  
clause's input collation.  Two collations agree on equality if either  
is InvalidOid (denoting a non-collation-sensitive operation, which  
cannot conflict with the other side), if they have the same OID, or if  
both are deterministic: by definition a deterministic collation treats  
two strings as equal iff they are byte-wise equal (see CREATE  
COLLATION), so any two deterministic collations share the same  
equality relation and the uniqueness proof carries over.  Any mismatch  
involving a nondeterministic collation is rejected.  
  
Back-patch to all supported branches; the bug has existed since  
nondeterministic collations were introduced in PG 12.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAMbWs4_XUUSTyzCaRjUeeahWNqi=8ZOA5Q4coi8zUVEDSBkM6A@mail.gmail.com  
Backpatch-through: 14  

commit   : f5d1038d92cf102b30cd4429d10c97b5293f8115    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 3 May 2026 20:23:50 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 3 May 2026 20:23:50 +0300    

The XLogRecordPageWithFreeSpace function updates the freespace map (FSM) data  
while replaying data-level WAL records during the recovery. If the FSM block  
is updated, it needs to be marked as modified. Currently, this is done with  
the MarkBufferDirtyHint call (as in all other cases for modifying FSM data).  
However, in the recovery context, this function will actually do nothing if  
checksums are enabled. It's assumed that the page should not be dirtied  
during recovery while modifying hints to protect against torn pages, since no  
new WAL data can be generated at this point to store FPI.  
  
Such logic does not seem fully aligned with the FSM case, as its blocks could  
be simply zeroed if a checksum mismatch is detected. Currently, changes to an  
FSM block could be lost if each change to that block occurs infrequently  
enough to allow it to be evicted from the cache. To persist the change, the  
modification needs to be performed while the FSM block is still kept in  
buffers and marked as dirty after receiving its FPI. If the block has already  
been cleaned, the change won't be persisted, so stored FSM blocks may remain  
in an obsolete state.  
  
If a large number of discrepancies between the data in leaf FSM blocks and the  
actual data blocks accumulate on the replica server, this could cause  
significant delays in insert operations after switchover. Such an insert  
operation may need to visit many data blocks marked as having sufficient  
space in the FSM, only to discover that the information is incorrect and the  
FSM records need to be corrected. In a heavily trafficked insert-only table  
with many concurrent clients performing inserts, this has been observed to  
cause several-second stalls, causing visible application malfunction. The  
desire to avoid such cases was the reason behind the commit ab7dbd681, which  
introduced an update of FSM data during the heap_xlog_visible invocation.  
However, an update to the FSM data on the standby side could be lost due to a  
missing 'dirty' flag, so there is still a possibility that a large number of  
FSM records will contain incorrect data. Note that having a zeroed FSM page  
in such a case (due to a checksum mismatch) is preferable, as a zero value  
will be interpreted as an indication of full data blocks, and the inserter  
will be routed to the next FSM block or to the end of the table.  
  
Given that FSM is ready to handle torn page writes and  
XLogRecordPageWithFreeSpace is called only during the recovery, there seems  
to be no reason to use MarkBufferDirtyHint here instead of a regular  
MarkBufferDirty call.  
  
Discussion: https://postgr.es/m/596c4f1c-f966-4512-b9c9-dd8fbcaf0928%40postgrespro.ru  
Author: Alexey Makhmutov <a.makhmutov@postgrespro.ru>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : f0e3f9732d41e0f6f902280fd3b117af272d7adc    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 1 May 2026 15:12:28 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 1 May 2026 15:12:28 -0400    

ECPGdeallocate_all(), ECPGprepared_statement(), ECPGget_desc(), and  
ecpg_freeStmtCacheEntry() could crash with a SIGSEGV when called  
without an established connection (for example, when EXEC SQL CONNECT  
was forgotten or a non-existent connection name was used), because  
they dereferenced the result of ecpg_get_connection() without first  
checking it for NULL.  
  
Each site is fixed in the style of the surrounding code.  
  
New tests are added for these conditions.  
  
Author: Shruthi Gowda <gowdashru@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Mahendra Singh Thalor <mahi6run@gmail.com>  
Reviewed-by: Nishant Sharma <nishant.sharma@enterprisedb.com>  
Discussion: https://postgr.es/m/3007317.1765210195@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : d36a668f5d79f96bd4affbc23ac4f8f9a8c8e8f2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2026 13:10:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2026 13:10:49 +0900    

Since 9d3e094f12, the command tries to validate the parent index of the  
named index, if invalid.  The documentation did not mention this  
behavior, which could be confusing.  
  
Author: Mohamed ALi <moali.pg@gmail.com>  
Discussion: https://postgr.es/m/CAGnOmWpHu25_LpT=zv7KtetQhqV1QEZzFYLd_TDyOLu1Od9fpw@mail.gmail.com  
Backpatch-through: 14  

commit   : 81b56b47c29d28f6041c94be5c5345f974d09f68    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 30 Apr 2026 11:04:57 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 30 Apr 2026 11:04:57 -0400    

When cloning extended statistics via CREATE TABLE ... LIKE ... INCLUDING  
STATISTICS, stxkeys holds attribute numbers from the source (parent)  
table, but get_attname() was being called with the child relation's  
OID.  If the parent has dropped columns, the child's attribute numbers  
are renumbered sequentially and no longer match, so the lookup either  
returns the wrong column name (silent corruption) or errors out when  
the attnum does not exist in the child.  
  
Fix it by remapping the parent attnum through attmap before the lookup,  
consistent with how expression statistics are already handled a few  
lines below.  
  
Add a regression test covering both manifestations: a 3-column parent  
where the stale attnum refers to no child column (cache-lookup error),  
and a 4-column parent where the stale attnum silently refers to the  
wrong child column.  
  
Author: Julien Tachoires <julmon@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Discussion: https://postgr.es/m/20260415105718.tomuncfbmlt67oel@poseidon.home.virt  
Backpatch-through: 14  

commit   : 5367c28c875cbaf3c8f4c39fbf9827aae4b7c5b1    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 29 Apr 2026 12:25:09 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 29 Apr 2026 12:25:09 -0500    

After a recent macOS update, building Postgres produces warnings  
that look like this:  
  
    ranlib: warning: 'libpgport_shlib.a(pg_cpu_x86.c.o)' has no symbols  
    ranlib: warning: 'libpgport_shlib.a(pg_popcount_x86.c.o)' has no symbols  
  
To fix, add a dummy symbol to files that may otherwise have none.  
Per project policy, this is a candidate for back-patching into  
out-of-support branches: it suppresses annoying compiler warnings  
but changes no behavior.  
  
Reported-by: Zhang Mingli <zmlpostgres@gmail.com>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/229aaaf3-f529-44ed-8e50-00cb6909af21%40Spark  
Backpatch-through: 13  

commit   : 220c29e3caa749d1d98a4ff115c650dd04faf38d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2026 16:17:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2026 16:17:31 +0900    

Author: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CAHut+PuvY_wYLPJ4DTs7NE9Lu2ty4d-OgZAOJC-NvCM=2wwcQQ@mail.gmail.com  
Backpatch-through: 14  

commit   : affd929c905270c3cc197749cfefd2d501f04f34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2026 12:28:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2026 12:28:35 -0400    

British Columbia (America/Vancouver) moved to permanent UTC-07 on  
2026-03-09, which will affect their clocks beginning on 2026-11-01.  
For lack of any clarity on the point, assume their TZ abbreviation  
will be MST from that time forward.  
  
Moldova (Europe/Chisinau) has followed EU DST transition times since  
2022.  
  
Backpatch-through: 14  

commit   : 109de35b705cac265185459ae947eb72810c3a82    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 24 Apr 2026 14:05:23 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 24 Apr 2026 14:05:23 +1200    

ExecEvalHashedScalarArrayOp(), when using a strict equality function,  
performs a short-circuit when looking up NULL values.  When the function  
is non-strict, the code incorrectly looked up the hash table for a  
zero-valued Datum, which could have resulted in an accidental true  
return if the hash table contained zero valued Datum, or could result  
in a crash for non-byval types.  
  
Here we fix this by adding an extra step when we build the hash table to  
check what the result of a NULL lookup would be.  This requires looping  
over the array and checking what the non-hashed version of the code  
would do.  We cache the results of that in the expression so that we can  
reuse the result any time we're asked to search for a NULL value.  
  
It's important to note that non-strict equality functions are free to  
treat any NULL value as equal to any non-NULL value.  For example,  
someone may wish to design a type that treats an empty string and NULL  
as equal.  
  
All built-in types have strict equality functions, so this could affect  
custom / user-defined types.  
  
Author: Chengpeng Yan <chengpeng_yan@outlook.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: ChangAo Chen <cca5507@qq.com>  
Discussion: https://postgr.es/m/A16187AE-2359-4265-9F5E-71D015EC2B2D@outlook.com  
Backpatch-through: 14  

commit   : fb5acf2d8f2eb2a91f59a2e790a23d1c45d9de19    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 24 Apr 2026 08:59:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 24 Apr 2026 08:59:14 +0900    

pg_test_timing reports timing differences in nanoseconds in master, and  
in microseconds in v14 through v18, but previously the backward-clock  
warning incorrectly labeled the value as milliseconds.  
  
This commit fixes the warning message to use "ns" in master and  
"us" in v14 through v18, matching the actual unit being reported.  
  
Backpatch to all supported versions.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Xiaopeng Wang <wxp_728@163.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/F780CEEB-A237-4302-9F55-60E9D8B6533D@gmail.com  
Backpatch-through: 14  

commit   : f76685b250c12f7449a3938b9a27befa812057c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2026 18:12:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2026 18:12:10 -0400    

drongo has been failing build in the v14 branch since 67d318e70:  
  
  regress.obj : error LNK2001: unresolved external symbol PGLZ_strategy_always [C:\\prog\\bf\\root\\REL_14_STABLE\\pgsql.build\\regress.vcxproj]  
  
This is evidently because PGLZ_strategy_always was not marked  
PGDLLIMPORT in that branch.  Back-patch the relevant part of  
8ec569479.  (Maybe we should back-patch more of it, but I'm  
content to just touch this one file.)  

commit   : d2f58c42a2613cc65cddd7a223f85b6bfc0093fb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Apr 2026 21:05:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Apr 2026 21:05:27 +0300    

If CheckAttributeType() is called with InvalidOid, it performs a bunch  
of pointless, futile syscache lookups with InvalidOid, but ultimately  
tolerates it and has no effect. We were calling it with InvalidOid on  
dropped columns, but it seems accidental that it works, so let's stop  
doing it.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/93ce56cd-02a6-4db1-8224-c8999372facc@iki.fi  
Backpatch-through: 14  

commit   : c7a1d5fc651371d6dac6e82f35e43b2adc81e72f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Apr 2026 21:28:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Apr 2026 21:28:11 +0300    

CheckAttributeType() checks that a composite type is not made a member  
of itself with ALTER TABLE ADD COLUMN or ALTER TYPE ADD ATTRIBUTE,  
even indirectly via a domain, array, another composite type or a range  
type. But it missed checking for multiranges. That was a simple  
oversight when multiranges were added.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/93ce56cd-02a6-4db1-8224-c8999372facc@iki.fi  
Backpatch-through: 14  

commit   : 8a6f08c0c7c3769ba32e302c95c7950179e5b87e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2026 12:41:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2026 12:41:01 -0400    

to_char() allocates its output buffer with 8 bytes per formatting  
code in the pattern.  If the locale's currency symbol, thousands  
separator, or decimal or sign symbol is more than 8 bytes long,  
in principle we could overrun the output buffer.  No such locales  
exist in the real world, so it seems sufficient to truncate the  
symbol if we do see it's too long.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/638232.1776790821@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 21a24d70950000741cc09866bc86e8be274f65df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2026 12:02:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2026 12:02:15 -0400    

parse_affentry() and addCompoundAffixFlagValue() each collect fields  
from an affix file into working buffers of size BUFSIZ.  They failed  
to defend against overlength fields, so that a malicious affix file  
could cause a stack smash.  BUFSIZ (typically 8K) is certainly way  
longer than any reasonable affix field, but let's fix this while  
we're closing holes in this area.  
  
I chose to do this by silently truncating the input before it can  
overrun the buffer, using logic comparable to the existing logic in  
get_nextfield().  Certainly there's at least as good an argument for  
raising an error, but for now let's follow the existing precedent.  
  
Reported-by: Igor Stepansky <igor.stepansky@orca.security>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 6cae0c2bd2119103a17d21bfd9982e41345b394d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2026 10:47:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2026 10:47:56 -0400    

This function writes into a caller-supplied buffer of length  
2 * MAXNORMLEN, which should be plenty in real-world cases.  
However a malicious affix file could supply an affix long  
enough to overrun that.  Defend by just rejecting the match  
if it would overrun the buffer.  I also inserted a check of  
the input word length against Affix->replen, just to be sure  
we won't index off the buffer, though it would be caller error  
for that not to be true.  
  
Also make the actual copying steps a bit more readable, and remove  
an unnecessary requirement for the whole input word to fit into the  
output buffer (even though it always will with the current caller).  
  
The lack of documentation in this code makes my head hurt, so  
I also reverse-engineered a basic header comment for CheckAffix.  
  
Reported-by: Xint Code  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/641711.1776792744@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : d809b16d1bd21ff708126ef111ddfee0fc477dbf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2026 10:34:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2026 10:34:40 +0900    

This commit tweaks ALTER INDEX .. ATTACH PARTITION to attempt a  
validation of a parent index in the case where an index is already  
attached but the parent is not yet valid.  This occurs in cases where a  
parent index was created invalid such as with CREATE INDEX ONLY, but was  
left invalid after an invalid child index was attached (partitioned  
indexes set indisvalid to false if at least one partition is  
!indisvalid, indisvalid is true in a partitioned table iff all  
partitions are indisvalid).  This could leave a partition tree in a  
situation where a user could not bring the parent index back to valid  
after fixing the child index, as there is no built-in mechanism to do  
so.  This commit relies on the fact that repeated ATTACH PARTITION  
commands on the same index silently succeed.  
  
An invalid parent index is more than just a passive issue.  It causes  
for example ON CONFLICT on a partitioned table if the invalid parent  
index is used to enforce a unique constraint.  
  
Some test cases are added to track some of problematic patterns, using a  
set of partition trees with combinations of invalid indexes and ATTACH  
PARTITION.  
  
Reported-by: Mohamed Ali <moali.pg@gmail.com>  
Author: Sami Imseih <sanmimseih@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Haibo Yan <tristan.yim@gmail.com>  
Discussion: http://postgr.es/m/CAGnOmWqi1D9ycBgUeOGf6mOCd2Dcf=6sKhbf4sHLs5xAcKVCMQ@mail.gmail.com  
Backpatch-through: 14  

commit   : babf2f740d10ab1860a6985dacf7aadfa134b654    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2026 10:54:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2026 10:54:39 -0400    

We were using "select count(*) into x from generate_series(1,  
1_000_000_000_000)" to waste one second waiting for a statement  
timeout trap.  Aside from consuming CPU to little purpose, this could  
easily eat several hundred MB of temporary file space, which has been  
observed to cause out-of-disk-space errors in the buildfarm.  
Let's just use "pg_sleep(10)", which is far less resource-intensive.  
  
Also update the "when others" exception handler so that if it does  
ever again trap an error, it will tell us what error.  The cause of  
these intermittent buildfarm failures had been obscure for awhile.  
  
Discussion: https://postgr.es/m/557992.1776779694@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 8e39951beac7ae361f742022d0060b1ce3ba99e8    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 21 Apr 2026 14:31:15 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 21 Apr 2026 14:31:15 +0900    

When a rule action or rule qualification references NEW.col where col  
is a generated column (stored or virtual), the rewriter produces  
incorrect results.  
  
rewriteTargetListIU removes generated columns from the query's target  
list, since stored generated columns are recomputed by the executor  
and virtual ones store nothing.  However, ReplaceVarsFromTargetList  
then cannot find these columns when resolving NEW references during  
rule rewriting.  For UPDATE, the REPLACEVARS_CHANGE_VARNO fallback  
redirects NEW.col to the original target relation, making it read the  
pre-update value (same as OLD.col).  For INSERT,  
REPLACEVARS_SUBSTITUTE_NULL replaces it with NULL.  Both are wrong  
when the generated column depends on columns being modified.  
  
Fix by building target list entries for generated columns from their  
generation expressions, pre-resolving the NEW.attribute references  
within those expressions against the query's targetlist, and passing  
them together with the query's targetlist to ReplaceVarsFromTargetList.  
  
Back-patch to all supported branches.  Virtual generated columns were  
added in v18, so the back-patches in pre-v18 branches only handle  
stored generated columns.  
  
Reported-by: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAHg+QDexGTmCZzx=73gXkY2ZADS6LRhpnU+-8Y_QmrdTS6yUhA@mail.gmail.com  
Backpatch-through: 14  

commit   : f33874c3a9970184ae59c5600e0af104d7fddcf0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 Apr 2026 08:45:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 Apr 2026 08:45:45 +0900    

The documentation for jit_debugging_support and jit_profiling_support  
previously stated that these parameters can only be set at server start.  
  
However, both parameters use the PGC_SU_BACKEND context, meaning they  
can be set at session start by superusers, but cannot be changed within  
an active session.  
  
This commit updates the documentation to reflect the actual behavior.  
  
Backpatch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAHGQGwEpMDpB-K8SSUVRRHg6L6z3pLAkekd9aviOS=ns0EC=+Q@mail.gmail.com  
Backpatch-through: 14  

commit   : 0a26194683516a766344f0d899f23ae6e183524c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Apr 2026 15:30:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Apr 2026 15:30:59 +0900    

The documentation stated only that the log file created by pg_ctl -l is  
inaccessible to other users by default. However, since commit c37b3d0,  
the actual behavior is that only the cluster owner has access by default,  
but users in the same group as the cluster owner may also read the file  
if group access is enabled in the cluster.  
  
This commit updates the documentation to describe this behavior  
more clearly.  
  
Backpatch to all supported versions.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Xiaopeng Wang <wxp_728@163.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/OS9PR01MB1214959BE987B4839E3046050F54BA@OS9PR01MB12149.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : e5fb1ff5bed9778f159a658ff098db97c8ec8536    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 16 Apr 2026 18:17:05 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 16 Apr 2026 18:17:05 +1200    

  * JOHAB: replace the incorrect "simplified Chinese" description with  
    a correct one that identifies it as the Korean combining (Johab)  
    encoding standardized in KS X 1001 annex 3.  
  
  * EUC_KR: drop a stray space before the comma in the existing  
    comment, and note that the encoding covers the KS X 1001  
    precomposed (Wansung) form.  
  
  * UHC: spell out "Unified Hangul Code", clarify that it is  
    Microsoft Windows CodePage 949, and describe its relationship to  
    EUC-KR (superset covering all 11,172 precomposed Hangul syllables).  
  
Backpatch-through: 14  
Author: Henson Choi <assam258@gmail.com>  
Discussion: https://postgr.es/m/CAAAe_zAFz1v-3b7Je4L%2B%3DwZM3UGAczXV47YVZfZi9wbJxspxeA%40mail.gmail.com  

commit   : e138b78cdc963cd0497c5355e20921aeb516f805    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2026 05:09:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2026 05:09:15 +0900    

The goal of this module is to provide an entry point for the coverage of  
the low-level compression and decompression PGLZ routines.  The new test  
is moved to a new parallel group, with all the existing  
compression-related tests added to it.  
  
This includes tests for the cases detected by fuzzing that emulate  
corrupted compressed data, as fixed by 2b5ba2a0a141:  
- Set control bit with read of a match tag, where no data follows.  
- Set control bit with read of a match tag, where 1 byte follows.  
- Set control bit with match tag where length nibble is 3 bytes  
(extended case).  
  
While on it, some tests are added for compress/decompress roundtrips,  
and for check_complete=false/true.  Like 2b5ba2a0a141, backpatch to all  
the stable branches.  
  
Discussion: https://postgr.es/m/adw647wuGjh1oU6p@paquier.xyz  
Backpatch-through: 14  

commit   : de32a01e7bb905b455d1a001b011433bd41dfb6a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 9 Apr 2026 11:48:55 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 9 Apr 2026 11:48:55 -0400    

When decoding a match tag, pglz_decompress() reads 2 bytes (or 3  
for extended-length matches) from the source buffer before checking  
whether enough data remains.  The existing bounds check (sp > srcend)  
occurs after the reads, so truncated compressed data that ends  
mid-tag causes a read past the allocated buffer.  
  
Fix by validating that sufficient source bytes are available before  
reading each part of the match tag.  The post-read sp > srcend  
check is no longer needed and is removed.  
  
Found by fuzz testing with libFuzzer and AddressSanitizer.  
  
Backpatch-through: 14  

commit   : a7c41df1f2fdfba42d09a978213066d941e45c9b    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 19 Oct 2022 12:59:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Oct 2022 12:59:29 +0900    

make_ctags did not include field members of structs since the commit  
964d01ae90c314eb31132c2e7712d5d9fc237331.  
  
For example, in the following field of RestrictInfo:  
  
   Selectivity norm_selec pg_node_attr(equal_ignore);  
  
pg_node_attr was mistakenly interpreted to be the name of the field.  
To fix this, add -I option to ctags command if the command is  
Exuberant ctags or Universal ctags (for plain old ctags, struct  
members are not included in the tags file anyway).  
  
Also add "-e" and "-n" options to make_ctags. The -e option invokes  
ctags command with -e option, which produces TAGS file for emacs. This  
allows to eliminate duplicate codes in make_etags so that make_etags  
just exec make_ctags with -e option.  
  
The -n option allows not to produce symbolic links in each  
sub directory (the default is producing symbolic links).  
  
This includes the follow-up fixes: 87f21d2c6890 and ae66716bf3ef.  This  
change is applied to v15 and v14, v16 and nwer versions already  
including these improvements.  One reason why I am doing this backpatch  
is that this can be really useful for backpatching purposes, especially  
the -n option that limits the number of TAGS/tags files created in the  
tree.  
  
Author: Yugo Nagata  
Reviewers: Alvaro Herrera, Tatsuo Ishii  
Discussion: https://postgr.es/m/flat/20221007154442.76233afc7c5b255c4de6528a%40sraoss.co.jp  
Discussion: https://postgr.es/m/adcKr7fob5ZvjhlH@paquier.xyz  
Backpatch-through: 14  

commit   : 305cf0df0c7834a23d5ee22c0560970bb66d68eb    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 9 Apr 2026 19:28:33 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 9 Apr 2026 19:28:33 +0900    

In nodeWindowAgg.c, the calculations for frame start and end positions  
in ROWS and GROUPS modes were performed using simple integer addition.  
If a user-supplied offset was sufficiently large (close to INT64_MAX),  
adding it to the current row or group index could cause a signed  
integer overflow, wrapping the result to a negative number.  
  
This led to incorrect behavior where frame boundaries that should have  
extended indefinitely (or beyond the partition end) were treated as  
falling at the first row, or where valid rows were incorrectly marked  
as out-of-frame.  Depending on the specific query and data, these  
overflows can result in incorrect query results, execution errors, or  
assertion failures.  
  
To fix, use overflow-aware integer addition (ie, pg_add_s64_overflow)  
to check for overflows during these additions.  If an overflow is  
detected, the boundary is now clamped to INT64_MAX.  This ensures the  
logic correctly treats the boundary as extending to the end of the  
partition.  
  
Bug: #19405  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/19405-1ecf025dda171555@postgresql.org  
Backpatch-through: 14  

commit   : 40fa04e7c851752e79ac50c512bd1dea2c3002bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2026 14:22:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2026 14:22:17 -0400    

Commit aa606b931 installed a test that would reference a nonexistent  
TupleDesc array entry if a system column is used in COPY FROM WHERE.  
Typically this would be harmless, but with bad luck it could result  
in a phony "generated columns are not supported in COPY FROM WHERE  
conditions" error, and at least in principle it could cause SIGSEGV.  
(Compare 570e2fcc0 which fixed the identical problem in another  
place.)  Also, since c98ad086a it throws an Assert instead.  
  
In the back branches, just guard the test to make it a safe no-op for  
system columns.  Commit 21c69dc73 installed a more aggressive answer  
in master.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/6f435023-8ab6-47c2-ba07-035d0c4212f9@gmail.com  
Backpatch-through: 14-18  

commit   : 9b354cfc55846464d19c695badbe6897d0393988    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 3 Apr 2026 14:48:54 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 3 Apr 2026 14:48:54 +1300    

LLVM 22 has the fix that we copied into our tree in commit 9044fc1d and  
a new function to reach it[1][2], so we only need to use our copy for  
Aarch64 + LLVM < 22.  The only change to the final version that our copy  
didn't get is a new LLVM_ABI macro, but that isn't appropriate for us.  
Our copy is hopefully now frozen and would only need maintenance if bugs  
are found in the upstream code.  
  
Non-Aarch64 systems now also use the new API with LLVM 22.  It allocates  
all sections with one contiguous mmap() instead of one per  
section.  We could have done that earlier, but commit 9044fc1d wanted to  
limit the blast radius to the affected systems.  We might as well  
benefit from that small improvement everywhere now that it is available  
out of the box.  
  
We can't delete our copy until LLVM 22 is our minimum supported version,  
or we switch to the newer JITLink API for at least Aarch64.  
  
[1] https://github.com/llvm/llvm-project/pull/71968  
[2] https://github.com/llvm/llvm-project/pull/174307  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CA%2BhUKGJTumad75o8Zao-LFseEbt%3DenbUFCM7LZVV%3Dc8yg2i7dg%40mail.gmail.com  

commit   : b4e7cd428c00cf0888d4cf2b2484026b05643766    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Apr 2026 15:24:44 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Apr 2026 15:24:44 +1300    

The lifetime.end intrinsic can now only be used for stack memory  
allocated with alloca[1][2][3].  We use it to tell LLVM about the  
lifetime of function arguments/isnull values that we keep in palloc'd  
memory, so that it can avoid spilling registers to memory.  
  
We might need to rearrange things and put them on the stack, but that'll  
take some research.  In the meantime, unbreak the build on LLVM 22.  
  
[1] https://github.com/llvm/llvm-project/pull/149310  
[2] https://llvm.org/docs/LangRef.html#llvm-lifetime-end-intrinsic  
[3] https://llvm.org/docs/LangRef.html#i-alloca  
  
Backpatch-through: 14  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> (earlier attempt)  
Reviewed-by: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> (earlier attempt)  
Reviewed-by: Andres Freund <andres@anarazel.de> (earlier attempt)  
Discussion: https://postgr.es/m/CA%2BhUKGJTumad75o8Zao-LFseEbt%3DenbUFCM7LZVV%3Dc8yg2i7dg%40mail.gmail.com  

commit   : 9a53249c5b12ed7b291c4d3061a638d3868b1123    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 1 Apr 2026 09:48:48 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 1 Apr 2026 09:48:48 -0500    

Oversight in commit 665d1fad99.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAHut%2BPv72haFerrCdYdmF6hu6o2jKcGzkXehom%2BsP-JBBmOVDg%40mail.gmail.com  
Backpatch-through: 14  

commit   : 7cd23aad2a7aeeac276019e2f831313c75a8be2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2026 13:59:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2026 13:59:54 -0400    

Several places in tuplestore.c would leave the tuplestore data  
structure effectively corrupt if some subroutine were to throw  
an error.  Notably, if WRITETUP() failed after some number of  
successful calls within dumptuples(), the tuplestore would  
contain some memtuples pointers that were apparently live  
entries but in fact pointed to pfree'd chunks.  
  
In most cases this sort of thing is fine because transaction  
abort cleanup is not too picky about the contents of memory that  
it's going to throw away anyway.  There's at least one exception  
though: if a Portal has a holdStore, we're going to call  
tuplestore_end() on that, even during transaction abort.  
So it's not cool if that tuplestore is corrupt, and that means  
tuplestore.c has to be more careful.  
  
This oversight demonstrably leads to crashes in v15 and before,  
if a holdable cursor fails to persist its data due to an undersized  
temp_file_limit setting.  Very possibly the same thing can happen in  
v16 and v17 as well, though the specific test case submitted failed  
to fail there (cf. 095555daf).  The failure is accidentally dodged  
as of v18 because 590b045c3 got rid of tuplestore_end's retail tuple  
deletion loop.  Still, it seems unwise to permit tuplestores to become  
internally inconsistent in any branch, so I've applied the same fix  
across the board.  
  
Since the known test case for this is rather expensive and doesn't  
fail in recent branches, I've omitted it.  
  
Bug: #19438  
Reported-by: Dmitriy Kuzmin <kuzmin.db4@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/19438-9d37b179c56d43aa@postgresql.org  
Backpatch-through: 14  

commit   : 6ce5c310ba4f34c3d41b82d346628e8125b22456    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2026 16:18:13 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2026 16:18:13 +1300    

Functions such as hash_numeric() are not careful to use the correct  
PG_RETURN_*() macro according to the return type of that function as  
defined in pg_proc.  Because that function is meant to return int32,  
when the hashed value exceeds 2^31, the 64-bit Datum value won't wrap to  
a negative number, which means the Datum won't have the same value as it  
would have had it been cast to int32 on a two's complement machine.  This  
isn't harmless as both datum_image_eq() and datum_image_hash() may receive  
a Datum that's been formed and deformed from a tuple in some cases, and  
not in other cases.  When formed into a tuple, the Datum value will be  
coerced into an integer according to the attlen as specified by the  
TupleDesc.  This can result in two Datums that should be equal being  
classed as not equal, which could result in (but not limited to) an error  
such as:  
  
ERROR:  could not find memoization table entry  
  
Here we fix this by ensuring we cast the Datum value to a signed integer  
according to the typLen specified in the datum_image_eq/datum_image_hash  
function call before comparing or hashing.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reported-by: Tender Wang <tndrwang@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAHewXNmcXVFdB9_WwA8Ez0P+m_TQy_KzYk5Ri5dvg+fuwjD_yw@mail.gmail.com  

commit   : a6d03067ff5d2198caf4805882dcdbe813a55817    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 27 Mar 2026 12:20:38 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 27 Mar 2026 12:20:38 +0200    

By using palloc() instead of raw malloc().  
  
Reported-by: Gaurav Singh <gaurav.singh@yugabyte.com>  
Reviewed-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/CAEcQ1bYR9s4eQLFDjzzJHU8fj-MTbmRpW-9J-r2gsCn+HEsynw@mail.gmail.com  
Backpatch-through: 14  

commit   : bf7ecf35318d432e6661c3b79e0160ff733eef7b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Mar 2026 20:49:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Mar 2026 20:49:31 +0900    

pg_stat_replication is documented to keep the last measured lag values for  
a short time after the standby catches up, and then set them to NULL when  
there is no WAL activity. However, previously lag values could become NULL  
prematurely even while WAL activity was ongoing, especially in logical  
replication.  
  
This happened because the code cleared lag when two consecutive reply messages  
indicated that the apply location had caught up with the send location.  
It did not verify that the reported positions were unchanged, so lag could be  
cleared even when positions had advanced between messages. In logical  
replication, where the apply location often quickly catches up, this issue was  
more likely to occur.  
  
This commit fixes the issue by clearing lag only when the standby reports that  
it has fully replayed WAL (i.e., both flush and apply locations have caught up  
with the send location) and the write/flush/apply positions remain unchanged  
across two consecutive reply messages.  
  
The second message with unchanged positions typically results from  
wal_receiver_status_interval, so lag values are cleared after that interval  
when there is no activity. This avoids showing stale lag data while preventing  
premature NULL values.  
  
Even with this fix, lag may rarely become NULL during activity if identical  
position reports are sent repeatedly. Eliminating such duplicate messages  
would address this fully, but that change is considered too invasive for stable  
branches and will be handled in master only later.  
  
Backpatch to all supported branches.  
  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAOzEurTzcUrEzrH97DD7+Yz=HGPU81kzWQonKZvqBwYhx2G9_A@mail.gmail.com  
Backpatch-through: 14  

commit   : 4dc9346531e1833ebe482828aa75d0638895c9ec    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Tue, 24 Mar 2026 16:40:33 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Tue, 24 Mar 2026 16:40:33 +0700    

The check for a mismatch on the second decoded item pointer  
was an exact copy of the first item pointer check, comparing  
orig_itemptrs[0] with decoded_itemptrs[0] instead of orig_itemptrs[1]  
with decoded_itemptrs[1].  The error message also reported (0, 1) as  
the expected value instead of (blk, off).  As a result, any decoding  
error in the second item pointer (where the varbyte delta encoding  
is exercised) would go undetected.  
  
This has been wrong since commit bde7493d1, so backpatch to all  
supported versions.  
  
Author: Jianghua Yang <yjhjstz@gmail.com>  
Discussion: https://postgr.es/m/CAAZLFmSOD8R7tZjRLZsmpKtJLoqjgawAaM-Pne1j8B_Q2aQK8w@mail.gmail.com  
Backpatch-through: 14  

commit   : e35e466f61b358f88f20fbebd3996c50589a6663    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 23 Mar 2026 11:53:32 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 23 Mar 2026 11:53:32 +0200    

If a CHECKPOINT record with nextMulti N is written to the WAL before  
the CREATE_ID record for N, and N happens to be the first multixid on  
an offset page, the backwards compatibility logic to tolerate WAL  
generated by older minor versions (before commit 789d65364c) failed to  
compensate for the missing XLOG_MULTIXACT_ZERO_OFF_PAGE record. In  
that case, the latest_page_number was initialized at the start of WAL  
replay to the page for nextMulti from the CHECKPOINT record, even if  
we had not seen the CREATE_ID record for that multixid yet, which  
fooled the backwards compatibility logic to think that the page was  
already initialized.  
  
To fix, track the last XLOG_MULTIXACT_ZERO_OFF_PAGE that we've seen  
separately from latest_page_number. If we haven't seen any  
XLOG_MULTIXACT_ZERO_OFF_PAGE records yet, use  
SimpleLruDoesPhysicalPageExist() to check if the page needs to be  
initialized.  
  
Reported-by: duankunren.dkr <duankunren.dkr@alibaba-inc.com>  
Analyzed-by: duankunren.dkr <duankunren.dkr@alibaba-inc.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Discussion: https://www.postgresql.org/message-id/c4ef1737-8cba-458e-b6fd-4e2d6011e985.duankunren.dkr@alibaba-inc.com  
Backpatch-through: 14-18  

commit   : c6f369e585e93f73cec21aff8974a8610572f446    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 19 Mar 2026 14:59:07 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 19 Mar 2026 14:59:07 -0700    

ALTER FOREIGN DATA WRAPPER could drop the dependency on the handler  
function if it wasn't explicitly specified.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/35c44a4b7fb76d35418c4d66b775a88f4ce60c86.camel@j-davis.com  
Backpatch-through: 14  

commit   : f154714646505f93632820afad5604628558cbf1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Mar 2026 08:10:20 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Mar 2026 08:10:20 +0900    

Commit 6eedb2a5fd8 made the logical walsender call  
XLogFlush(GetXLogInsertRecPtr()) to ensure that all pending WAL is flushed,  
fixing a publisher shutdown hang. However, if the last WAL record ends at  
a page boundary, GetXLogInsertRecPtr() can return an LSN pointing past  
the page header, which can cause XLogFlush() to report an error.  
  
A similar issue previously existed in the GiST code. Commit b1f14c96720  
introduced GetXLogInsertEndRecPtr(), which returns a safe WAL insertion end  
location (returning the start of the page when the last record ends at a page  
boundary), and updated the GiST code to use it with XLogFlush().  
  
This commit fixes the issue by making the logical walsender use  
XLogFlush(GetXLogInsertEndRecPtr()) when flushing pending WAL during shutdown.  
  
Backpatch to all supported versions.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/vzguaguldbcyfbyuq76qj7hx5qdr5kmh67gqkncyb2yhsygrdt@dfhcpteqifux  
Backpatch-through: 14  

commit   : ff78b8fac46e82dcee0d994dab87e4634c7d7d9b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2026 15:24:37 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 14 Mar 2026 15:24:37 +0100    

The comment about ParallelWorkerNumbr in parallel.c says:  
  
  In parallel workers, it will be set to a value >= 0 and < the number  
  of workers before any user code is invoked; each parallel worker will  
  get a different parallel worker number.  
  
However asserts in various places collecting instrumentation allowed  
(ParallelWorkerNumber == num_workers). That would be a bug, as the value  
is used as index into an array with num_workers entries.  
  
Fixed by adjusting the asserts accordingly. Backpatch to all supported  
versions.  
  
Discussion: https://postgr.es/m/5db067a1-2cdf-4afb-a577-a04f30b69167@vondra.me  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Backpatch-through: 14  

commit   : c0ffc725f8b3ae51a5755233bd84499b8221f92e    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 13 Mar 2026 22:42:29 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 13 Mar 2026 22:42:29 +0100    

The function used GetXLogInsertRecPtr() to generate the fake LSN. Most  
of the time this is the same as what XLogInsert() would return, and so  
it works fine with the XLogFlush() call. But if the last record ends at  
a page boundary, GetXLogInsertRecPtr() returns LSN pointing after the  
page header. In such case XLogFlush() fails with errors like this:  
  
  ERROR: xlog flush request 0/01BD2018 is not satisfied --- flushed only to 0/01BD2000  
  
Such failures are very hard to trigger, particularly outside aggressive  
test scenarios.  
  
Fixed by introducing GetXLogInsertEndRecPtr(), returning the correct LSN  
without skipping the header. This is the same as GetXLogInsertRecPtr(),  
except that it calls XLogBytePosToEndRecPtr().  
  
Initial investigation by me, root cause identified by Andres Freund.  
  
This is a long-standing bug in gistGetFakeLSN(), probably introduced by  
c6b92041d38 in PG13. Backpatch to all supported versions.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/vf4hbwrotvhbgcnknrqmfbqlu75oyjkmausvy66ic7x7vuhafx@e4rvwavtjswo  
Backpatch-through: 14  

commit   : 70f7c5badcc069560993faabc744466804446246    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2026 16:06:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2026 16:06:51 +0900    

The logic of xslt_process() has never considered the fact that  
xsltSaveResultToString() would return NULL for an empty string (the  
upstream code has always done so, with a string length of 0).  This  
would cause memcpy() to be called with a NULL pointer, something  
forbidden by POSIX.  
  
Like 46ab07ffda9d and similar fixes, this is backpatched down to all the  
supported branches, with a test case to cover this scenario.  An empty  
string has been always returned in xml2 in this case, based on the  
history of the module, so this is an old issue.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/c516a0d9-4406-47e3-9087-5ca5176ebcf9@gmail.com  
Backpatch-through: 14  

commit   : a84a9a4260689210b87f13e7b3e13b7e8c135576    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 9 Mar 2026 18:24:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 9 Mar 2026 18:24:41 +0900    

Commit 2cd40adb85d added the IF NOT EXISTS option to ALTER TABLE ADD COLUMN.  
This also enabled IF NOT EXISTS for ALTER FOREIGN TABLE ADD COLUMN,  
but the ALTER FOREIGN TABLE documentation was not updated to mention it.  
  
This commit updates the documentation to describe the IF NOT EXISTS option for  
ALTER FOREIGN TABLE ADD COLUMN.  
  
While updating that section, also this commit clarifies that the COLUMN keyword  
is optional in ALTER FOREIGN TABLE ADD/DROP COLUMN. Previously, part of  
the documentation could be read as if COLUMN were required.  
  
This commit adds regression tests covering these ALTER FOREIGN TABLE syntaxes.  
  
Backpatch to all supported versions.  
  
Suggested-by: Fujii Masao <masao.fujii@gmail.com>  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwFk=rrhrwGwPtQxBesbT4DzSZ86Q3ftcwCu3AR5bOiXLw@mail.gmail.com  
Backpatch-through: 14  

commit   : eb11d7a9158d3cd31245b14fb2601e227d947db1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2026 13:46:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2026 13:46:38 +0900    

When make_new_segment() creates an odd-sized segment, the pagemap was  
only sized based on a number of usable_pages entries, forgetting that a  
segment also contains metadata pages, and that the FreePageManager uses  
absolute page indices that cover the entire segment.  This  
miscalculation could cause accesses to pagemap entries to be out of  
bounds.  During subsequent reuse of the allocated segment, allocations  
landing on pages with indices higher than usable_pages could cause  
out-of-bounds pagemap reads and/or writes.  On write, 'span' pointers  
are stored into the data area, corrupting the allocated objects.  On  
read (aka during a dsa_free), garbage is interpreted as a span pointer,  
typically crashing the server in dsa_get_address().  
  
The normal geometric path correctly sizes the pagemap for all pages in  
the segment.  The odd-sized path needs to do the same, but it works  
forward from usable_pages rather than backward from total_size.  
  
This commit fixes the sizing of the odd-sized case by adding pagemap  
entries for the metadata pages after the initial metadata_bytes  
calculation, using an integer ceiling division to compute the exact  
number of additional entries needed in one go, avoiding any iteration in  
the calculation.  
  
An assertion is added in the code path for odd-sized segments, ensuring  
that the pagemap includes the metadata area, and that the result is  
appropriately sized.  
  
This problem would show up depending on the size requested for the  
allocation of a DSA segment.  The reporter has noticed this issue when a  
parallel hash join makes a DSA allocation large enough to trigger the  
odd-sized segment path, but it could happen for anything that does a DSA  
allocation.  
  
A regression test is added to test_dsa, down to v17 where the test  
module has been introduced.  This adds a set of cheap tests to check the  
problem, the new assertion being useful for this purpose.  Sami has  
proposed a test that took a longer time than what I have done here; the  
test committed is faster and good enough to check the odd-sized  
allocation path.  
  
Author: Paul Bunn <paul.bunn@icloud.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/044401dcabac$fe432490$fac96db0$@icloud.com  
Backpatch-through: 14  

commit   : 3bf6f22ce151a17ab04a99f70e0cc95b23c6d893    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Mar 2026 16:43:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Mar 2026 16:43:40 +0900    

Previously, when logical replication was running, shutting down  
the publisher could cause the logical walsender to enter a busy loop  
and prevent the publisher from completing shutdown.  
  
During shutdown, the logical walsender waits for all pending WAL  
to be written out. However, some WAL records could remain unflushed,  
causing the walsender to wait indefinitely.  
  
The issue occurred because the walsender used XLogBackgroundFlush() to  
flush pending WAL. This function does not guarantee that all WAL is written.  
For example, WAL generated by a transaction without an assigned  
transaction ID that aborts might not be flushed.  
  
This commit fixes the bug by making the logical walsender call XLogFlush()  
instead, ensuring that all pending WAL is written and preventing  
the busy loop during shutdown.  
  
Backpatch to all supported versions.  
  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAO6_Xqo3co3BuUVEVzkaBVw9LidBgeeQ_2hfxeLMQcXwovB3GQ@mail.gmail.com  
Backpatch-through: 14  

commit   : 921f4a15c10f9791d6d57de7a4e714ef2d3a5fa9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Mar 2026 12:57:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Mar 2026 12:57:52 +0900    

In ALTER TABLE ... ADD/DROP COLUMN, the COLUMN keyword is optional. However,  
part of the documentation could be read as if COLUMN were required, which may  
mislead users about the command syntax.  
  
This commit updates the ALTER TABLE documentation to clearly state that  
COLUMN is optional for ADD and DROP.  
  
Also this commit adds regression tests covering ALTER TABLE ... ADD/DROP  
without the COLUMN keyword.  
  
Backpatch to all supported versions.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAEoWx2n6ShLMOnjOtf63TjjgGbgiTVT5OMsSOFmbjGb6Xue1Bw@mail.gmail.com  
Backpatch-through: 14  

commit   : 1346794feb776603232e4cd330affe31ab3c4e1e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2026 10:06:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2026 10:06:08 +0900    

This fixes a problem similar to ad8c86d22cbd.  In this case, the test  
could fail under the following circumstances:  
- The primary is stopped with teardown_node(), meaning that it may not  
be able to send all its WAL records to standby_1 and standby_2.  
- If standby_2 receives more records than standby_1, attempting to  
reconnect standby_2 to the promoted standby_1 would fail because of a  
timeline fork.  
  
This race condition is fixed with a simple trick: instead of tearing  
down the primary, it is stopped cleanly so as all the WAL records of the  
primary are received and flushed by both standby_1 and standby_2.  Once  
we do that, there is no need for a wait_for_catchup() before stopping  
the node.  The test wants to check that a timeline jump can be achieved  
when reconnecting a standby to a promoted standby in the same cluster,  
hence an immediate stop of the primary is not required.  
  
This failure is harder to reach than the previous instability of  
009_twophase, still the buildfarm has been able to detect this failure  
at least once.  I have tried Alexander Lakhin's test trick with the  
bgwriter and very aggressive standby snapshots, but I could not  
reproduce it directly.  It is reachable, as the buildfarm has proved.  
  
Backpatch down to all supported branches, and this problem can lead to  
spurious failures in the buildfarm.  
  
Discussion: https://postgr.es/m/493401a8-063f-436a-8287-a235d9e065fc@gmail.com  
Backpatch-through: 14  

commit   : e0a9c6463509babfa4dc65aab8aef560e73d85ed    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 4 Mar 2026 15:04:53 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 4 Mar 2026 15:04:53 +0100    

Author: Florin Irion <florin.irion@enterprisedb.com>  
Discussion: https://postgr.es/m/c6fff161-9aee-4290-9ada-71e21e4d84de@gmail.com  

commit   : ffe53037dff757a9e866966ab2741ec762df51c4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 4 Mar 2026 11:06:43 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 4 Mar 2026 11:06:43 +0200    

This reduces maintenance overhead, as we no longer need to update the  
dummy expected output file every time the .sql file changes.  
  
Discussion: https://www.postgresql.org/message-id/1009073.1772551323@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : bce98e49e8ace62c1018dc24dec443a50b347cb3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Mar 2026 16:31:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Mar 2026 16:31:05 +0900    

The phase of the test where we want to check that 2PC transactions  
prepared on a primary can be committed on a promoted standby relied on  
an immediate stop of the primary.  This logic has a race condition: it  
could be possible that some records (most likely standby snapshot  
records) are generated on the primary before it finishes its shutdown,  
without the promoted standby know about them.  When the primary is  
recycled as new standby, the test could fail because of a timeline fork  
as an effect of these extra records.  
  
This fix takes care of the instability by doing a clean stop of the  
primary instead of a teardown (aka immediate stop), so as all records  
generated on the primary are sent to the promoted standby and flushed  
there.  There is no need for a teardown of the primary in this test  
scenario: the commit of 2PC transactions on a promoted standby do not  
care about the state of the primary, only of the standby.  
  
This race is very hard to hit in practice, even slow buildfarm members  
like skink have a very low rate of reproduction.  Alexander Lakhin has  
come up with a recipe to improve the reproduction rate a lot:  
- Enable -DWAL_DEBUG.  
- Patch the bgwriter so as standby snapshots are generated every  
milliseconds.  
- Run 009_twophase tests under heavy parallelism.  
  
With this method, the failure appears after a couple of iterations.  
With the fix in place, I have been able to run more than 50 iterations  
of the parallel test sequence, without seeing a failure.  
  
Issue introduced in 30820982b295, due to a copy-pasto coming from the  
surrounding tests.  Thanks also to Hayato Kuroda for digging into the  
details of the failure.  He has proposed a fix different than the one of  
this commit.  Unfortunately, it relied on injection points, feature only  
available in v17.  The solution of this commit is simpler, and can be  
applied to v14~v16.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/b0102688-6d6c-c86a-db79-e0e91d245b1a@gmail.com  
Backpatch-through: 14  

commit   : 7ab6ac1d7f50eb4a36280cbbee3be68bc19d28ca    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2026 14:47:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2026 14:47:41 +0900    

Clarify the documentation of COMMENT ON to state that specifying an empty  
string is treated as NULL, meaning that the comment is removed.  
  
This makes the behavior explicit and avoids possible confusion about how  
empty strings are handled.  
  
Also adds regress test cases that use empty string to remove a comment.  
  
Backpatch to all supported versions.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Reviewed-by: Shengbin Zhao <zshengbin91@gmail.com>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: zhangqiang <zhang_qiang81@163.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/26476097-B1C1-4BA8-AA92-0AD0B8EC7190@gmail.com  
Backpatch-through: 14  

commit   : 858c83b3e666752710516240845b493f9c0eb60d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 11:10:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 11:10:41 +0900    

This commit adds a new test module called "test_custom_types", that can  
be used to stress code paths related to custom data type  
implementations.  
  
Currently, this is used as a test suite to validate the set of fixes  
done in 3b7a6fa15720, that requires some typanalyze callbacks that can  
force very specific backend behaviors, as of:  
- typanalyze callback that returns "false" as status, to mark a failure  
in computing statistics.  
- typanalyze callback that returns "true" but let's the backend know  
that no interesting stats could be computed, with stats_valid set to  
"false".  
  
This could be extended more in the future if more problems are found.  
For simplicity, the module uses a fake int4 data type, that requires a  
btree operator class to be usable with extended statistics.  The type is  
created by the extension, and its properties are altered in the test.  
  
Like 3b7a6fa15720, this module is backpatched down to v14, for coverage  
purposes.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/aaDrJsE1I5mrE-QF@paquier.xyz  
Backpatch-through: 14  

commit   : 038c7d4a3b244cbbcc6a31a4f925eb175358a6c3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 09:38:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 09:38:47 +0900    

This commit addresses two defects regarding extended statistics on  
expressions:  
- When building extended statistics in lookup_var_attr_stats(), the call  
to examine_attribute() did not account for the possibility of a NULL  
return value.  This can happen depending on the behavior of a typanalyze  
callback — for example, if the callback returns false, if no rows are  
sampled, or if no statistics are computed.  In such cases, the code  
attempted to build MCV, dependency, and ndistinct statistics using a  
NULL pointer, incorrectly assuming valid statistics were available,  
which could lead to a server crash.  
- When loading extended statistics for expressions,  
statext_expressions_load() did not account for NULL entries in the  
pg_statistic array storing expression statistics.  Such NULL entries can  
be generated when statistics collection fails for an expression, as may  
occur during the final step of serialize_expr_stats().  An extended  
statistics object defining N expressions requires N corresponding  
elements in the pg_statistic array stored for the expressions, and some  
of these elements can be NULL.  This situation is reachable when a  
typanalyze callback returns true, but sets stats_valid to indicate that  
no useful statistics could be computed.  
  
While these scenarios cannot occur with in-core typanalyze callbacks, as  
far as I have analyzed, they can be triggered by custom data types with  
custom typanalyze implementations, at least.  
  
No tests are added in this commit.  A follow-up commit will introduce a  
test module that can be extended to cover similar edge cases if  
additional issues are discovered.  This takes care of the core of the  
problem.  
  
Attribute and relation statistics already offer similar protections:  
- ANALYZE detects and skips the build of invalid statistics.  
- Invalid catalog data is handled defensively when loading statistics.  
  
This issue exists since the support for extended statistics on  
expressions has been added, down to v14 as of a4d75c86bf15.  Backpatch  
to all supported stable branches.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Corey Huinker <corey.huinker@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/aaDrJsE1I5mrE-QF@paquier.xyz  
Backpatch-through: 14  

commit   : e72bde9017c0bbac6e54ebc6cc58cde96855d289    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 27 Feb 2026 17:05:06 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 27 Feb 2026 17:05:06 +0900    

This commit also rephrases this comment to improve readability.  
  
Oversight in commit 6136e94dc.  
  
Reported-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Author: Andreas Karlsson <andreas@proxel.se>  
Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK16pDnM_wU3kmquPj-M9MYqG3y0BdntRZ0eytqbCaFY3WQ%40mail.gmail.com  
Backpatch-through: 14  

commit   : 058710d415ee5bab4daf6be5c33149a32066384a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 26 Feb 2026 12:26:32 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 26 Feb 2026 12:26:32 -0800    

Commit 84d5efa7e3 missed some multibyte issues caused by short-circuit  
logic in the callers. The callers assumed that if the predicate string  
is longer than the label string, then it couldn't possibly be a match,  
but it can be when using case-insensitive matching (LVAR_INCASE) if  
casefolding changes the byte length.  
  
Fix by refactoring to get rid of the short-circuit logic as well as  
the function pointer, and consolidate the logic in a replacement  
function ltree_label_match().  
  
Discussion: https://postgr.es/m/02c6ef6cf56a5013ede61ad03c7a26affd27d449.camel@j-davis.com  
Backpatch-through: 14  

commit   : 746dae69c3d8192c83a1ad310e9303449a0c6083    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Feb 2026 12:26:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Feb 2026 12:26:52 -0500    

In commits 1d97e4788 et al, I forgot that pre-v17 branches  
require updating Solution.pm when changing the set of  
symbols generated in pg_config.h.  Per buildfarm.  

commit   : 231570d33581e34cdfbacfa0f89a3d6fff790ef3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Feb 2026 12:06:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Feb 2026 12:06:58 -0500    

Otherwise, this would break if using C and C++ compilers from  
different families and they understand different options.  It already  
used the right flags for compiling, this is only for linking.  Also,  
the meson setup already did this correctly.  
  
Back-patch of v18 commit 365b5a345 into older supported branches.  
At the time we were only aware of trouble in v18, but as shown  
by buildfarm member siren, older branches can hit the problem too.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://www.postgresql.org/message-id/228700.1722717983@sss.pgh.pa.us  
Discussion: https://postgr.es/m/3109540.1771698685@sss.pgh.pa.us  
Backpatch-through: 14-17  

commit   : e0565630665f0f40def0f01f39ae282b81c4cb9b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 25 Feb 2026 18:13:22 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 25 Feb 2026 18:13:22 -0800    

Settings that ran the new test euc_kr.sql to completion would fail these  
older src/pl tests.  Use alternative expected outputs, for which psql  
\gset and \if have reduced the maintenance burden.  This fixes  
"LANG=ko_KR.euckr LC_MESSAGES=C make check-world".  (LC_MESSAGES=C fixes  
IO::Pty usage in tests 010_tab_completion and 001_password.)  That file  
is new in commit c67bef3f3252a3a38bf347f9f119944176a796ce.  Back-patch  
to v14, like that commit.  
  
Discussion: https://postgr.es/m/20260217184758.da.noahmisch@microsoft.com  
Backpatch-through: 14  

commit   : ec84a1f16f2838830d4ca37e3ea1f40faf3e4e52    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Feb 2026 09:02:53 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Feb 2026 09:02:53 +0900    

The documentation for the INCLUDING COMMENTS option of the LIKE clause  
in CREATE TABLE was inaccurate and incomplete. It stated that comments for  
copied columns, constraints, and indexes are copied, but regarding comments  
on constraints in reality only comments on CHECK and NOT NULL constraints  
are copied; comments on other constraints (such as primary keys) are not.  
In addition, comments on extended statistics are copied, but this was not  
documented.  
  
The CREATE FOREIGN TABLE documentation had a similar omission: comments  
on extended statistics are also copied, but this was not mentioned.  
  
This commit updates the documentation to clarify the actual behavior.  
The CREATE TABLE reference now specifies that comments on copied columns,  
CHECK constraints, NOT NULL constraints, indexes, and extended statistics are  
copied. The CREATE FOREIGN TABLE reference now notes that comments on  
extended statistics are copied as well.  
  
Backpatch to all supported versions. Documentation updates related to  
CREATE FOREIGN TABLE LIKE and NOT NULL constraint comment copying are  
not applied to v17 and earlier, since those features were introduced in v18.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwHSOSGcaYDvHF8EYCUCfGPjbRwGFsJ23cx5KbJ1X6JouQ@mail.gmail.com  
Backpatch-through: 14  

commit   : 5d2dec77efaf98049b24efd716f5cc677405a9e2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Feb 2026 08:46:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Feb 2026 08:46:12 +0900    

Previously, when one process woke another that was waiting on a lock,  
ProcWakeup() incorrectly cleared its own waitStart field (i.e.,  
MyProc->waitStart) instead of that of the process being awakened.  
As a result, the awakened process retained a stale lock-wait start timestamp.  
  
This did not cause user-visible issues. pg_locks.waitstart was reported as  
NULL for the awakened process (i.e., when pg_locks.granted is true),  
regardless of the waitStart value.  
  
This bug was introduced by commit 46d6e5f56790.  
  
This commit fixes this by resetting the waitStart field of the process  
being awakened in ProcWakeup().  
  
Backpatch to all supported branches.  
  
Reported-by: Chao Li <li.evan.chao@gmail.com>  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: ji xu <thanksgreed@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/537BD852-EC61-4D25-AB55-BE8BE46D07D7@gmail.com  
Backpatch-through: 14  

commit   : ff9bd96754f171a9277a13de7e0dea7349b57278    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2026 11:57:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2026 11:57:26 -0500    

Although clang claims to be compatible with gcc's printf format  
archetypes, this appears to be a falsehood: it likes __syslog__  
(which gcc does not, on most platforms) and doesn't accept  
gnu_printf.  This means that if you try to use gcc with clang++  
or clang with g++, you get compiler warnings when compiling  
printf-like calls in our C++ code.  This has been true for quite  
awhile, but it's gotten more annoying with the recent appearance  
of several buildfarm members that are configured like this.  
  
To fix, run separate probes for the format archetype to use with the  
C and C++ compilers, and conditionally define PG_PRINTF_ATTRIBUTE  
depending on __cplusplus.  
  
(We could alternatively insist that you not mix-and-match C and  
C++ compilers; but if the case works otherwise, this is a poor  
reason to insist on that.)  
  
This commit back-patches 0909380e4 into supported branches.  
  
Discussion: https://postgr.es/m/986485.1764825548@sss.pgh.pa.us  
Discussion: https://postgr.es/m/3988414.1771950285@sss.pgh.pa.us  
Backpatch-through: 14-18  

commit   : 244c047205bb770f877ea525ea8bd7cd3cdad076    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2026 11:19:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2026 11:19:50 -0500    

Newest versions of gcc+glibc are able to detect cases where code  
implicitly casts away const by assigning the result of strchr() or  
a similar function applied to a "const char *" value to a target  
variable that's just "char *".  This of course creates a hazard of  
not getting a compiler warning about scribbling on a string one was  
not supposed to, so fixing up such cases is good.  
  
This patch fixes a dozen or so places where we were doing that.  
Most are trivial additions of "const" to the target variable,  
since no actually-hazardous change was occurring.  
  
Thanks to Bertrand Drouvot for finding a couple more spots than  
I had.  
  
This commit back-patches relevant portions of 8f1791c61 and  
9f7565c6c into supported branches.  However, there are two  
places in ecpg (in v18 only) where a proper fix is more  
complicated than seems appropriate for a back-patch.  I opted  
to silence those two warnings by adding casts.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/1324889.1764886170@sss.pgh.pa.us  
Discussion: https://postgr.es/m/3988414.1771950285@sss.pgh.pa.us  
Backpatch-through: 14-18  

commit   : 5d311d6a845ae4423a716ae422f1462128c33125    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2026 10:51:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2026 10:51:42 -0500    

The test added by commit 4b760a181 assumed that a table's physical  
row order would be predictable after an UPDATE.  But a non-heap table  
AM might produce some other order.  Even with heap AM, the assumption  
seems risky; compare a3fd53bab for instance.  Adding an ORDER BY is  
cheap insurance and doesn't break any goal of the test.  
  
Author: Pavel Borisov <pashkin.elfe@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CALT9ZEHcE6tpvumScYPO6pGk_ASjTjWojLkodHnk33dvRPHXVw@mail.gmail.com  
Backpatch-through: 14  

commit   : c47744ede01c45dcf73c420a4fc393965909c8ab    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 24 Feb 2026 14:01:58 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 24 Feb 2026 14:01:58 -0800    

The grease patch in 4966bd3ed found its first problem: prior to the  
February 2018 patch releases, no server knew how to negotiate protocol  
versions, so pg_upgrade needs to take that into account when speaking to  
those older servers.  
  
This will be true even after the grease feature is reverted; we don't  
need anyone to trip over this again in the future. Backpatch so that all  
supported versions of pg_upgrade can gracefully handle an update to the  
default protocol version. (This is needed for any distributions that  
link older binaries against newer libpqs, such as Debian.) Branches  
prior to 18 need an additional version check, for the existence of  
max_protocol_version.  
  
Per buildfarm member crake.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAOYmi%2B%3D4QhCjssfNEoZVK8LPtWxnfkwT5p-PAeoxtG9gpNjqOQ%40mail.gmail.com  
Backpatch-through: 14