PostgreSQL 15.18 commit log

commit   : 005c1971a2926fbb9caf5a1ad634cd17a42bfd3c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 15:49:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 15:49:58 -0400    

commit   : 78f1b471f991307cea4aa0d95f2d957601a1b8cd    
  
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   : dc6c85ff4d1bb97cd06b11bb19b7b69cf7952f02    
  
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   : fc1fd3d970d400fcc37979bcb012d4657dbab1f5    
  
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   : 8053235abe86e8ed4f592ac752903f52369711ee    
  
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    

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   : e3a1f83eae4fc1d8281908322189d4f95de873a7    
  
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   : e49e9590d984d60bfd95b438e5c6c07d08e9d661    
  
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   : fb0bc321d3a9a87c8fda23185bf581a373860da8    
  
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   : 0c83fe8e4c84471e32254de2a1ef5e52921bebb7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 137013f6084239bd824271c8c95beea496f4e2be    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 08c397b0234b09084195930dc41d125eca5d334d    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : c3fff3950f215732365c379bb87bc13d453eb4a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 126a236ba87c749bfcf0b74ef67f9682cd3d4d19    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : c95275f18bee5caac175d314cbd997dd68f160f3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 9dcfcb92fff82b398f2ba0c03eb7bea9c197aab2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 84a9f2641d8c69503505c3f96d9d89ab625c5dec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : d106295b60578b31da37b7ae95c694e14774411b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 3fb66d3022f7bf89143f1452e030d86bd0e1f58e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 16fda4df63226fe0d5239fe13cdb5aec580c133f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 4032c9d98ab767fcbc5fa65b6ab1a39412b68912    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : b11c3eadf765664a9b5b6d099f05fc26efbb5a83    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 7fdb0907e09318d83e6a0a1f9798b492fd3ff1c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : bfc5cea76d25fa7d2a881699121a09eebc0d5ec6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : d75b1dc96f0a15b71dd832285fafaac7a755f4cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 7fe36569395909d18549e9d3098e6ef18d421596    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 9c2fa5b6ab6fbf717eb2d8fb85d8c8fb97e4e965    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -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   : 9e351c4c5168dc6d91ff19bf428a7be6516f1307    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2026 13:13:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2026 13:13:25 +0200    

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

commit   : dc36d05ae1c0172363c198f61264ccf0ce2259b8    
  
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   : 34c18a22556e5274c6c1ab708fe01e47eb02b6a1    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 5 May 2026 18:55:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 5 May 2026 18:55:05 +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   : bab4f7fa56217ff6cbde3b79a5104d2c942b8582    
  
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   : 872c9fae78bc4a98d447940db01a5ca83c461804    
  
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   : ca259b08409096811b57b1c13dd5cccf9b2b83b1    
  
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   : 6916f44100515b7d939f034a2c78caef4047209e    
  
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   : e4f035de455e54653a811fda35d1458ec73def60    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2026 13:10:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2026 13:10:48 +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   : 76d15a7ee9de91afda672cd7ed56cdcd9909f4ef    
  
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   : 76cdf922b0e7525efcc6181dc46e380fc40721e9    
  
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   : c76287fa0d579da7cc950dd0f66f9cc4cedf48a3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2026 16:17:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2026 16:17:29 +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   : e28fc73d5c14b6736d60667fea424cf4e6373ade    
  
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   : 622f8b53014ed62eda857cec192978db8cca8a70    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 24 Apr 2026 14:04:55 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 24 Apr 2026 14:04:55 +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   : d7241c156d41944f331554b382e9719994fe334c    
  
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   : e1830ebf52190ad48649c69ebd2a02fc5ba89366    
  
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   : 34ebeb15c8b18330d992bc672c1192b0d9436fc7    
  
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   : f60d25986288f453360cb5d1902945d9417d0da0    
  
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   : 0b196d3db7138967d135b72ed9296a9ad7c06846    
  
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   : f852c9093fb0cc10e6e36c562fc00b4ca3b5e242    
  
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   : 0859000d0d7195738b1c52e430b25fc72642cd73    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2026 10:34:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2026 10:34:38 +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   : 8a5729a8ef28e26e5e9cb6829e6b2a77feabaa69    
  
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   : 7062bd577ec98d1e6f6a0fb7c8b859d0c32a6061    
  
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   : 23cebf672e197d98d4fb6ffca2318edae4eadcc5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Apr 2026 09:40:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Apr 2026 09:40:07 +0900    

