PostgreSQL 16.14 commit log

commit   : 0d1c00c624fa7367d4a895f44381887757289682    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 15:48:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 15:48:18 -0400    

commit   : 878e171244f7c1280201a04aa420b78c4a2d08d3    
  
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   : e42598a41e76ff12293e3aaeeeb5c5696a93f642    
  
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   : 6f0bff33d780aac82d147a309afe505d79974086    
  
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   : 710995782fa388f3878a86e1d9ed68db8abc4276    
  
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    

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   : 614474996a48b7fc7f83faf9a940600041a80d67    
  
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    

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   : e24fb3247644a9baef72758806d83ec59d914781    
  
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    

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   : c259731242148834ac053dc3f6a4ffc3b317aa9a    
  
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    

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   : 6778af13e283c593fe0c16aeb6ed953a080e582b    
  
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   : 32c525eb674bc8fff10f9ea64774525aaae39de5    
  
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   : d92852d624f3d2df4b1140349350fa2c1fdc6571    
  
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   : 79b7847c729bcbbe7ae2af1742adc6db86904932    
  
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   : 24e0e32544c3664447555eda8f56c4e0fffcdaa4    
  
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   : 248a433cd10759ef968ebed655d19dd1ef129bf6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:50 -0700    

ALTER SUBSCRIPTION ... REFRESH PUBLICATION interpolates schema and  
relation names into SQL without quoting them.  A crafted subscriber  
relation name can inject arbitrary SQL on the publisher.  Test such a  
name.  Back-patch to v16, where commit  
875693019053b8897ec3983e292acbb439b088c3 first appeared.  
  
Reported-by: Pavel Kohout <pavel.kohout@aisle.com>  
Author: Pavel Kohout <pavel.kohout@aisle.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Backpatch-through: 16  
Security: CVE-2026-6638  

commit   : 00e27235e5ef6596acc94ec60eb17f74810bf817    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 1604939b2210b93e34572ee6df499d103849c53e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 5c1069c35b49227f955735ea5f2a2ee1c9c48a63    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 47dae5e74025c02a66966b2c44617dacce93b69d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 66cf26b9e4be1b46a5039bb7ea37f65d1e52e763    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : c2e6ef86317d372f8bbca42b830c70ff3f0da275    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : aff71f87ba78e8fe5fb266ecfce692f2e23a5d6a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : f20b840813f579062cc5de0a9a266dc8d5590fc7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : a4f089c79b3f7c1790d400ec72a9258d55165dbf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : cfb610eaa02583fad12558af2eb36dab015cef02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 924b3e94390de04b0fbb55edce8a29873a5062e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 5919e0005b6f23292450a44f1db5c6b2e2bb0ddf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 6b6b26fdecc8a8e0b57ab9f0e8a6ad6212ccba36    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 May 2026 05:13:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 May 2026 05:13:49 -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   : 3d2893a2c7bd7431f51d5e2eaa004eff800a5476    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2026 13:07:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2026 13:07:36 +0200    

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

commit   : 207ec28a1934b5fe72b102517f0abdc8a7cd4bea    
  
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   : 1352651c21ab5d5bf7aa85f1add0c39ad174a557    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 5 May 2026 18:55:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 5 May 2026 18:55:04 +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   : 5a24cef082a095aaeadb0b1672d8c1d912335261    
  
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   : 748fe9e6085c998fac693fdf216093657d0104cb    
  
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   : 54537de35873eaa4547ab2aa7168c6a935894643    
  
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   : 7e4c871f41814ebc694cebd544afee5c5a172e0e    
  
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   : 8f2429ff24feeec6ddcf0f20f125aa35ebced0c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2026 13:10:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2026 13:10:42 +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   : 7bb5196358063c61a554052a1ea0ee82b61efabb    
  
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   : 3b35c10a4d503a64a6bc110de3330a337bc1a362    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Apr 2026 18:44:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Apr 2026 18:44:45 +0900    

Upon a failure of sync_file_range(), EINTR was checked based on the  
returned result of the routine rather than its errno.  sync_file_range()  
returns -1 on failure, making the check a no-op, invalidating the retry  
attempt in this case.  
  
Oversight in 0d369ac65004.  
  
Author: DaeMyung Kang <charsyam@gmail.com>  
Discussion: https://postgr.es/m/20260429151811.1810874-1-charsyam@gmail.com  
Backpatch-through: 16  

commit   : 7a8e35a4c9647e97ab44a3059be21903cdf6bfeb    
  
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   : 4b062bd442ad622eba25e001e692313a556e81c6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2026 16:17:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2026 16:17:28 +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   : 0465c999ec4f337b46d47552b1b007d5d74229db    
  
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   : a2a0060d5d8fb64ffdb43ff768762a3f4674b78d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 24 Apr 2026 14:04:31 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 24 Apr 2026 14:04:31 +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   : 07e96aeff93f43364020f21836c97aff4f6ff6ba    
  
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   : 526d9ca619cc466fd637a7545c0d3ad3ea7bc6cf    
  
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   : 06e304524d5c19223697a78ffaa8c7610bc6a365    
  
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   : e1e60f148a3aa937f1bf92dd50bb4b24051fd0e2    
  
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   : 42383d32d78acb13cc9a2245f037a73b39d4573b    
  
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   : 17f72e037f20354e3b4a4309dde02a7592075d4b    
  
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   : 313355d68016a4c83bcbcb16a743dc7a8e54f8a1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2026 10:34:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2026 10:34:37 +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   : 5dbc5bb106c086b60617b7599deb9cd33bf20275    
  
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   : 07b257189ea4fc949a36fd341ba2ba6b49e5f718    
  
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   : 2d347f2cd71364d94cb118310492cb4dc022e05f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Apr 2026 09:40:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Apr 2026 09:40:06 +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   : 8916a4bcc73f289f1ff6ef748a0d70e99cbdc8b6    
  
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   : 798dabe8388764a8a9979f5c91237f807cd09188    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2026 19:24:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2026 19:24:46 -0400    

Commit cfcd57111 et al fell over under Valgrind testing.  
(It seems to be enough to #define USE_VALGRIND, you don't actually  
need to run it under Valgrind to see failures.)  The cause is that  
remove_rel_from_eclass updates each EquivalenceMember's em_relids,  
and those can be aliases of the left_relids or right_relids of some  
RestrictInfo in ec_sources.  If the update made em_relids empty then  
bms_del_member will have pfree'd the relid set, so that the subsequent  
attempt to clean up ec_sources accesses already-freed memory.  
  
We missed seeing ill effects before cfcd57111 because (a) if the  
pfree happens then we will remove the EquivalenceMember altogether,  
making the source RestrictInfo no longer of use, and (b) the  
cleanup of ec_sources didn't touch left/right_relids before that.  
  
I'm unclear though on how cfcd57111 managed to pass non-USE_VALGRIND  
testing.  Apparently we managed to store another Bitmapset into the  
freed space before trying to access it, but you'd not think that would  
happen 100% of the time.  I think what USE_VALGRIND changes is that it  
makes list.c much more memory-hungry, so that the freed space gets  
claimed by some List node before a Bitmapset can be put there.  
  
This failure can be seen in v16, v17, and master, but oddly enough not  
v18.  That's because the SJE patch replaced the simple bms_del_members  
calls used here with adjust_relid_set, which is careful not to  
scribble on its input.  But commit 20efbdffe just recently put back  
the old coding and thus resurrected the problem.  
  
Discussion: https://postgr.es/m/458729.1776724816@sss.pgh.pa.us  
Backpatch-through: 16, 17, master  

commit   : d509be4ace9058d84ce39cca6b968e38cc56c19b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2026 14:48:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2026 14:48:23 -0400    