When the startup process exists with a FATAL error during PM_STARTUP,  
the postmaster called ExitPostmaster() directly, assuming that no other  
processes are running at this stage.  Since 7ff23c6d277d, this  
assumption is not true, as the checkpointer, the background writer, the  
IO workers and bgworkers kicking in early would be around.  
  
This commit removes the startup-specific shortcut happening in  
process_pm_child_exit() for a failing startup process during PM_STARTUP,  
falling down to the existing exit() flow to signal all the started  
children with SIGQUIT, so as we have no risk of creating orphaned  
processes.  
  
This required an extra change in HandleFatalError() for v18 and newer  
versions, as an assertion could be triggered for PM_STARTUP.  It is now  
incorrect.  In v17 and older versions, HandleChildCrash() needs to be  
changed to handle PM_STARTUP so as children can be waited on.  
  
While on it, fix a comment at the top of postmaster.c.  It was claiming  
that the checkpointer and the background writer were started after  
PM_RECOVERY.  That is not the case.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAJTYsWVoD3V9yhhqSae1_wqcnTdpFY-hDT7dPm5005ZFsL_bpA@mail.gmail.com  
Backpatch-through: 15  

commit   : 954e468bbaa809bbe70b16eb6982327ba97c7ccd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 Apr 2026 08:44:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 Apr 2026 08:44:19 +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 or users granted the appropriate  
SET privilege, 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   : 4198b2d04b3a290793ca52aebe025cb1b138c85c    
  
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   : 78f8fbc8ab5fd9d67187e1fb1876538c55e8ddeb    
  
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   : 6b59bd710be18636642d01da623bb61b82949152    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2026 05:09:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2026 05:09:13 +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   : c6d3f05851a94655a5e2194c03553824350a4782    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 Apr 2026 17:03:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 Apr 2026 17:03:10 +0900    

Three routines in pgstat_database.c incorrectly ignore the database OID  
provided by their caller, using MyDatabaseId instead:  
- pgstat_report_connect()  
- pgstat_report_disconnect()  
- pgstat_reset_database_timestamp()  
  
The first two functions, for connection and disconnection, each have a  
single caller that already passes MyDatabaseId.  This was harmless,  
still incorrect.  
  
The timestamp reset function also has a single caller, but in this case  
the issue has a real impact: it fails to reset the timestamp for the  
shared-database entry (datid=0) when operating on shared objects.  This  
situation can occur, for example, when resetting counters for shared  
relations via pg_stat_reset_single_table_counters().  
  
There is currently one test in the tree that checks the reset of a  
shared relation, for pg_shdescription, we rely on it to check what is  
stored in pg_stat_database.  As stats_reset may be NULL, two resets are  
done to provide a baseline for comparison.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Dapeng Wang <wangdp20191008@gmail.com>  
Discussion: https://postgr.es/m/ABBD5026-506F-4006-A569-28F72C188693@gmail.com  
Backpatch-through: 15  

commit   : c88ad3a2122eae875b77eb5cba3b7bda5c92f251    
  
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   : 7363e932c4ddb2746dd8676ef0f5af606134dc84    
  
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   : 4da71fc37a20eb7bfc339197ad6c9b95af46c59c    
  
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   : 07e833e3cff3da136980c7a4e30e965f825ae83c    
  
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   : 963fccc09cc6b3fe6f0a6246e5af16c9d9af100d    
  
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   : c00ea2b5b4f16496d0f8545266af0b9945e54800    
  
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   : ba8b89123694cce4a2f1d52dc11450e2bbcd9ea4    
  
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   : 811f3263a48d98a0802e72d8436ad66f0a0aa211    
  
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   : 6b2e091f021445ee34cd82d848f88d4bf126016b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2026 16:17:39 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2026 16:17:39 +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   : d3bb7841b4be7e7aad0bd666117c022acb5a2c64    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Mar 2026 09:12:40 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Mar 2026 09:12:40 -0400    