The original implementation of remove_rel_from_restrictinfo()  
thought it could skate by with removing no-longer-valid relid  
bits from only the clause_relids and required_relids fields.  
This is quite bogus, although somehow we had not run across a  
counterexample before now.  At minimum, the left_relids and  
right_relids fields need to be fixed because they will be  
examined later by clause_sides_match_join().  But it seems  
pretty foolish not to fix all the relid fields, so do that.  
  
This needs to be back-patched as far as v16, because the  
bug report shows a planner failure that does not occur  
before v16.  I'm a little nervous about back-patching,  
because this could cause unexpected plan changes due to  
opening up join possibilities that were rejected before.  
But it's hard to argue that this isn't a regression.  Also,  
the fact that this changes no existing regression test results  
suggests that the scope of changes may be fairly narrow.  
I'll refrain from back-patching further though, since no  
adverse effects have been demonstrated in older branches.  
  
Bug: #19460  
Reported-by: François Jehl <francois.jehl@pigment.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/19460-5625143cef66012f@postgresql.org  
Backpatch-through: 16  

commit   : d052f6c7d97fae1e5ecee74981fbcbba0f168a7d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Apr 2026 10:13:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Apr 2026 10:13:55 +0530    

Parallel apply workers previously failed to report statistics while  
waiting for new work in the main loop. This resulted in the stats from the  
most recent transaction remaining unbuffered, leading to arbitrary  
reporting delays—particularly when streamed transactions were infrequent.  
  
This commit ensures that statistics are explicitly flushed when the worker  
is idle, providing timely visibility into accumulated worker activity.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where it was introduced  
Discussion: https://postgr.es/m/TYRPR01MB1419579F217CC4332B615589594202@TYRPR01MB14195.jpnprd01.prod.outlook.com  

commit   : 482c5183450aef2374df78a685e5b6c5a829282b    
  
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   : 5ef61f417f176ec2894e81ed03987f8ca2c17cbb    
  
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   : 8167371704bd2ae26304878c1d6d167dabed0c71    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 14 Apr 2026 12:06:02 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 14 Apr 2026 12:06:02 -0700    

Missed by commit 1671f990dd66.  
  
Author: Andreas Karlsson <andreas@proxel.se>  
Discussion: https://postgr.es/m/118ca69e-47eb-42e1-83e9-72ccf40dd6fd@proxel.se  
Backpatch-through: 16  

commit   : caee654e05e886bf0198cdd8a1c021ca321999b8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2026 05:09:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2026 05:09:12 +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   : c7cdcbd3e6a72f858690ed7e69046cf2cd41fb19    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 Apr 2026 17:03:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 Apr 2026 17:03:08 +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   : e630f65d03047ccab67ebb0e20faa7f3f24b526b    
  
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   : 0fe032e6a666173a587bdd207e13e68a5c20d180    
  
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   : 3c7a6bbe63e2707c6bd50ccab64d68756e6b7c78    
  
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   : bb959269e382eb75f23f30607ba27b0c67b36111    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2026 13:14:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2026 13:14:50 -0400    

This code missed the need to update the combined state's  
nullbitmap if state1 already had a bitmap but state2 didn't.  
We need to extend the existing bitmap with 1's but didn't.  
This could result in wrong output from a parallelized  
array_agg(anyarray) calculation, if the input has a mix of  
null and non-null elements.  The errors depended on timing  
of the parallel workers, and therefore would vary from one  
run to another.  
  
Also install guards against integer overflow when calculating  
the combined object's sizes, and make some trivial cosmetic  
improvements.  
  
Author: Dmytro Astapov <dastapov@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFQUnFj2pQ1HbGp69+w2fKqARSfGhAi9UOb+JjyExp7kx3gsqA@mail.gmail.com  
Backpatch-through: 16  