astreamer_tar_parser_content() sent the wrong data pointer when  
forwarding MEMBER_TRAILER padding to the next streamer.  After  
astreamer_buffer_until() buffers the padding bytes, the 'data'  
pointer has been advanced past them, but the code passed 'data'  
instead of bbs_buffer.data.  This caused the downstream consumer  
to receive bytes from after the padding rather than the padding  
itself, and could read past the end of the input buffer.  
  
astreamer_gzip_decompressor_content() only checked for  
Z_STREAM_ERROR from inflate(), silently ignoring Z_DATA_ERROR  
(corrupted data) and Z_MEM_ERROR (out of memory).  Fix by  
treating any return other than Z_OK, Z_STREAM_END, and  
Z_BUF_ERROR as fatal.  
  
astreamer_gzip_decompressor_free() missed calling inflateEnd() to  
release zlib's internal decompression state.  
  
astreamer_tar_parser_free() neglected to pfree() the streamer  
struct itself, leaking it.  
  
astreamer_extractor_content() did not check the return value of  
fclose() when closing an extracted file.  A deferred write error  
(e.g., disk full on buffered I/O) would be silently lost.  
  
Discussion: https://postgr.es/m/results/98c6b630-acbb-44a7-97fa-1692ce2b827c@dunslane.net  
  
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>  
  
Backpatch-through: 15  

commit   : 92cf11171baf64723412c996c641e6cc124d11d6    
  
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   : 246c296f00ae923d0e09f03ec280b85ca382749a    
  
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   : 9cee8644f1aa4eb571946d65e660495fbe43e42d    
  
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   : a5f412107f98721bd8cd624a05d5e7b4df99d7a8    
  
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   : 5540f9c430f65631887d31fa26dfdfa576c1c17e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Mar 2026 18:06:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Mar 2026 18:06:48 -0400    

Send the correct amount of data to the next astreamer, not the  
whole allocated buffer size.  This bug escaped detection because  
in present uses the next astreamer is always a tar-file parser  
which is insensitive to trailing garbage.  But that may not  
be true in future uses.  
  
Author: Andrew Dunstan <andrew@dunslane.net>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2178517.1774064942@sss.pgh.pa.us  
Backpatch-through: 15  

commit   : 3a35ab1d0126802045e7133788647a549ea6fa98    
  
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   : fa9f2e31756225f4e17103d22d9e651bf8d41941    
  
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   : 34baa313e31788e3a0ba251d5649b6e3ccfced26    
  
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   : ce06b5740ef944094f7793bac3b015901156aa5f    
  
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   : 0b0041b942f7ecca56efec4cb882caec0247984f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2026 16:06:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2026 16:06:50 +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   : d0f4b6350d843c6ad7ebf84fbca06e595b780ad3    
  
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   : 46c93b705644ad0746dfbd6e0b737fd03e41817f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2026 13:46:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2026 13:46:37 +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   : 42734f29661520f698bf51e408624d51618d0b0d    
  
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   : 9a42888a32fd2ebc3d8e39bbc450556c326c9db7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2026 14:43:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Mar 2026 14:43:21 -0500    

It looks like whoever wrote the astreamer (nee bbstreamer) code  
thought that pg_log_error() is equivalent to elog(ERROR), but  
it's not; it just prints a message.  So all these places tried to  
continue on after a compression or decompression error return,  
with the inevitable result being garbage output and possibly  
cascading error messages.  We should use pg_fatal() instead.  
  
These error conditions are probably pretty unlikely in practice,  
which no doubt accounts for the lack of field complaints.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/1531718.1772644615@sss.pgh.pa.us  
Backpatch-through: 15  

commit   : 8bfaae6fb20cf3029f42f2760f9d90a84e4448d7    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 5 Mar 2026 19:47:20 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 5 Mar 2026 19:47:20 +0200    