commit   : 8354cd7ff5752035336f34149f97674c2399d905    
  
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   : 26f27c592c5da7f40efe733204396b15ea905f82    
  
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   : 009e1d303a65055d77912535a22471e611c41272    
  
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   : 59c139d53be3567ab9255a25f1f49c0facdcf503    
  
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   : a26ac902f662e81f9b8b8ba1e7b784d4ab82b05f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2026 12:02:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2026 12:02:08 -0400    

Before the major rewrite in commit c6e0fe1f2, AllocSetFree() would  
typically crash when asked to free an already-free chunk.  That was  
an ugly but serviceable way of detecting coding errors that led to  
double pfrees.  But since that rewrite, double pfrees went through  
just fine, because the "hdrmask" of a freed chunk isn't changed at all  
when putting it on the freelist.  We'd end with a corrupt freelist  
that circularly links back to the doubly-freed chunk, which would  
usually result in trouble later, far removed from the actual bug.  
  
This situation is no good at all for debugging purposes.  Fortunately,  
we can fix it at low cost in MEMORY_CONTEXT_CHECKING builds by making  
AllocSetFree() check for chunk->requested_size == InvalidAllocSize,  
relying on the pre-existing code that sets it that way just below.  
  
I investigated the alternative of changing a freed chunk's methodid  
field, which would allow detection in non-MEMORY_CONTEXT_CHECKING  
builds too.  But that adds measurable overhead.  Seeing that we didn't  
notice this oversight for more than three years, it's hard to argue  
that detecting this type of bug is worth any extra overhead in  
production builds.  
  
Likewise fix AllocSetRealloc() to detect repalloc() on a freed chunk,  
and apply similar changes in generation.c and slab.c.  (generation.c  
would hit an Assert failure anyway, but it seems best to make it act  
like aset.c.)  bump.c doesn't need changes since it doesn't support  
pfree in the first place.  Ideally alignedalloc.c would receive  
similar changes, but in debugging builds it's impossible to reach  
AlignedAllocFree() or AlignedAllocRealloc() on a pfreed chunk, because  
the underlying context's pfree would have wiped the chunk header of  
the aligned chunk.  But that means we should get an error of some  
sort, so let's be content with that.  
  
Per investigation of why the test case for bug #19438 didn't appear to  
fail in v16 and up, even though the underlying bug was still present.  
(This doesn't fix the underlying double-free bug, just cause it to  
get detected.)  
  
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: 16  

commit   : 1bd90c8879b6bb00284401f3eb2f5911abb13dca    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2026 16:17:14 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2026 16:17:14 +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   : 1590723f04c06ff2ff3194b8aaaca569be8b6931    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Mar 2026 09:12:28 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Mar 2026 09:12:28 -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   : 52edaf9d9b0231700f97bd13c6860dc63b9b2eff    
  
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   : f4210500156af10bf10d866630d9a2d68f6e4be1    
  
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   : 4c0ffe6244f2f487d89e132831ba34769aa018ed    
  
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   : 77dff5d937b192b85c55bce822e7413ff7dda6eb    
  
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   : 80785a527b9cf74b16cb5bb65355f94157124bf7    
  
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   : a19edb66a847b596a669941810f99686fb77a7b7    
  
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   : da21ecf5798c809fe06d2c5f00bc8b14ba8ed240    
  
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   : 6fab4fa541a74414b27bed9c01f6e618e793c7d1    
  
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   : 4f4025eac0b9a8d0b1a4b48db48f770313ea085e    
  
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   : 5f46c617e95f882cb977940f895dab8734c2d75b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2026 16:06:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Mar 2026 16:06:49 +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   : bb9dd2680348827deaa4055cbcfe81ae15b1d152    
  
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   : 0af5e64e9153afb3214140e5bbebf3dd1743d7ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2026 13:46:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Mar 2026 13:46:35 +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   : 82935467a0338e0e28acbd357c4c4c7f7aa2aab7    
  
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   : cce939c71c11e9434d96c60977bc805682f3d18d    
  
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   : f6e63d4b8b2ec5ff011c87f79f3efc8abe921263    
  
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   : f51821d9cf769d3f8f400dcef9f46ecd584e1403    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Mar 2026 12:55:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Mar 2026 12:55: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   : 8e3c377e284a22f3f0ce773f6141ff9ed3523cf9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2026 10:06:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Mar 2026 10:06:05 +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   : 415cc943ffdd591c513cc9c526d219095e72a278    
  
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   : 46c54d3d2f3ec0aaf04eaf5ea5eade08d4796b87    
  
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   : 65f5c451a3e1e95e457d62fc015af11b85704203    
  
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   : a7499ff5eb589c9aa530656fc074706e564ac819    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Mar 2026 16:31:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Mar 2026 16:31:01 +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   : 228addbbf2c13f8cc8f80bb6f0aa5bd7204e65e5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2026 14:45:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Mar 2026 14:45:52 +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   : 28c2b789652a8df0999d5dbfefa2482dafdcaaa1    
  
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   : a4649c50a8db58c19fa9a4f2ae12bef52b6c872b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Mar 2026 11:14:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Mar 2026 11:14:58 -0500    