This branch missed the IsolationUsesXactSnapshot() check.  That led to EPQ on  
repeatable read and serializable isolation levels.  This commit fixes the  
issue and provides a simple isolation check for that.  Backpatch through v15  
where MERGE statement was introduced.  
  
Reported-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAPpHfdvzZSaNYdj5ac-tYRi6MuuZnYHiUkZ3D-AoY-ny8v%2BS%2Bw%40mail.gmail.com  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Backpatch-through: 15  

commit   : 87da83bde9f8b57e01e5cd1a7716d9db6696ea27    
  
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   : 270e7b4ff519de076f3da5b88ebaed8b579ebd3c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2026 10:06:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2026 10:06:06 +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   : 4548e8746631e03d6e8c22eb708c1e5f410126b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Mar 2026 12:08:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Mar 2026 12:08:37 -0500    

The code path in astreamer_lz4_decompressor_content() that updated  
the output pointers when the output buffer isn't full was wrong.  
It advanced next_out by bytes_written, which could include previous  
decompression output not just that of the current cycle.  The  
correct amount to advance is out_size.  While at it, make the  
output pointer updates look more like the input pointer updates.  
  
This bug is pretty hard to reach, as it requires consecutive  
compression frames that are too small to fill the output buffer.  
pg_dump could have produced such data before 66ec01dc4, but  
I'm unsure whether any files we use astreamer with would be  
likely to contain problematic data.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/0594CC79-1544-45DD-8AA4-26270DE777A7@gmail.com  
Backpatch-through: 15  

commit   : 988b9588dadbcc3f53bd4ba853a43c9208d450f2    
  
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   : a6b11ac4c42d83e0821d0b1863d4d1ebbbc1eabb    
  
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   : be233b301e60f5f305296d65cf7bcfd4821319ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Mar 2026 16:31:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Mar 2026 16:31:03 +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   : 4574dd44da3c0a922ebd7117ee5229dbe3f2c84f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2026 14:47:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2026 14:47:10 +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   : 8fc45ac5d91a0834f6bca1405309749e6ec687dd    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 2 Mar 2026 13:12:25 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 2 Mar 2026 13:12:25 -0600    

Presently, the GUC check hook for basic_archive.archive_directory  
checks that the specified directory exists.  Consequently, if the  
directory does not exist at server startup, archiving will be stuck  
indefinitely, even if it appears later.  To fix, remove this check  
from the hook so that archiving will resume automatically once the  
directory is present.  basic_archive must already be prepared to  
deal with the directory disappearing at any time, so no additional  
special handling is required.  
  
Reported-by: Олег Самойлов <splarv@ya.ru>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Sergei Kornilov <sk@zsrv.org>  
Discussion: https://postgr.es/m/73271769675212%40mail.yandex.ru  
Backpatch-through: 15  

commit   : 8eedbc2cc4b37a5e0a5f6a158ddc77b8059930bc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 11:10:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 11:10:39 +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   : f033abc6c4f2639f0e498ff256f6c9407793abbb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 09:38:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 09:38:46 +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   : cf370919a9963ac7d821caf491fdc6f9da87b178    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 27 Feb 2026 17:05:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 27 Feb 2026 17:05:05 +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   : 2b993167fc85fb41729dc0980639504ccc356e02    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 26 Feb 2026 12:26:13 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 26 Feb 2026 12:26:13 -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   : e22821c7bdf3577d44bc8dd311acc01d6e6d609a    
  
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   : 41d75b9a4a1c7f84bafd331428c005e5743bac3d    
  
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   : 44d29f5c6c0febc8ef3c88da3eab099b89546296    
  
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   : e81c61ee4a8e9df0f4d0a9fd0024947a1c5cfc84    
  
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   : 74ee3e9e73656497d0bbf57ff6d839b37feefb09    
  
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   : 7e788a585a6c29b12fcb53a313ac5c4d080c36e8    
  
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   : cc9c22a5160a260551a0316078bef55954ba7e9a    
  
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   : b57d35dde7dde5e94ce534a6f2a0a24cb5ccb2c1    
  
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   : e726620d208ee1fca37a6cbfe0fc9a7031ff659e    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 24 Feb 2026 14:01:54 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 24 Feb 2026 14:01:54 -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