In commits 29d75b25b et al, I made pg_dumpall's dumpRoleMembership  
logic treat a dangling grantor OID the same as dangling role and  
member OIDs: print a warning and skip emitting the GRANT.  This wasn't  
terribly well thought out; instead, we should handle the case by  
emitting the GRANT without the GRANTED BY clause.  When the source  
database is pre-v16, such cases are somewhat expected because those  
versions didn't prevent dropping the grantor role; so don't even  
print a warning that we did this.  (This change therefore restores  
pg_dumpall's pre-v16 behavior for these cases.)  The case is not  
expected in >= v16, so then we do print a warning, but soldiering on  
with no GRANTED BY clause still seems like a reasonable strategy.  
  
Per complaint from Robert Haas that we were now dropping GRANTs  
altogether in easily-reachable scenarios.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com  
Backpatch-through: 16  

commit   : c0676c8294f7ad8fe56d749e030e3316bf047a4b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 11:10:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 11:10:38 +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   : 04745ba9c72ee99bc284f9d690fb3c631f7574f5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 09:38:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Mar 2026 09:38:44 +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   : e0fd58a841995fb575f80e78c1d84f1e26beeefa    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 27 Feb 2026 17:05:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 27 Feb 2026 17:05:04 +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   : 3ed2c7ef7aa40e6c5c6a1bc16433f9768d98787d    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 26 Feb 2026 12:25:00 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 26 Feb 2026 12:25:00 -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   : a4515c9b41bcf7ff6d9ea012938706bd73e3fd54    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 29 Jan 2026 10:37:09 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 29 Jan 2026 10:37:09 -0800    

The backport prior to 18 requires minor modification due to code  
refactoring.  
  
Discussion: https://postgr.es/m/e2b7a0a88aaadded7e2d19f42d5ab03c9e182ad8.camel@j-davis.com  
Backpatch-through: 16  

commit   : 99b0786e0747baf3ce0361c9fe7be6d08db13c50    
  
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   : b9f7ceabd820369280d4ca6bfaab43cf8345f1bd    
  
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   : 25501fe995fc6b851bf282974fe8c4a8b6d91f4c    
  
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   : fe99a0338953fdcba5ba1aaaa2330435fd44d709    
  
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   : b993706787d0165136bdc183443982f053e5044b    
  
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   : 1d97e47883e0b45da22a42ab620762cc8022aa37    
  
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   : 0969bfd0db869a31e341ad17bbef32532f6315fc    
  
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   : 25b67fa7daa2d8d5452a1c9415ed16914ac6ba15    
  
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   : a38ed212ff236e4e1c94c790d9b9d18f52d2b13a    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 24 Feb 2026 14:01:51 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 24 Feb 2026 14:01:51 -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