PostgreSQL 18.1 commit log

commit   : 4b324845ba5d24682b9b3708a769f00d160afbd7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 16:52:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 16:52:06 -0500    

commit   : 91d070c7bb1480247cb834c36c89b15a7db5f82d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 13:36:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 13:36:13 -0500    

Security: CVE-2025-12817, CVE-2025-12818  

commit   : 00eb646ea43410e5df77fed96f4a981e66811796    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Nov 2025 09:00:00 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 10 Nov 2025 09:00:00 -0600    

This omission allowed table owners to create statistics in any  
schema, potentially leading to unexpected naming conflicts.  For  
ALTER TABLE commands that require re-creating statistics objects,  
skip this check in case the user has since lost CREATE on the  
schema.  The addition of a second parameter to CreateStatistics()  
breaks ABI compatibility, but we are unaware of any impacted  
third-party code.  
  
Reported-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Security: CVE-2025-12817  
Backpatch-through: 13  

commit   : 7eb8fcad860e9a0548191dab7a87a5bead5f8e91    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:01 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:01 -0800    

Several functions could overflow their size calculations, when presented  
with very large inputs from remote and/or untrusted locations, and then  
allocate buffers that were too small to hold the intended contents.  
  
Switch from int to size_t where appropriate, and check for overflow  
conditions when the inputs could have plausibly originated outside of  
the libpq trust boundary. (Overflows from within the trust boundary are  
still possible, but these will be fixed separately.) A version of  
add_size() is ported from the backend to assist with code that performs  
more complicated concatenation.  
  
Reported-by: Aleksey Solovev (Positive Technologies)  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Security: CVE-2025-12818  
Backpatch-through: 13  

commit   : 292b81a0be84e5e5c0a57dc0c48404eca74646f8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 12:58:04 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 12:58:04 +0100    

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

commit   : 5632d2f5deca271af7dd26a8e2a4a28f45f003dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Nov 2025 12:30:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Nov 2025 12:30:08 -0500    

commit   : f8ccab0e9701117a80385bf134ad2ce5c1dc68e8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 8 Nov 2025 12:25:45 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 8 Nov 2025 12:25:45 +1300    

generic-gcc.h maps our read and write barriers to C11 acquire and  
release fences using compiler builtins, for platforms where we don't  
have our own hand-rolled assembler.  This is apparently enough for GCC,  
but the C11 memory model is only defined in terms of atomic accesses,  
and our barriers for non-atomic, non-volatile accesses were not always  
respected under Clang's stricter interpretation of the standard.  
  
This explains the occasional breakage observed on new RISC-V + Clang  
animal greenfly in lock-free PgAioHandle manipulation code containing a  
repeating pattern of loads and read barriers.  The problem can also be  
observed in code generated for MIPS and LoongAarch, though we aren't  
currently testing those with Clang, and on x86, though we use our own  
assembler there.  The scariest aspect is that we use the generic version  
on very common ARM systems, but it doesn't seem to reorder the relevant  
code there (or we'd have debugged this long ago).  
  
Fix by inserting an explicit compiler barrier.  It expands to an empty  
assembler block declared to have memory side-effects, so registers are  
flushed and reordering is prevented.  In those respects this is like the  
architecture-specific assembler versions, but the compiler is still in  
charge of generating the appropriate fence instruction.  Done for write  
barriers on principle, though concrete problems have only been observed  
with read barriers.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Tested-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/d79691be-22bd-457d-9d90-18033b78c40a%40gmail.com  
Backpatch-through: 13  

commit   : 7889889e4ea81e4e93a7b3e0d138f831e9dbd48b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Nov 2025 14:56:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Nov 2025 14:56:36 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  
  
Also as usual for a .1 release, there are some entries here that  
are not really relevant for v18 because they already appeared in 18.0.  
Those'll be removed later.  

commit   : ac72a905d0685738730dd797943613de4cf9fd48    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:54:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:54:36 +0900    

The following parameters can only be set at server start because  
their context is PGC_POSTMASTER, but this information was missing  
or incorrectly documented. This commit adds or corrects  
that information for the following parameters:  
  
* debug_io_direct  
* dynamic_shared_memory_type  
* event_source  
* huge_pages  
* io_max_combine_limit  
* max_notify_queue_pages  
* shared_memory_type  
* track_commit_timestamp  
* wal_decode_buffer_size  
  
Backpatched to all supported branches.  
  
Author: Karina Litskevich <litskevichkarina@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGfPzcin-_6XwPgVbWTOUFVZgHF5g9ROrwLUdCTfjy=0A@mail.gmail.com  
Backpatch-through: 13  

commit   : d83da466b59bd4523806a084b39cda90dc9c11e4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:42:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:42:17 +0900    

If these parameters are set without units, the values are interpreted  
as blocks. This detail was previously missing from the documentation,  
so this commit adds it.  
  
Backpatch to v17 where io_combine_limit was added.  
  
Author: Karina Litskevich <litskevichkarina@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACiT8iZCDkz1bNYQNQyvGhXWJExSnJULRTYT894u4-Ti7Yh6jw@mail.gmail.com  
Backpatch-through: 17  

commit   : c0031d461324ca6063e96cc28ce78b75aa778112    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 6 Nov 2025 19:08:29 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 6 Nov 2025 19:08:29 +0100    

XLogRecPtrIsInvalid() is inconsistent with the affirmative form of  
macros used for other datatypes, and leads to awkward double negatives  
in a few places.  This commit introduces XLogRecPtrIsValid(), which  
allows code to be written more naturally.  
  
This patch only adds the new macro.  XLogRecPtrIsInvalid() is left in  
place, and all existing callers remain untouched.  This means all  
supported branches can accept hypothetical bug fixes that use the new  
macro, and at the same time any code that compiled with the original  
formulation will continue to silently compile just fine.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/aQB7EvGqrbZXrMlg@ip-10-97-1-34.eu-west-3.compute.internal  

commit   : 0f9e0068bc62c98557d93ffeb484231162093304    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Nov 2025 11:52:47 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Nov 2025 11:52:47 +0100    

Stored generated columns are not yet computed when the filtering  
happens, so we need to prohibit them to avoid incorrect behavior.  
  
Virtual generated columns currently error out ("unexpected virtual  
generated column reference").  They could probably work if we expand  
them in the right place, but for now let's keep them consistent with  
the stored variant.  This doesn't change the behavior, it only gives a  
nicer error message.  
  
Co-authored-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CACJufxHb8YPQ095R_pYDr77W9XKNaXg5Rzy-WP525mkq+hRM3g@mail.gmail.com  

commit   : 75ec47c38bcf8777164cf91885eb907eb3fc369b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Nov 2025 12:50:10 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Nov 2025 12:50:10 +0200    

Before commit e25626677f, PGReserveSemaphores() had to be called  
before SpinlockSemaInit() because spinlocks were implemented using  
semaphores on some platforms (--disable-spinlocks). Add a comment  
explaining that.  
  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAExHW5seSZpPx-znjidVZNzdagGHOk06F+Ds88MpPUbxd1kTaA@mail.gmail.com  
Backpatch-to: 18  

commit   : 83122538f2f0354970cd5209a90abc677f32384e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Nov 2025 10:22:29 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Nov 2025 10:22:29 +0100    

Discussion: https://www.postgresql.org/message-id/flat/E1vEsbx-004QDO-0o%40gemulon.postgresql.org  

commit   : 5114d62e74991151ea38a1a31e0806a9a78682d1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 6 Nov 2025 17:25:04 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 6 Nov 2025 17:25:04 +1300    

Since OpenBSD core dumps do not embed executable paths, the script now  
searches for the corresponding binary manually within the specified  
directory before invoking LLDB.  This is imperfect but should find the  
right executable in practice, as needed for meaningful backtraces.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAN55FZ36R74TZ8RKsFueYwLxGKDAm3LU2FHM_ZUCSB6imd3vYA@mail.gmail.com  
Backpatch-through: 18  

commit   : 233d79ec4fa09057e6707bd8da11758c4313f3cc    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:01 +0900    

Commit 27cc7cd2b removed the epqScanDone flag from the EState struct,  
and instead added an equivalent flag named relsubs_done to the EPQState  
struct; but it failed to update this comment.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK152zJ3fU5avDT5udfL0namrDeVfMTL3dxdOXw28SOrycg%40mail.gmail.com  
Backpatch-through: 13  

commit   : e971cf5a95ca1c8a0d6f09a8765f53492460abbf    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:15:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:15:01 +0900    

postgres_fdw supports EvalPlanQual testing by using the infrastructure  
provided by the core with the RecheckForeignScan callback routine (cf.  
commits 5fc4c26db and 385f337c9), but there has been no test coverage  
for that, except that recent commit 12609fbac, which fixed an issue in  
commit 385f337c9, added a test case to exercise only a code path added  
by that commit to the core infrastructure.  So let's add test cases to  
exercise other code paths as well at this time.  
  
Like commit 12609fbac, back-patch to all supported branches.  
  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK15%2B6H%3DkDA%3D-y3Y28OAPY7fbAdyMosVofZZ%2BNc769epVTQ%40mail.gmail.com  
Backpatch-through: 13  

commit   : ae2381025a4c77662ed5a56c062cbf3355c3d618    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 6 Nov 2025 13:24:30 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 6 Nov 2025 13:24:30 +1300    

If any shell command fails, the whole script should fail.  To avoid  
future omissions, add this even for single-command scripts that use su  
with heredoc syntax, as they might be extended or copied-and-pasted.  
  
Extracted from a larger patch that wanted to use #error during  
compilation, leading to the diagnosis of this problem.  
  
Reviewed-by: Tristan Partin <tristan@partin.io> (earlier version)  
Discussion: https://postgr.es/m/DDZP25P4VZ48.3LWMZBGA1K9RH%40partin.io  
Backpatch-through: 15  

commit   : 6d8acb777715c401925b7c26e16378b2716aa6a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Nov 2025 11:09:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Nov 2025 11:09:30 -0500    

We've successfully used libsanitizer for awhile with the undefined  
and alignment sanitizers, but with some other sanitizers (at least  
thread and hwaddress) it crashes due to internal recursion before  
it's fully initialized itself.  It turns out that that's due to the  
"__ubsan_default_options" hack installed by commit f686ae82f, and we  
can fix it by ensuring that __ubsan_default_options is built without  
any sanitizer instrumentation hooks.  
  
Reported-by: Emmanuel Sibi <emmanuelsibi.mec@gmail.com>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Diagnosed-by: Emmanuel Sibi <emmanuelsibi.mec@gmail.com>  
Fix-suggested-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/F7543B04-E56C-4D68-A040-B14CCBAD38F1@gmail.com  
Discussion: https://postgr.es/m/dbf77bf7-6e54-ed8a-c4ae-d196eeb664ce@gmail.com  
Backpatch-through: 16  

commit   : 500f646368e4dcfd86daf729ad9481d85b547005    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 5 Nov 2025 18:09:21 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 5 Nov 2025 18:09:21 +0900    

In generate_orderedappend_paths(), there is an assumption that a child  
relation's row estimate is always greater than zero.  There is an  
Assert verifying this assumption, and the estimate is also used to  
convert an absolute tuple count into a fraction.  
  
However, this assumption is not always valid -- for example, upper  
relations can have their row estimates unset, resulting in a value of  
zero.  This can cause an assertion failure in debug builds or lead to  
the tuple fraction being computed as infinity in production builds.  
  
To fix, use the row estimate from the cheapest_total path to compute  
the tuple fraction.  The row estimate in this path should already have  
been forced to a valid value.  
  
In passing, update the comment for generate_orderedappend_paths() to  
note that the function also considers the cheapest-fractional case  
when not all tuples need to be retrieved.  That is, it collects all  
the cheapest fractional paths and builds an ordered append path for  
each interesting ordering.  
  
Backpatch to v18, where this issue was introduced.  
  
Bug: #19102  
Reported-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
Reviewed-by: Andrei Lepikhov <lepihov@gmail.com>  
Discussion: https://postgr.es/m/19102-93480667e1200169@postgresql.org  
Backpatch-through: 18  

commit   : d09047d6c009893fd6beb5ee083a4e919c931d98    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:22 +0900    

The test introduced by 17b2d5ec759c verifies that a WAL receiver  
survives across a timeline jump by searching the server logs for  
termination messages.  However, it called restart() before the timeline  
switch, which kills the WAL receiver and may log the exact message being  
checked, hence failing the test.  As TAP tests reuse the same log file  
across restarts, a rotate_logfile() is used before the restart so as the  
log matching check is not impacted by log entries generated by a  
previous shutdown.  
  
Recent changes to file handle inheritance altered I/O timing enough to  
make this fail consistently while testing another patch.  
  
While on it, this adds an extra check based on a PID comparison.  This  
test may lead to false positives as it could be possible that the WAL  
receiver has processed a timeline jump before the initial PID is  
grabbed, but it should be good enough in most cases.  
  
Like 17b2d5ec759c, backpatch down to v13.  
  
Author: Bryan Green <dbryan.green@gmail.com>  
Co-authored-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/9d00b597-d64a-4f1e-802e-90f9dc394c70@gmail.com  
Backpatch-through: 13  

commit   : b166a715262e84b135f70d18020c32329038dba9    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 5 Nov 2025 12:29:31 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 5 Nov 2025 12:29:31 +0900    

The comment for ChangeVarNodes() refers to a parameter named  
change_RangeTblRef, which does not exist in the code.  
  
The comment for ChangeVarNodesExtended() contains an extra space,  
while the comment for replace_relid_callback() has an awkward line  
break and a typo.  
  
This patch fixes these issues and revises some sentences for smoother  
wording.  
  
Oversights in commits ab42d643c and fc069a3a6.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs480j16HC1JtjKCgj5WshivT8ZJYkOfTyZAM0POjFomJkg@mail.gmail.com  
Backpatch-through: 18  

commit   : 19e391e38a5efe1e798a0e7e3c87b3ba2208b110    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 19:23:13 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 19:23:13 -0500    

First, the assertions in assign_io_method() were the wrong way round. Second,  
the lengthof() assertion checked the length of io_method_options, which is the  
wrong array to check and is always longer than pgaio_method_ops_table.  
  
While add it, add a static assert to ensure pgaio_method_ops_table and  
io_method_options stay in sync.  
  
Per coverity and Tom Lane.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 18  

commit   : 850b7da15b8dc5d479181095fde89be340680a06    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 18:36:18 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 18:36:18 -0500    

In 2a0faed9d702, which added JIT compilation support for expressions, I  
accidentally used sizeof(LLVMBasicBlockRef *) instead of  
sizeof(LLVMBasicBlockRef) as part of computing the size of an allocation. That  
turns out to have no real negative consequences due to LLVMBasicBlockRef being  
a pointer itself (and thus having the same size). It still is wrong and  
confusing, so fix it.  
  
Reported by coverity.  
  
Backpatch-through: 13  

commit   : 3ebea75f9afab4f526934100b4ba747e9d95bba8    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 4 Nov 2025 16:27:31 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 4 Nov 2025 16:27:31 -0800    

Allow pg_newlocale_from_collation(C_COLLATION_OID) to work even if  
there's no catalog access, which some extensions expect.  
  
Not known to be a bug without extensions involved, but backport to 18.  
  
Also corrects an issue in master with dummy_c_locale (introduced in  
commit 5a38104b36) where deterministic was not set. That wasn't a bug,  
but could have been if that structure was used more widely.  
  
Reported-by: Alexander Kukushkin <cyberdemn@gmail.com>  
Reviewed-by: Alexander Kukushkin <cyberdemn@gmail.com>  
Discussion: https://postgr.es/m/CAFh8B=nj966ECv5vi_u3RYij12v0j-7NPZCXLYzNwOQp9AcPWQ@mail.gmail.com  
Backpatch-through: 18  

commit   : 71aa2e1147b9ddae8e6e9717953c28075e287ad2    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 4 Nov 2025 15:47:22 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 4 Nov 2025 15:47:22 -0800    

This commit adds CHECK_FOR_INTERRUPTS to the shared buffer iteration  
loops in EvictRelUnpinnedBuffers and EvictAllUnpinnedBuffers. These  
functions, used by pg_buffercache's pg_buffercache_evict_relation and  
pg_buffercache_evict_all, can now be interrupted during long-running  
operations.  
  
Backpatch to version 18, where these functions and their corresponding  
pg_buffercache functions were introduced.  
  
Author: Yuhang Qiu <iamqyh@gmail.com>  
Discussion: https://postgr.es/m/8DC280D4-94A2-4E7B-BAB9-C345891D0B78%40gmail.com  
Backpatch-through: 18  

commit   : 8733f0b54c05239e059e473c46c1800dcd37cd40    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Nov 2025 20:31:43 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Nov 2025 20:31:43 +0100    

Commit a95e3d84c0e0 added ActiveSnapshot push+pop when processing  
work-items (BRIN autosummarization), but forgot to handle the case of  
a transaction failing during the run, which drops the snapshot untimely.  
Fix by making the pop conditional on an element being actually there.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/202511041648.nofajnuddmwk@alvherre.pgsql  

commit   : 640c59067ec5847fed3fadaeeb587f3ad5eb152b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:25:34 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:25:34 -0500    

Debian Trixie CI images are generated now [1], so use them with the  
following changes:  
  
- detect_stack_use_after_return=0 option is added to the ASAN_OPTIONS  
  because ASAN uses a "shadow stack" to track stack variable lifetimes  
  and this confuses Postgres' stack depth check [2].  
  
- Perl is updated to the newer version (perl5.40-i386-linux-gnu).  
  
- LLVM-14 is no longer default installation, no need to force using  
  LLVM-16.  
  
- Switch MinGW CC/CXX to x86_64-w64-mingw32ucrt-* to fix build failure  
  from missing _iswctype_l in mingw-w64 v12 headers.  
  
[1] https://github.com/anarazel/pg-vm-images/commit/35a144793f  
[2] https://postgr.es/m/20240130212304.q66rquj5es4375ab%40awork3.anarazel.de  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAN55FZ1_B1usTskAv+AYt1bA7abVd9YH6XrUUSbr-2Z0d5Wd8w@mail.gmail.com  
Backpatch: 15-, where CI support was added  

commit   : a26b753a0894961d82e5f6785ae08959c2755110    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 4 Nov 2025 18:46:37 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 4 Nov 2025 18:46:37 +0100    

When building intermediate TID lists during parallel GIN builds, split  
the sorted lists into smaller chunks, to limit the amount of memory  
needed when merging the chunks later.  
  
The leader may need to keep in memory up to one chunk per worker, and  
possibly one extra chunk (before evicting some of the data). The code  
processing item pointers uses regular palloc/repalloc calls, which means  
it's subject to the MaxAllocSize (1GB) limit.  
  
We could fix this by allowing huge allocations, but that'd require  
changes in many places without much benefit. Larger chunks do not  
actually improve performance, so the memory usage would be wasted.  
  
Fixed by limiting the chunk size to not hit MaxAllocSize. Each worker  
gets a fair share.  
  
This requires remembering the number of participating workers, in a  
place that can be accessed from the callback. Luckily, the bs_worker_id  
field in GinBuildState was unused, so repurpose that.  
  
Report by Greg Smith, investigation and fix by me. Batchpatched to 18,  
where parallel GIN builds were introduced.  
  
Reported-by: Gregory Smith <gregsmithpgsql@gmail.com>  
Discussion: https://postgr.es/m/CAHLJuCWDwn-PE2BMZE4Kux7x5wWt_6RoWtA0mUQffEDLeZ6sfA@mail.gmail.com  
Backpatch-through: 18  

commit   : 8864016118798ae4660bde7bee5cd6ee94ae6e95    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Nov 2025 17:30:44 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Nov 2025 17:30:44 +0100    

Accidental omission in commit aa2ba50c2c13.  There are too many lists of  
these variables ...  
  
Discussion: https://postgr.es/m/202511031738.eqaeaedpx5cr@alvherre.pgsql  

commit   : ba99c9491c442e3640092c8cae380d9353721f3e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Nov 2025 14:31:57 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Nov 2025 14:31:57 +0100    

A generated column may end up being part of the partition key  
expression, if it's specified as an expression e.g. "(<generated  
column name>)" or if the partition key expression contains a whole-row  
reference, even though we do not allow a generated column to be part  
of partition key expression.  Fix this hole.  
  
Co-authored-by: jian he <jian.universality@gmail.com>  
Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://www.postgresql.org/message-id/flat/CACJufxF%3DWDGthXSAQr9thYUsfx_1_t9E6N8tE3B8EqXcVoVfQw%40mail.gmail.com  

commit   : 419ffde235469bd7459bd52b7eeed76a7520853a    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Nov 2025 13:23:26 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 4 Nov 2025 13:23:26 +0100    

It's possible to define BRIN indexes on functions that require a  
snapshot to run, but the autosummarization feature introduced by commit  
7526e10224f0 fails to provide one.  This causes autovacuum to leave a  
BRIN placeholder tuple behind after a failed work-item execution, making  
such indexes less efficient.  Repair by obtaining a snapshot prior to  
running the task, and add a test to verify this behavior.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Giovanni Fabris <giovanni.fabris@icon.it>  
Reported-by: Arthur Nascimento <tureba@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/202511031106.h4fwyuyui6fz@alvherre.pgsql  

commit   : 1baae827ef51ca12ac5cd83775905a46f8e794af    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Nov 2025 11:59:17 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Nov 2025 11:59:17 +0100    

Fixup for commit ef5e60a9d35: The inconsistent use of articles was a  
bit awkward.  

commit   : a14201073965ba8c4d6e553b044e30efbf214c20    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:33 +0900    

Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of  
3635a0a35aaf) introduced an unconditional WAL receiver shutdown when  
switching from streaming to archive WAL sources.  This causes problems  
during a timeline switch, when a WAL receiver enters WALRCV_WAITING  
state but remains alive, waiting for instructions.  
  
The unconditional shutdown can break some monitoring scenarios as the  
WAL receiver gets repeatedly terminated and re-spawned, causing  
pg_stat_wal_receiver.status to show a "streaming" instead of "waiting"  
status, masking the fact that the WAL receiver is waiting for a new TLI  
and a new LSN to be able to continue streaming.  
  
This commit changes the WAL receiver behavior so as the shutdown becomes  
conditional, with InstallXLogFileSegmentActive being always reset to  
prevent the regression fixed by b4f584f9d2a1: only terminate the WAL  
receiver when it is actively streaming (WALRCV_STREAMING,  
WALRCV_STARTING, or WALRCV_RESTARTING).  When in WALRCV_WAITING state,  
just reset InstallXLogFileSegmentActive flag to allow archive  
restoration without killing the process.  WALRCV_STOPPED and  
WALRCV_STOPPING are not reachable states in this code path.  For the  
latter, the startup process is the one in charge of setting  
WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to  
reach a WALRCV_STOPPED state after switching walRcvState, so  
WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is  
in a WALRCV_STOPPING state.  
  
A regression test is added to check that a WAL receiver is not stopped  
on timeline jump, that fails when the fix of this commit is reverted.  
  
Reported-by: Ryan Bird <ryanzxg@gmail.com>  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org  
Backpatch-through: 13  

commit   : 46524d519a2d2a49c67a53a23225700c49f971fb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 3 Nov 2025 12:57:09 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 3 Nov 2025 12:57:09 -0800    

Author: Mikhail Nikalayeu <mihailnikalayeu@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/CANtu0ojXmqjmEzp-=aJSxjsdE76iAsRgHBoK0QtYHimb_mEfsg@mail.gmail.com  
Backpatch-through: 13  

commit   : d9ffc27291fda0041db4f1e9c74ab1148e4b04a8    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 3 Nov 2025 15:58:19 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 3 Nov 2025 15:58:19 +0100    

We don't allow null values to appear in identity-generated columns in  
other ways, so we shouldn't let unvalidated not-null constraints do it  
either.  Oversight in commit a379061a22a8.  
  
Author: jian he <jian.universality@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CACJufxGQM_+vZoYJMaRoZfNyV=L2jxosjv_0TLAScbuLJXWRfQ@mail.gmail.com  

commit   : 6c3b1df878a65bb76e21ed640add30391db8f1d7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 2 Nov 2025 15:27:03 -0500    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 2 Nov 2025 15:27:03 -0500    

Add comments explaining when and where it is safe for nbtree to treat  
row compare keys as if they were simple scalar inequality keys on the  
row's most significant column.  This is particularly important within  
_bt_advance_array_keys, which deals with required inequality keys in a  
general and uniform way, without any special handling for row compares.  
  
Also spell out the implications of _bt_check_rowcompare's approach of  
_conditionally_ evaluating lower-order row compare subkeys, particularly  
when one of its lower-order subkeys might see NULL index tuple values  
(these may or may not affect whether the qual as a whole is satisfied).  
The behavior in this area isn't particularly intuitive, so these issues  
seem worth going into.  
  
In passing, add a few more defensive/documenting row comparison related  
assertions to _bt_first and _bt_check_rowcompare.  
  
Follow-up to commits bd3f59fd and ec986020.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Victor Yegorov <vyegorov@gmail.com>  
Reviewed-By: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAH2-Wznwkak_K7pcAdv9uH8ZfNo8QO7+tHXOaCUddMeTfaCCFw@mail.gmail.com  
Backpatch-through: 18  

commit   : 742bd91a83d009187ccf9370142408b94e5b119a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 2 Nov 2025 13:34:16 -0500    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 2 Nov 2025 13:34:16 -0500    

_bt_first reliably uses the same equality key (on each index column) for  
initial positioning purposes as the one that _bt_checkkeys can use to  
end the scan following commit f09816a0.  _bt_first no longer applies its  
own independent rules to determine which initial positioning key to use  
on each column (for equality and inequality keys alike).  Preprocessing  
is now fully in control of determining which keys start and end each  
scan, ensuring that _bt_first and _bt_checkkeys have symmetric behavior.  
  
Remove obsolete comments that described why _bt_first was expected to  
use at least one of the available required equality keys for initial  
positioning purposes.  The rules in this area are now maximally strict  
and uniform, so there's no reason to draw attention to equality keys.  
Any column with a required equality key cannot have a redundant required  
inequality key (nor can it have a redundant required equality key).  
  
Oversight in commit f09816a0, which removed similar comments from  
_bt_first, but missed these comments.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Backpatch-through: 18  

commit   : fdbc6757276208bb87498d4f17ef884baf2e90fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Nov 2025 12:30:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Nov 2025 12:30:44 -0500    

The C standard says that the second and third arguments of a  
conditional operator shall be both void type or both not-void  
type.  The Windows version of INTERRUPTS_PENDING_CONDITION()  
got this wrong.  It's pretty harmless because the result of  
the operator is ignored anyway, but apparently recent versions  
of MSVC have started issuing a warning about it.  Silence the  
warning by casting the dummy zero to void.  
  
Reported-by: Christian Ullrich <chris@chrullrich.net>  
Author: Bryan Green <dbryan.green@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/cc4ef8db-f8dc-4347-8a22-e7ebf44c0308@chrullrich.net  
Backpatch-through: 13  

commit   : c25314d5364e284d137d30c5110727dbe0068d8b    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 31 Oct 2025 18:49:50 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 31 Oct 2025 18:49:50 +0100    

The original messages were confusing in dry-run mode in that they state  
that something is being done, when in reality it isn't.  Use alternative  
wording in that case, to make the distinction clear.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAHut+PsvQJQnQO0KT0S2oegenkvJ8FUuY-QS5syyqmT24R2xFQ@mail.gmail.com  

commit   : 59aeb693f67fc15dfa58e2fdada2a70ce1004660    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 31 Oct 2025 17:43:15 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 31 Oct 2025 17:43:15 +0100    

The code updates the system identifier, then runs pg_walreset; if the  
latter fails, it complains about the former, which makes no sense.  
Change the error message to complain about the right thing.  
  
Noticed while reviewing a patch touching nearby code.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Backpatch-through: 17  

commit   : 0941188056934cb6ae6de391bc57837620f16c26    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 30 Oct 2025 19:11:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 30 Oct 2025 19:11:53 -0400    

This removes some of the specifics of how the default was set, and adds  
a mention of latency as a reason the value is lower than the storage  
hardware might suggest.  It still mentions caching.  
  
Discussion: https://postgr.es/m/CAKAnmmK_nSPYr53LobUwQD59a-8U9GEC3XGJ43oaTYJq5nAOkw@mail.gmail.com  
  
Backpatch-through: 13  

commit   : a7e7bcac67f69b402332dea48c7710b95f6fd574    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 16:08:43 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 16:08:43 -0400    

Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAN55FZ3kO4vLq56PWrfJ7Fw6Wz8DhEN9j9GX3aScx%2BWOirtK-g%40mail.gmail.com  
Backpatch: 15-, where CI support was added  

commit   : 3287bf62c9ea63763ea03bf8508e24ba3b73a8f3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 13:07:01 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 13:07:01 -0400    

They use Windows Server 2022, not 2019.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/flat/CAN55FZ1OsaM+852BMQDJ+Kgfg+07knJ6dM3PjbGbtYaK4qwfqA@mail.gmail.com  

commit   : fa78e5bea53a3096d1df7d1b2d7cbd58d15a9b7a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 30 Oct 2025 10:59:56 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 30 Oct 2025 10:59:56 +0100    

The docs for max_protocol_version suggested PQprotocolVersion()  
instead of PQfullProtocolVersion() to find out the exact protocol  
version.  Since PQprotocolVersion() only returns the major protocol  
version, that is bad advice.  
  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAGECzQSKFxQsYAgr11PhdOr-RtPZEdAXZnHx6U3avLuk3xQaTQ%40mail.gmail.com  

commit   : bf3dba508ee1c812b790e3f3f059659c69f74cdf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Oct 2025 13:13:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Oct 2025 13:13:31 +0900    

This commit reverts 818fefd8fd4, that has been introduced to address a  
an instability in some of the TAP tests due to the presence of random  
standby snapshot WAL records, when slots are invalidated by  
InvalidatePossiblyObsoleteSlot().  
  
Anyway, this commit had also the consequence of introducing a behavior  
regression.  After 818fefd8fd4, the code may determine that a slot needs  
to be invalidated while it may not require one: the slot may have moved  
from a conflicting state to a non-conflicting state between the moment  
when the mutex is released and the moment when we recheck the slot, in  
InvalidatePossiblyObsoleteSlot().  Hence, the invalidations may be more  
aggressive than they actually have to.  
  
105b2cb3361 has tackled the test instability in a way that should be  
hopefully sufficient for the buildfarm, even for slow members:  
- In v18, the test relies on an injection point that bypasses the  
creation of the random records generated for standby snapshots,  
eliminating the random factor that impacted the test.  This option was  
not available when 818fefd8fd4 was discussed.  
- In v16 and v17, the problem was bypassed by disallowing a slot to  
become active in some of the scenarios tested.  
  
While on it, this commit adds a comment to document that it is fine for  
a recheck to use xmin and LSN values stored in the slot, without storing  
and reusing them across multiple checks.  
  
Reported-by: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/f492465f-657e-49af-8317-987460cb68b0.mengjuan.cmj@alibaba-inc.com  
Backpatch-through: 16  

commit   : ef6168bafe9be1a5781b2c471ffa4650f31f9a77    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 30 Oct 2025 12:03:15 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 30 Oct 2025 12:03:15 +0900    

RIGHT_SEMI joins rely on the HEAP_TUPLE_HAS_MATCH flag to guarantee  
that only the first match for each inner tuple is considered.  
However, in a parallel hash join, the inner relation is stored in a  
shared global hash table that can be probed by multiple workers  
concurrently.  This allows different workers to inspect and set the  
match flags of the same inner tuples at the same time.  
  
If two workers probe the same inner tuple concurrently, both may see  
the match flag as unset and emit the same tuple, leading to duplicate  
output rows and violating RIGHT_SEMI join semantics.  
  
For now, we disable parallel plans for RIGHT_SEMI joins.  In the long  
term, it may be possible to support parallel execution by performing  
atomic operations on the match flag, for example using a CAS or  
similar mechanism.  
  
Backpatch to v18, where RIGHT_SEMI join was introduced.  
  
Bug: #19094  
Reported-by: Lori Corbani <Lori.Corbani@jax.org>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19094-6ed410eb5b256abd@postgresql.org  
Backpatch-through: 18  

commit   : af3a79e0837d23fa536f859fc927b1379855ae24    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:49:07 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:49:07 +1300    

Because long is 32-bit on 64-bit Windows, it isn't a good datatype to  
store the difference between 2 pointers.  The under-sized type could  
overflow and lead to scary warnings in MEMORY_CONTEXT_CHECKING builds,  
such as:  
  
WARNING:  problem in alloc set ExecutorState: bad single-chunk %p in block %p  
  
However, the problem lies only in the code running the check, not from  
an actual memory accounting bug.  
  
Fix by using "Size" instead of "long".  This means using an unsigned  
type rather than the previous signed type.  If the block's freeptr was  
corrupted, we'd still catch that if the unsigned type wrapped.  Unsigned  
allows us to avoid further needless complexities around comparing signed  
and unsigned types.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAApHDvo-RmiT4s33J=aC9C_-wPZjOXQ232V-EZFgKftSsNRi4w@mail.gmail.com  

commit   : b1635c166698a2b70aa3f397d0f7ca6844872dce    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 29 Oct 2025 12:35:02 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 29 Oct 2025 12:35:02 +0100    

Two or more constants can have the same location.  We handled this  
correctly for non squashed constants, but failed to do it if squashed  
(resulting in out-of-bounds memory access), because the code structure  
became broken by commit 0f65f3eec478: we failed to update 'last_loc'  
correctly when skipping these squashed constants.  
  
The simplest fix seems to be to get rid of 'last_loc' altogether -- in  
hindsight, it's quite pointless.  Also, when ignoring a constant because  
of this, make sure to fulfill fill_in_constant_lengths's duty of setting  
its length to -1.  
  
Lastly, we can use == instead of <= because the locations have been  
sorted beforehand, so the < case cannot arise.  
  
Co-authored-by: Sami Imseih <samimseih@gmail.com>  
Co-authored-by: Dmitry Dolgov <9erthalion6@gmail.com>  
Reported-by: Konstantin Knizhnik <knizhnik@garret.ru>  
Backpatch-through: 18  
Discussion: https://www.postgresql.org/message-id/2b91e358-0d99-43f7-be44-d2d4dbce37b3%40garret.ru  

commit   : a92bbffbc3a7157b0998f0423cf2304c81626822    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Oct 2025 09:55:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Oct 2025 09:55:48 +0900    

CRLF translation is already handled by the text mode, so there should be  
no need for any specific logic.  See also 1c6d4629394d, msys perl being  
one case where the translation mattered.  
  
Note: An equivalent has been first applied on HEAD with 8767b449a3a1.  
The same change is backpatched to v18 as all the Windows buildfarm  
members have reported green.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/aPsh39bxwYKvUlAf@paquier.xyz  
Backpatch-through: 18  

commit   : 74197bdc842a280befe834e5cb4be700af9f8198    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 Oct 2025 10:06:03 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 Oct 2025 10:06:03 +0100    

Some recent changes were made to remove the explicit dependency on  
btree indexes in some parts of the code.  One of these changes was  
made in commit 9ef1851685b, which allows non-btree indexes to be used  
in get_actual_variable_range().  A follow-up commit ee1ae8b99f9 fixes  
the cases where an index doesn’t have a sortopfamily as this is a  
prerequisite to be used in get_actual_variable_range().  
  
However, it was found that indexes that have amcanorder = true but do  
not allow index-only-scans (amcanreturn returns false or is NULL) will  
pass all of the conditions, while they should be rejected since  
get_actual_variable_range() uses the index-only-scan machinery in  
get_actual_variable_endpoint().  Such an index might cause errors like  
  
    ERROR:  no data returned for index-only scan  
  
during query planning.  
  
The fix is to add a check in get_actual_variable_range() to reject  
indexes that do not allow index-only scans.  
  
Author: Maxime Schoemans <maxime.schoemans@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/20ED852A-C2D9-41EB-8671-8C8B9D418BE9%40enterprisedb.com  

commit   : b45a8d7d8b306b43f31a002f1b3f1dddc8defeaf    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 27 Oct 2025 06:37:35 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 27 Oct 2025 06:37:35 +0000    

Previously, the check_hook for synchronized_standby_slots attempted to  
validate that each specified slot existed and was physical. However, these  
checks were not performed during server startup. As a result, if users  
configured non-existent slots before startup, the misconfiguration would  
go undetected initially. This could later cause parallel query failures,  
as newly launched workers would detect the issue and raise an ERROR.  
  
This patch improves the check_hook by validating the syntax and format of  
slot names. Validation of slot existence and type is deferred to the WAL  
sender process, aligning with the behavior of the check_hook for  
primary_slot_name.  
  
Reported-by: Fabrice Chapuis <fabrice636861@gmail.com>  
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Ashutosh Sharma <ashu.coek88@gmail.com>  
Reviewed-by: Rahila Syed <rahilasyed90@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/CAA5-nLCeO4MQzWipCXH58qf0arruiw0OeUc1+Q=Z=4GM+=v1NQ@mail.gmail.com  

commit   : a2387c32f2f8a1643c7d71b951587e6bcb2d4744    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 26 Oct 2025 11:01:32 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 26 Oct 2025 11:01:32 +1300    

When dealing with ResultRelInfos for partitions, there are cases where  
there are mixed requirements for the ri_RootResultRelInfo.  There are  
cases when the partition itself requires a NULL ri_RootResultRelInfo and  
in the same query, the same partition may require a ResultRelInfo with  
its parent set in ri_RootResultRelInfo.  This could cause the column  
mapping between the partitioned table and the partition not to be done  
which could result in crashes if the column attnums didn't match  
exactly.  
  
The fix is simple.  We now check that the ri_RootResultRelInfo matches  
what the caller passed to ExecGetTriggerResultRel() and only return a  
cached ResultRelInfo when the ri_RootResultRelInfo matches what the  
caller wants, otherwise we'll make a new one.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Reported-by: Dmitry Fomin <fomin.list@gmail.com>  
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com  
Backpatch-through: 15  

commit   : 67ef5575ccb07d2dd5322aef33e01b3c2a4b9047    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2025 17:46:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2025 17:46:57 -0400    

Commit 65281391a caused some additional error context lines to  
appear in the output of one test case.  That's fine, but we missed  
updating the expected output.  Do it now.  
  
While here, add some missing test-output subdirectories to  
contrib/sepgsql/.gitignore, so that we don't get git warnings  
after running the tests.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1613232.1761255361@sss.pgh.pa.us  
Backpatch-through: 18  

commit   : 172f217e825c63878b7b7c875ee04c7a90427303    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 23 Oct 2025 21:26:15 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 23 Oct 2025 21:26:15 +0200    

The project Git server hasn't supported cloning with the Git protocol  
in a very long time, but the documentation never got the memo. Remove  
the mention of using the Git protocol, and while there wrap a mention  
of Git in <productname> tags.  
  
Backpatch down to all supported versions.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Gurjeet Singh <gurjeet@singh.im>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Gurjeet Singh <gurjeet@singh.im>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CABwTF4WMiMb-KT2NRcib5W0C8TQF6URMb+HK9a_=rnZnY8Q42w@mail.gmail.com  
Backpatch-through: 13  

commit   : e7a3fae39e338c21b7c9ba8307775b410b4bd057    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2025 12:32:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2025 12:32:06 -0400    

These two functions expect there to be room to insert another item  
in the FreePageBtree's array, but their assertions were too weak  
to guarantee that.  This has little practical effect granting that  
the callers are not buggy, but it seems to be misleading late-model  
Coverity into complaining about possible array overrun.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/799984.1761150474@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 447a794f6473f86457279f4a21673042271724d0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2025 11:47:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2025 11:47:46 -0400    

Commit c6f7f11d8 intended to prevent leaking any PyObject reference  
counts in edge cases (such as out-of-memory during string  
construction), but actually it introduced a leak in the normal case.  
Repeating an error-trapping operation often enough would lead to  
session-lifespan memory bloat.  The problem is that I failed to  
think about the fact that PyObject_GetAttrString() increments the  
refcount of the returned PyObject, so that simply walking down the  
list of error frame objects causes all but the first one to have  
their refcount incremented.  
  
I experimented with several more-or-less-complex ways around that,  
and eventually concluded that the right fix is simply to drop the  
newly-obtained refcount as soon as we walk to the next frame  
object in PLy_traceback.  This sounds unsafe, but it's perfectly  
okay because the caller holds a refcount on the first frame object  
and each frame object holds a refcount on the next one; so the  
current frame object can't disappear underneath us.  
  
By the same token, we can simplify the caller's cleanup back to  
simply dropping its refcount on the first object.  Cleanup of  
each frame object will lead in turn to the refcount of the next  
one going to zero.  
  
I also added a couple of comments explaining why PLy_elog_impl()  
doesn't try to free the strings acquired from PLy_get_spi_error_data()  
or PLy_get_error_data().  That's because I got here by looking at a  
Coverity complaint about how those strings might get leaked.  They  
are not leaked, but in testing that I discovered this other leak.  
  
Back-patch, as c6f7f11d8 was.  It's a bit nervous-making to be  
putting such a fix into v13, which is only a couple weeks from its  
final release; but I can't see that leaving a recently-introduced  
leak in place is a better idea.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1203918.1761184159@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 5f88da5de3f23f74b5cc0958a0b2033801a86220    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Oct 2025 13:24:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Oct 2025 13:24:56 +0900    

Commit 883a95646a8 introduced overflow entries in the replication lag tracker  
to fix an issue where lag columns in pg_stat_replication could stall when  
the replay LSN stopped advancing.  
  
This commit adds comments clarifying the purpose and behavior of overflow  
entries to improve code readability and understanding.  
  
Since commit 883a95646a8 was recently applied and backpatched to all  
supported branches, this follow-up commit is also backpatched accordingly.  
  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CABPTF7VxqQA_DePxyZ7Y8V+ErYyXkmwJ1P6NC+YC+cvxMipWKw@mail.gmail.com  
Backpatch-through: 13  

commit   : 2bc01eff37a2fc856eb701c2036f6a186749d681    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 22 Oct 2025 17:17:46 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 22 Oct 2025 17:17:46 -0700    

Fix oversight in commit 303ba0573, which was backpatched through 14.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAD21AoBeFdTJcwUfUYPcEgONab3TS6i1PB9S5cSXcBAmdAdQKw%40mail.gmail.com  
Backpatch-through: 14  

commit   : ceb51d09b46b5f75a8fa94c169e570b02a370461    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:12:03 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:12:03 +1300    

When JIT deformed tuples (controlled via the jit_tuple_deforming GUC),  
types narrower than sizeof(Datum) would be zero-extended up to Datum  
width.  This wasn't the same as what fetch_att() does in the standard  
tuple deforming code.  Logically the values are the same when fetching  
via the DatumGet*() marcos, but negative numbers are not the same in  
binary form.  
  
In the report, the problem was manifesting itself with:  
  
ERROR: could not find memoization table entry  
  
in a query which had a "Cache Mode: binary" Memoize node. However, it's  
currently unclear what else is affected.  Anything that uses  
datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by  
JIT could be affected, but it may not be limited to that.  
  
The fix for this is simple: use signed extension instead of zero  
extension.  
  
Many thanks to Emmanuel Touzery for reporting this issue and providing  
steps and backup which allowed the problem to easily be recreated.  
  
Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM  
Backpatch-through: 13  

commit   : e2072b47b9abc7d298d242217919d3d0d9415fca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Oct 2025 13:38:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Oct 2025 13:38:37 -0400    

One code path forgot to free the separately-malloc'd filename  
part of a struct rfile.  Another place freed the filename but  
forgot the struct rfile itself.  These seem worth fixing because  
with a large backup we could be dealing with many files.  
  
Coverity found the bug in make_rfile().  I found the other one  
by manual inspection.  

commit   : 6ff7ba9fe525fd64cdafb242867d8d22486b88d9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 20:10:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 20:10:58 +0900    

Previously, if primary_slot_name was set to an invalid slot name and  
the configuration file was reloaded, both the postmaster and all other  
backend processes reported a WARNING. With many processes running,  
this could produce a flood of duplicate messages. The problem was that  
the GUC check hook for primary_slot_name reported errors at WARNING  
level via ereport().  
  
This commit changes the check hook to use GUC_check_errdetail() and  
GUC_check_errhint() for error reporting. As with other GUC parameters,  
this causes non-postmaster processes to log the message at DEBUG3,  
so by default, only the postmaster's message appears in the log file.  
  
Backpatch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/CAHGQGwFud-cvthCTfusBfKHBS6Jj6kdAPTdLWKvP2qjUX6L_wA@mail.gmail.com  
Backpatch-through: 13  

commit   : 9670032cc51f502e39b4b99eba72dd14573d3776    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 11:27:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 11:27:15 +0900    

Previously, when the replay LSN reported in feedback messages from a standby  
stopped advancing, for example, due to a recovery conflict, the write_lag and  
flush_lag columns in pg_stat_replication would initially update but then stop  
progressing. This prevented users from correctly monitoring replication lag.  
  
The problem occurred because when any LSN stopped updating, the lag tracker's  
cyclic buffer became full (the write head reached the slowest read head).  
In that state, the lag tracker could no longer compute round-trip lag values  
correctly.  
  
This commit fixes the issue by handling the slowest read entry (the one  
causing the buffer to fill) as a separate overflow entry and freeing space  
so the write and other read heads can continue advancing in the buffer.  
As a result, write_lag and flush_lag now continue updating even if the reported  
replay LSN remains stalled.  
  
Backpatch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGdGQ=1-X-71Caee-LREBUXSzyohkoQJd4yZZCMt24C0g@mail.gmail.com  
Backpatch-through: 13  

commit   : 93fb76ca4e69e53ac0b4d3ed0575dffdb609bb30    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 12:23:23 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 12:23:23 -0500    

As foretold by commit a72f7d97be, this commit moves the baseline  
point for ABI compatibility for v18 to commit c8af5019be.  While at  
it, add some more commentary and adjust the format of the entries  
to improve both human and machine readability.  There's a good  
chance we'll add an .abi-compliance-history file to the other  
back-branches, but for now this effort is limited to v18.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: David E. Wheeler <david@justatheory.com>  
Reviewed-by: Mankirat Singh <mankiratsingh1315@gmail.com>  
Discussion: https://postgr.es/m/aPJ03E2itovDBcKX%40nathan  
Backpatch-through: 18 only  

commit   : b797c2854964cc1a940a8ea2bb7ce2dc04401129    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 10:02:19 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 10:02:19 -0500    

Backpatch-through: 13  

commit   : 2795f5a5428fd292996fd155f16a57b0db3df8f4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 09:56:26 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 09:56:26 -0500    

Backpatch-through: 13  

commit   : 715983a81ac85a2d78ba1e2a7fe00bcf62f4ad3c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:46:49 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:46:49 +1300    

A BlockNumber (32-bit) might not be large enough to add bo_pagesPerRange  
to when the table contains close to 2^32 pages.  At worst, this could  
result in a cancellable infinite loop during the BRIN index scan with  
power-of-2 pagesPerRange, and slow (inefficient) BRIN index scans and  
scanning of unneeded heap blocks for non power-of-2 pagesPerRange.  
  
Backpatch to all supported versions.  
  
Author: sunil s <sunilfeb26@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAOG6S4-tGksTQhVzJM19NzLYAHusXsK2HmADPZzGQcfZABsvpA@mail.gmail.com  
Backpatch-through: 13  

commit   : b2abcfa33a7c2184d96fe62029195773bb8a4032    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 16:12:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 16:12:34 +0900    

The comment fixed in this commit described the function as dealing with  
database blocks, but in reality it processes shared memory allocations.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aH4DDhdiG9Gi0rG7@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 18  

commit   : ee49f2cf447ab3191164aec82410dc52f7960c6f    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 21 Oct 2025 14:12:13 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 21 Oct 2025 14:12:13 +0900    

I mistakenly included the "Replaces" lines describing the origin of  
Result nodes in groupingsets.out, which actually come from a feature  
not available in v18.  Mea culpa.  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/CAMbWs4_VxjdM-nBvt8YE=84rE4OLBES27Wz1P0=9Z6KgwPqzEA@mail.gmail.com  

commit   : 40c2428307b82d590f0caf73c93a5cdaf721e8b8    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 21 Oct 2025 12:35:36 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 21 Oct 2025 12:35:36 +0900    

67a54b9e8 taught the planner to push down HAVING clauses even when  
grouping sets are present, as long as the clause does not reference  
any columns that are nullable by the grouping sets.  However, there  
was an oversight: if any empty grouping sets are present, the  
aggregation node can produce a row that did not come from the input,  
and pushing down a HAVING clause in this case may cause us to fail to  
filter out that row.  
  
Currently, non-degenerate HAVING clauses are not pushed down when  
empty grouping sets are present, since the empty grouping sets would  
nullify the vars they reference.  However, degenerate (variable-free)  
HAVING clauses are not subject to this restriction and may be  
incorrectly pushed down.  
  
To fix, explicitly check for the presence of empty grouping sets and  
retain degenerate clauses in HAVING when they are present.  This  
ensures that we don't emit a bogus aggregated row.  A copy of each  
such clause is also put in WHERE so that query_planner() can use it in  
a gating Result node.  
  
To facilitate this check, this patch expands the groupingSets tree of  
the query to a flat list of grouping sets before applying the HAVING  
pushdown optimization.  This does not add any additional planning  
overhead, since we need to do this expansion anyway.  
  
In passing, make a small tweak to preprocess_grouping_sets() by  
reordering its initial operations a bit.  
  
Backpatch to v18, where this issue was introduced.  
  
Reported-by: Yuhang Qiu <iamqyh@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/0879D9C9-7FE2-4A20-9593-B23F7A0B5290@gmail.com  
Backpatch-through: 18  

commit   : 52b05b068615ca13bc9aab6bd316c9a81c2e4d9a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 08:08:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 08:08:25 +0900    

pgwin32_unsetenv() (compatibility routine of unsetenv() on Windows)  
lacks the input validation that its sibling pgwin32_setenv() has.  
Without these checks, calling unsetenv() with incorrect names crashes on  
WIN32.  However, invalid names should be handled, failing on EINVAL.  
  
This commit adds the same checks as setenv() to fail with EINVAL for a  
"name" set to NULL, an empty string, or if '=' is included in the value,  
per POSIX requirements.  
  
Like 7ca37fb0406b, backpatch down to v14.  pgwin32_unsetenv() is defined  
on REL_13_STABLE, but with the branch going EOL soon and the lack of  
setenv() there for WIN32, nothing is done for v13.  
  
Author: Bryan Green <dbryan.green@gmail.com>  
Discussion: https://postgr.es/m/b6a1e52b-d808-4df7-87f7-2ff48d15003e@gmail.com  
Backpatch-through: 14  

commit   : a72f7d97bea9fe74e8b0eb6ab3d9ab422d02ce4f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Oct 2025 10:36:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Oct 2025 10:36:41 -0400    

This is just a quick commit to verify that the buildfarm ABI  
checker responds to this control file.  Once we've tested  
that, we will update the file to point at c8af5019b.  
There's documentation mop-up yet to do, too.  
  
Discussion: https://postgr.es/m/aPJ03E2itovDBcKX@nathan  
Backpatch-through: 18 only  

commit   : 399a9e04e5491f8a76ffb482f4a86b9acb6f91fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Oct 2025 08:45:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Oct 2025 08:45:57 -0400    

The revised logic in 001_ssltests.pl would fail if openssl  
doesn't work or if Perl is a 32-bit build, because it had  
already overwritten $serialno with something inappropriate  
to use in the eventual match.  We could go back to the  
previous code layout, but it seems best to introduce a  
separate variable for the output of openssl.  
  
Per failure on buildfarm member mamba, which has a 32-bit Perl.  

commit   : aa1fcd087e5f709505aa0b9e15c1f3a0ce8b826c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Oct 2025 14:36:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Oct 2025 14:36:58 -0400    

It emerges that zlib's configuration logic is not robust enough  
to guarantee that the macro will have the same ideas about struct  
field layout as the library itself does, leading to corruption of  
zlib's state struct followed by unintelligible failure messages.  
This hazard has existed for a long time, but we'd not noticed  
for several reasons:  
  
(1) We only use gzgetc() when trying to read a manually-compressed  
TOC file within a directory-format dump, which is a rarely-used  
scenario that we weren't even testing before 20ec99589.  
  
(2) No corruption actually occurs unless sizeof(long) is different  
from sizeof(off_t) and the platform is big-endian.  
  
(3) Some platforms have already fixed the configuration instability,  
at least sufficiently for their environments.  
  
Despite (3), it seems foolish to assume that the problem isn't  
going to be present in some environments for a long time to come.  
Hence, avoid relying on this macro.  We can just #undef it and  
fall back on the underlying function of the same name.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2122679.1760846783@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : c29d32d27bd3ef09fd7c4c372d2be18f4b8ad195    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Oct 2025 18:36:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Oct 2025 18:36:21 -0400    

We must tell init about each role name we plan to connect as,  
else SSPI auth fails.  Similar to previous patches such as  
14793f471, 973542866.  
  
Oversight in 208927e65, per buildfarm member drongo.  
(Although that was back-patched to v13, the test script  
only exists in v16 and up.)  

commit   : 0fe07fa115f520a67b9a9180cea703e91d8c7ac4    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 18 Oct 2025 18:18:19 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 18 Oct 2025 18:18:19 +0200    

It is possible to have a non-inherited not-null constraint on an  
inherited column, but we were failing to preserve such constraints  
during pg_upgrade where the source is 17 or older, because of a bug in  
the pg_dump query for it.  Oversight in commit 14e87ffa5c54.  Fix that  
query.  In passing, touch-up a bogus nearby comment introduced by the  
same commit.  
  
In version 17, make the regression tests leave a table in this  
situation, so that this scenario is tested in the cross-version upgrade  
tests of 18 and up.  
  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Reported-by: Andrew Bille <andrewbille@gmail.com>  
Bug: #19074  
Backpatch-through: 18  
Discussion: https://postgr.es/m/19074-ae2548458cf0195c@postgresql.org  

commit   : 162e70ea06eb31dfe8f75bf508afde323eb0b077    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 18 Oct 2025 17:50:10 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 18 Oct 2025 17:50:10 +0200    

Apparently, commit 04bc2c42f765 failed to notice that DO_FK_CONSTRAINT  
objects require identical handling as DO_CONSTRAINT ones, which causes  
some pg_upgrade tests in debug builds to fail spuriously.  Add that.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/202510181201.k6y75v2tpf5r@alvherre.pgsql  

commit   : 0b6a02f0355c8950ffe22b52eac86f6261e19caf    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 18 Oct 2025 16:07:41 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 18 Oct 2025 16:07:41 +1300    

This fixes an unlikely issue when fetching GROUPING SET results from  
their internally stored hash tables.  It was possible in rare cases that  
the hash iterator would be set up incorrectly which could result in a  
crash.  
  
This was introduced in 4d143509c, so backpatch to v18.  
  
Many thanks to Yuri Zamyatin for reporting and helping to debug this  
issue.  
  
Bug: #19078  
Reported-by: Yuri Zamyatin <yuri@yrz.am>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/19078-dfd62f840a2c0766@postgresql.org  
Backpatch-through: 18  

commit   : aa151022ec13f6a24f70c30dbfb9a5747db620e8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 17 Oct 2025 21:44:42 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 17 Oct 2025 21:44:42 +0200    

Commit a1b4f289beec improved the hashjoin sizing to also consider the  
memory used by BufFiles for batches. The code however had multiple  
issues, making it ineffective or not working as expected in some cases.  
  
* The amount of memory needed by buffers was calculated using uint32,  
  so it would overflow for nbatch >= 262144. If this happened the loop  
  would exit prematurely and the memory usage would not be reduced.  
  
  The nbatch overflow is fixed by reworking the condition to not use a  
  multiplication at all, so there's no risk of overflow. An explicit  
  cast was added to a similar calculation in ExecHashIncreaseBatchSize.  
  
* The loop adjusting the nbatch value used hash_table_bytes to calculate  
  the old/new size, but then updated only space_allowed. The consequence  
  is the total memory usage was not reduced, but all the memory saved by  
  reducing the number of batches was used for the internal hash table.  
  
  This was fixed by using only space_allowed. This is also more correct,  
  because hash_table_bytes does not account for skew buckets.  
  
* The code was also doubling multiple parameters (e.g. the number of  
  buckets for hash table), but was missing overflow protections.  
  
  The loop now checks for overflow, and terminates if needed. It'd be  
  possible to cap the value and continue the loop, but it's not worth  
  the complexity. And the overflow implies the in-memory hash table is  
  already very large anyway.  
  
While at it, rework the comment explaining how the memory balancing  
works, to make it more concise and easier to understand.  
  
The initial nbatch overflow issue was reported by Vaibhav Jain. The  
other issues were noticed by me and Melanie Plageman. Fix by me, with a  
lot of review and feedback by Melanie.  
  
Backpatch to 18, where the hashjoin memory balancing was introduced.  
  
Reported-by: Vaibhav Jain <jainva@google.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CABa-Az174YvfFq7rLS+VNKaQyg7inA2exvPWmPWqnEn6Ditr_Q@mail.gmail.com  

commit   : 3ccf8e9ac96e87c9ec4693d437f3c5531eafa1b6    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 17 Oct 2025 11:36:50 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 17 Oct 2025 11:36:50 -0500    

pg_prewarm() currently checks for SELECT privileges on the target  
relation.  However, indexes do not have access rights of their own,  
so a role may be denied permission to prewarm an index despite  
having the SELECT privilege on its parent table.  This commit fixes  
this by locking the parent table before the index (to avoid  
deadlocks) and checking for SELECT on the parent table.  Note that  
the code is largely borrowed from  
amcheck_lock_relation_and_check().  
  
An obvious downside of this change is the extra AccessShareLock on  
the parent table during prewarming, but that isn't expected to  
cause too much trouble in practice.  
  
Author: Ayush Vatsa <ayushvatsa1810@gmail.com>  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/CACX%2BKaMz2ZoOojh0nQ6QNBYx8Ak1Dkoko%3DD4FSb80BYW%2Bo8CHQ%40mail.gmail.com  
Backpatch-through: 13  

commit   : 150a1b328778b1594f543057b6d3fbb78178f8b2    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 17 Oct 2025 14:21:26 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 17 Oct 2025 14:21:26 +0200    

The SSL tests for pg_stat_ssl tries to exactly match the serial  
from the certificate by extracting it with the openssl binary.  
If that fails due to the binary not being available, a fallback  
match is used, but the attempt to execute a missing binary adds  
a warning to the output which can confuse readers for a failure  
in the test.  Fix by only attempting if the openssl binary was  
found by autoconf/meson.  
  
Backpatch down to v16 where commit c8e4030d1bdd made the test  
use the OPENSSL variable from autoconf/meson instead of a hard-  
coded value.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Christoph Berg <myon@debian.org>  
Discussion: https://postgr.es/m/aNPSp1-RIAs3skZm@msg.df7cb.de  
Backpatch-through: 16  

commit   : 3a7225ed37fc0819f689e17435dc590fd2b8980d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Oct 2025 13:06:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Oct 2025 13:06:09 +0900    

042_low_level_backup compared the result of a query two times with a  
comparison operator based on an integer, while the result should be  
compared with a string.  
  
The outcome of the tests is currently not impacted by this change.  
However, it could be possible that the tests fail to detect future  
issues if the query results become different, for some reason.  
  
Oversight in 99b4a63bef94.  
  
Author: Sadhuprasad Patro <b.sadhu@gmail.com>  
Discussion: https://postgr.es/m/CAFF0-CHhwNx_Cv2uy7tKjODUbeOgPrJpW4Rpf1jqB16_1bU2sg@mail.gmail.com  
Backpatch-through: 17  

commit   : 39e22b3adaa7738da4d7ff536a2ab5e303e7c890    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Oct 2025 13:01:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Oct 2025 13:01:17 +0900    

040_pg_createsubscriber has been calling safe_psql(), that returns the  
result of a SQL query, with ok() without checking the result generated  
(in this case 't', for a number of publications).  
  
The outcome of the tests is currently not impacted by this change.  
However, it could be possible that the test fails to detect future  
issues if the query results become different.  
  
The test is rewritten so as the number of publications is checked.  This  
is not the fix suggested originally by the author, but this is more  
reliable in the long run.  
  
Oversight in e5aeed4b8020.  
  
Author: Sadhuprasad Patro <b.sadhu@gmail.com>  
Discussion: https://postgr.es/m/CAFF0-CHhwNx_Cv2uy7tKjODUbeOgPrJpW4Rpf1jqB16_1bU2sg@mail.gmail.com  
Backpatch-through: 18  

commit   : 6aa04a60cbf5d7460c5444822b3127f5bdbc7930    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 16 Oct 2025 20:21:05 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 16 Oct 2025 20:21:05 +0200    

The original formulation failed to take into account the fact that for  
the PGXS case, the source dir is not $(top_srcdir), so it ended up not  
doing anything.  Handle it explicitly.  
  
Author: Ryo Matsumura <matsumura.ryo@fujitsu.com>  
Reviewed-by: Bryan Green <dbryan.green@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/TYCPR01MB113164770FB0B0BE6ED21E68EE8DCA@TYCPR01MB11316.jpnprd01.prod.outlook.com  

commit   : 1296dcf18b1cf3a064e5981c1655d133f0b1206f    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 16 Oct 2025 14:01:50 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 16 Oct 2025 14:01:50 +0900    

EvalPlanQualStart() failed to propagate es_partition_directory into  
the child EState used for EPQ rechecks. When execution time partition  
pruning ran during the EPQ scan, executor code dereferenced a NULL  
partition directory and crashed.  
  
Previously, propagating es_partition_directory into the EPQ EState was  
unnecessary because CreatePartitionPruneState(), which sets it on  
demand, also initialized the exec-pruning context.  After commit  
d47cbf474, CreatePartitionPruneState() now initializes only the init-  
time pruning context, leaving exec-pruning context initialization to  
ExecInitNode(). Since EvalPlanQualStart() runs only ExecInitNode() and  
not CreatePartitionPruneState(), it can encounter a NULL  
es_partition_directory.  Other executor fields initialized during  
CreatePartitionPruneState() are already copied into the child EState  
thanks to commit 8741e48e5d, but es_partition_directory was missed.  
  
Fix by borrowing the parent estate's  es_partition_directory in  
EvalPlanQualStart(), and by clearing that field in EvalPlanQualEnd()  
so the parent remains responsible for freeing the directory.  
  
Add an isolation test permutation that triggers EPQ with execution-  
time partition pruning, the case that reproduces this crash.  
  
Bug: #19078  
Reported-by: Yuri Zamyatin <yuri@yrz.am>  
Diagnosed-by: David Rowley <dgrowleyml@gmail.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Co-authored-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/19078-dfd62f840a2c0766@postgresql.org  
Backpatch-through: 18  

commit   : 15d7dded0e930b5781b2c0e591c1b45eb078a248    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 15 Oct 2025 13:14:00 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 15 Oct 2025 13:14:00 -0500    

Commit c8af5019be added a forward declaration for this typedef that  
caused redefinitions, which are not valid in C99.  
  
Per buildfarm members longfin and sifaka.  
  
Discussion: https://postgr.es/m/aO_fzfnKVXMd_RUM%40nathan  
Backpatch-through: 18 only  

commit   : c8af5019bee5c57502db830f8005a01cba60fee0    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 15 Oct 2025 12:47:33 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 15 Oct 2025 12:47:33 -0500    

Presently, these functions look up the relation's OID, lock it, and  
then check privileges.  Not only does this approach provide no  
guarantee that the locked relation matches the arguments of the  
lookup, but it also allows users to briefly lock relations for  
which they do not have privileges, which might enable  
denial-of-service attacks.  This commit adjusts these functions to  
use RangeVarGetRelidExtended(), which is purpose-built to avoid  
both of these issues.  The new RangeVarGetRelidCallback function is  
somewhat complicated because it must handle both tables and  
indexes, and for indexes, we must check privileges on the parent  
table and lock it first.  Also, it needs to handle a couple of  
extremely unlikely race conditions involving concurrent OID reuse.  
  
A downside of this change is that the coding doesn't allow for  
locking indexes in AccessShare mode anymore; everything is locked  
in ShareUpdateExclusive mode.  Per discussion, the original choice  
of lock levels was intended for a now defunct implementation that  
used in-place updates, so we believe this change is okay.  
  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/Z8zwVmGzXyDdkAXj%40nathan  
Backpatch-through: 18  

commit   : b141443259845de6901be70e8eaa090a483ab68f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 15 Oct 2025 17:15:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 15 Oct 2025 17:15:01 +0900    

If inside an EPQ recheck, ExecScanFetch would run the recheck method  
function for foreign/custom joins even if they aren't descendant nodes  
in the EPQ recheck plan tree, which is problematic at least in the  
foreign-join case, because such a foreign join isn't guaranteed to have  
an alternative local-join plan required for running the recheck method  
function; in the postgres_fdw case this could lead to a segmentation  
fault or an assert failure in an assert-enabled build when running the  
recheck method function.  
  
Even if inside an EPQ recheck, any scan nodes that aren't descendant  
ones in the EPQ recheck plan tree should be normally processed by using  
the access method function; fix by modifying ExecScanFetch so that if  
inside an EPQ recheck, it runs the recheck method function for  
foreign/custom joins that are descendant nodes in the EPQ recheck plan  
tree as before and runs the access method function for foreign/custom  
joins that aren't.  
  
This fix also adds to postgres_fdw an isolation test for an EPQ recheck  
that caused issues stated above.  
  
Oversight in commit 385f337c9.  
  
Reported-by: Kristian Lejao <kristianlejao@gmail.com>  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoBpo6Gx55FBOW+9s5X=nUw3Xpq64v35fpDEKsTERnc4TQ@mail.gmail.com  
Backpatch-through: 13  

commit   : a6598aac5295fcb169bd251cbc9fe125fa019a2d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Oct 2025 08:31:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Oct 2025 08:31:24 +0900    

The version number calculated by read_pg_version_file() is multiplied  
once by 10000, to be able to do comparisons based on PG_VERSION_NUM or  
equivalents with a minor version included.  However, the version number  
given sync_pgdata() was multiplied by 10000 a second time, leading to an  
overestimated number.  
  
This issue was harmless (still incorrect) as pg_combinebackup does not  
support versions of Postgres older than v10, and sync_pgdata() only  
includes a version check due to the rename of pg_xlog/ to pg_wal/.  This  
folder rename happened in the development cycle of v10.  This would  
become a problem if in the future  sync_pgdata() is changed to have more  
version-specific checks.  
  
Oversight in dc212340058b, so backpatch down to v17.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/aOil5d0y87ZM_wsZ@paquier.xyz  
Backpatch-through: 17  

commit   : b48ae226e6c31f5e1801e626d7602be7969f0fbd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Oct 2025 17:56:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Oct 2025 17:56:45 -0400    

log_error() would probably fail completely if used, and would  
certainly print garbage for anything that needed to be interpolated  
into the message, because it was failing to use the correct printing  
subroutine for a va_list argument.  
  
This bug likely went undetected because the error cases this code  
is used for are rarely exercised - they only occur when Windows  
security API calls fail catastrophically (out of memory, security  
subsystem corruption, etc).  
  
The FRONTEND variant can be fixed just by calling vfprintf()  
instead of fprintf().  However, there was no va_list variant  
of write_stderr(), so create one by refactoring that function.  
Following the usual naming convention for such things, call  
it vwrite_stderr().  
  
Author: Bryan Green <dbryan.green@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAF+pBj8goe4fRmZ0V3Cs6eyWzYLvK+HvFLYEYWG=TzaM+tWPnw@mail.gmail.com  
Backpatch-through: 13  

commit   : f691e72585a3811a05e37d27e898b1d816ff9ff9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:25:34 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:25:34 +1300    

There was some confusion around how to adjust the n_distinct estimates  
for partitioned tables.  Here we try and clarify that  
n_distinct_inherited needs to be adjusted rather than n_distinct.  
  
Also fix some slightly misleading text which was talking about table  
size rather than table rows, fix a grammatical error, and adjust some  
text which indicated that ANALYZE was performing calculations based on  
the n_distinct settings.  Really it's the query planner that does this  
and ANALYZE only stores the overridden n_distinct estimate value in  
pg_statistic.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAApHDvrL7a-ZytM1SP8Uk9nEw9bR2CPzVb+uP+bcNj=_q-ZmVw@mail.gmail.com  

commit   : 6a4009747c3687bf1fdfef5f0b75c33681f37a10    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Oct 2025 12:44:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Oct 2025 12:44:20 -0400    

pg_dump expects a read request of zero bytes to be a no-op; see for  
example ReadStr().  Gzip_read got this wrong and falsely supposed  
that the resulting gzret == 0 indicated an error.  We could complicate  
that error-checking logic some more, but it seems best to just fall  
out immediately when passed size == 0.  
  
This bug breaks the nominally-supported case of manually gzip'ing  
the toc.dat file within a directory-style dump, so back-patch to v16  
where this code came in.  (Prior branches already have a short-circuit  
for size == 0 before their only gzread call.)  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/3515357.1760128017@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : de2b62f4758786ae353baf161acb4a43dd9e0c8c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 13 Oct 2025 15:31:25 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 13 Oct 2025 15:31:25 +0200    

Since protocol version 3.2 the CancelRequest does not have a fixed size  
length anymore. The protocol docs still listed the length field to be a  
constant number though. This fixes that.  
  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reported-by: Dmitry Igrishin <dmitigr@gmail.com>  
Backpatch-through: 18  

commit   : 656736402f54f840a90acfae7db826c53d0a8b1d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 13 Oct 2025 15:28:20 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 13 Oct 2025 15:28:20 +0200    

Reported-By: Pavel Luzanov <p.luzanov@postgrespro.ru>  
Discussion: https://postgr.es/m/175976566145.768.4645962241073007347@wrigleys.postgresql.org  
Backpatch-through: 18  

commit   : 9de72704e060720c58f75a715e3f217ad8635276    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 12 Oct 2025 14:04:06 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 12 Oct 2025 14:04:06 -0400    

Remove a variable that is no longer in use following commit 9a2e2a28.  
It's not immediately clear why there were no compiler warnings about  
this oversight.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Backpatch-through: 18  

commit   : 661b320ed4e0abf7063fc51597803cf3fdb13a85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Oct 2025 16:33:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Oct 2025 16:33:55 -0400    

In commit a45c78e32 I removed the only regression test case that  
reaches this function, because it turns out that we only use it  
if reading an LZ4-compressed blobs.toc file in a directory dump,  
and that is a state that has to be created manually.  That seems  
like a bad thing to not test, not so much for LZ4Stream_gets()  
itself as because it means the squirrely eol_flag logic in  
LZ4Stream_read_internal() is not tested.  
  
The reason for the change was that I thought the lz4 program did not  
have any way to perform compression without explicit specification  
of the output file name.  However, it turns out that the syntax  
synopsis in its man page is a lie, and if you read enough of the  
man page you find out that with "-m" it will do what's needful.  
So restore the manual compression step in that test case.  
  
Noted while testing some proposed changes in pg_dump's compression  
logic.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3515357.1760128017@sss.pgh.pa.us  
Backpatch-through: 17  

commit   : 08c037dff96103f607d30c487d11d3bf43a531ea    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 11 Oct 2025 20:30:12 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 11 Oct 2025 20:30:12 +0200    

Commit 71f4c8c6f74b (which implemented DETACH CONCURRENTLY) added code  
to create a separate table constraint when a table is detached  
concurrently, identical to the partition constraint, on the theory that  
such a constraint was needed in case the optimizer had constructed any  
query plans that depended on the constraint being there.  However, that  
theory was apparently bogus because any such plans would be invalidated.  
  
For hash partitioning, those constraints are problematic, because their  
expressions reference the OID of the parent partitioned table, to which  
the detached table is no longer related; this causes all sorts of  
problems (such as inability of restoring a pg_dump of that table, and  
the table no longer working properly if the partitioned table is later  
dropped).  
  
We'd like to get rid of all those constraints.  In fact, for branch  
master, do that -- no longer create any substitute constraints.  
However, out of fear that some users might somehow depend on these  
constraints for other partitioning strategies, for stable branches  
(back to 14, which added DETACH CONCURRENTLY), only do it for hash  
partitioning.  
  
(If you repeatedly DETACH CONCURRENTLY and then ATTACH a partition, then  
with this constraint addition you don't need to scan the table in the  
ATTACH step, which presumably is good.  But if users really valued this  
feature, they would have requested that it worked for non-concurrent  
DETACH also.)  
  
Author: Haiyang Li <mohen.lhy@alibaba-inc.com>  
Reported-by: Fei Changhong <feichanghong@qq.com>  
Reported-by: Haiyang Li <mohen.lhy@alibaba-inc.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/18371-7fef49f63de13f02@postgresql.org  
Discussion: https://postgr.es/m/19070-781326347ade7c57@postgresql.org  

commit   : 33e7b4a7c7da6db40c57a224a7cf9b2ebac28861    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 11 Oct 2025 16:39:22 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 11 Oct 2025 16:39:22 +0200    

Introduced by my (Álvaro's) commit 9e4f914b5eba, which was itself  
backpatched to pg10, though only pg15 and up contain the problem  
because of commit 9c08aea6a309.  
  
This isn't a particularly significant leak, but given the fix is  
trivial, we might as well backpatch to all branches where it applies, so  
do that.  
  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/x4odfdlrwvsjawscnqsqjpofvauxslw7b4oyvxgt5owoyf4ysn@heafjusodrz7  

commit   : 61de81a496dcd50187e8de765f4c3ed0267764ef    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:23 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:23 -0400    

An assertion in _bt_killitems expected the scan's currPos state to  
contain a valid LSN, saved from when currPos's page was initially read.  
The assertion failed to account for the fact that even logged relations  
can have leaf pages with an invalid LSN when built with wal_level set to  
"minimal".  Remove the faulty assertion.  
  
Oversight in commit e6eed40e (though note that the assertion was  
backpatched to stable branches before 18 by commit 7c319f54).  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Matthijs van der Vleuten <postgresql@zr40.nl>  
Bug: #19082  
Discussion: https://postgr.es/m/19082-628e62160dbbc1c1@postgresql.org  
Backpatch-through: 13  

commit   : ed047ce0a881e628a17e0a3fe6a19c0faa155563    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 11:51:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 11:51:50 +0900    

Issue found while browsing this area of the code, introduced and  
copy-pasted around by 2258e76f90bf.  
  
Backpatch-through: 15  

commit   : 9a6ea00ac8c09fc73a8f725517ad7aea7664b1bc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:48 +0900    

An error happening while a slot data is saved on disk in  
SaveSlotToPath() could cause a state.tmp file (temporary file holding  
the slot state data, renamed to its permanent name at the end of the  
function) to remain around after it has been created.  This temporary  
file is created with O_EXCL, meaning that if an existing state.tmp is  
found, its creation would fail.  This would prevent the slot data to be  
saved, requiring a manual intervention to remove state.tmp before being  
able to save again a slot.  Possible scenarios where this temporary file  
could remain on disk is for example a ENOSPC case (no disk space) while  
writing, syncing or renaming it.  The bug reports point to a write  
failure as the principal cause of the problems.  
  
Using O_TRUNC has been argued back in 2019 as a potential solution to  
discard any temporary file that could exist.  This solution was rejected  
as O_EXCL can also act as a safety measure when saving the slot state,  
crash recovery offering cleanup guarantees post-crash.  This commit uses  
the alternative approach that has been suggested by Andres Freund back  
in 2019.  When the temporary state file cannot be written, synced,  
closed or renamed (note: not when created!), an unlink() is used to  
remove the temporary state file while holding the in-progress I/O  
LWLock, so as any follow-up attempts to save a slot's data would not  
choke on an existing file that remained around because of a previous  
failure.  
  
This problem has been reported a few times across the years, going back  
to 2019, but for some reason I have never come back to do something  
about it and it has been forgotten.  A recent report has reminded me  
that this was still a problem.  
  
Reported-by: Kevin K Biju <kevinkbiju@gmail.com>  
Reported-by: Sergei Kornilov <sk@zsrv.org>  
Reported-by: Grigory Smolkin <g.smolkin@postgrespro.ru>  
Discussion: https://postgr.es/m/CAM45KeHa32soKL_G8Vk38CWvTBeOOXcsxAPAs7Jt7yPRf2mbVA@mail.gmail.com  
Discussion: https://postgr.es/m/3559061693910326@qy4q4a6esb2lebnz.sas.yp-c.yandex.net  
Discussion: https://postgr.es/m/08bbfab1-a61d-3750-fc18-4ab2c1aa7f09@postgrespro.ru  
Backpatch-through: 13  

commit   : 32b95fc71b5825ad1722b821ae2508657970ce79    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 9 Oct 2025 10:59:29 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 9 Oct 2025 10:59:29 -0700    

While pgoutput caches relation synchronization information in  
RelationSyncCache that resides in CacheMemoryContext, each entry's  
information (such as row filter expressions and column lists) is  
stored in the entry's private memory context (entry_cxt in  
RelationSyncEntry), which is a descendant memory context of the  
decoding context. If a logical decoding invoked via SQL functions like  
pg_logical_slot_get_binary_changes fails with an error, subsequent  
logical decoding executions could access already-freed memory of the  
entry's cache, resulting in a crash.  
  
With this change, it's ensured that RelationSyncCache is cleaned up  
even in error cases by using a memory context reset callback function.  
  
Backpatch to 15, where entry_cxt was introduced for column filtering  
and row filtering.  
  
While the backbranches v13 and v14 have a similar issue where  
RelationSyncCache persists even after an error when pgoutput is used  
via SQL API, we decided not to backport this fix. This decision was  
made because v13 is approaching its final minor release, and we won't  
have an chance to fix any new issues that might arise. Additionally,  
since using pgoutput via SQL API is not a common use case, the risk  
outwights the benefit. If we receive bug reports, we can consider  
backporting the fixes then.  
  
Author: vignesh C <vignesh21@gmail.com>  
Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2Ekf0aDPkOA@mail.gmail.com  
Backpatch-through: 15  

commit   : dc9125111b4a0b955c8a4a44ce2bbac72479e11f    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 9 Oct 2025 01:07:52 -0400    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 9 Oct 2025 01:07:52 -0400    

SQL/JSON functions such as JSON_VALUE could fail with "unrecognized  
node type" errors when a DEFAULT clause contained an explicit COLLATE  
expression. That happened because assign_collations_walker() could  
invoke exprSetCollation() on a JsonBehavior expression whose DEFAULT  
still contained a CollateExpr, which exprSetCollation() does not  
handle.  
  
For example:  
  
  SELECT JSON_VALUE('{"a":1}', '$.c' RETURNING text  
                    DEFAULT 'A' COLLATE "C" ON EMPTY);  
  
Fix by validating in transformJsonBehavior() that the DEFAULT  
expression's collation matches the enclosing JSON expression’s  
collation. In exprSetCollation(), replace the recursive call on the  
JsonBehavior expression with an assertion that its collation already  
matches the target, since the parser now enforces that condition.  
  
Reported-by: Jian He <jian.universality@gmail.com>  
Author: Jian He <jian.universality@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHVwYYSyiVQ6o+PsRX6zQ7rAFinh_fv1kCfTsT1xG4Zeg@mail.gmail.com  
Backpatch-through: 17  

commit   : 9ea4a2b4f1cccba37935522920a933c67421476b    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 7 Oct 2025 15:02:20 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 7 Oct 2025 15:02:20 +0200    

Author: Shinya Kato <shinya11.kato@gmail.com>  
Discussion: https://postgr.es/m/CAOzEurRgpAh9dsbEM88FPOhNaV_PkdL6p_9MJatcrNf9wXw1nw@mail.gmail.com  
Backpatch-through: 18  

commit   : d83879a32b481f0e23cd8a14f7849cff3f8898b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Oct 2025 16:27:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Oct 2025 16:27:47 -0400    

On Windows, this code did not handle error conditions correctly at  
all, since it looked at "errno" which is not used for socket-related  
errors on that platform.  This resulted, for example, in failure  
to connect to a PostgreSQL server with GSSAPI enabled.  
  
We have a convention for dealing with this within libpq, which is to  
use SOCK_ERRNO and SOCK_ERRNO_SET rather than touching errno directly;  
but the GSSAPI code is a relative latecomer and did not get that memo.  
(The equivalent backend code continues to use errno, because the  
backend does this differently.  Maybe libpq's approach should be  
rethought someday.)  
  
Apparently nobody tries to build libpq with GSSAPI support on Windows,  
or we'd have heard about this before, because it's been broken all  
along.  Back-patch to all supported branches.  
  
Author: Ning Wu <ning94803@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFGqpvg-pRw=cdsUpKYfwY6D3d-m9tw8WMcAEE7HHWfm-oYWvw@mail.gmail.com  
Backpatch-through: 13  

commit   : 76613b539ac5d87d26f8026ec1e2cd11d0583b3d    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 3 Oct 2025 16:05:37 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 3 Oct 2025 16:05:37 +0700    

In similar vein to commit ccc8194e427, a reset instance of a shared  
memory TID store happened to occupy the same private memory as the old  
one for the entry point, since the chunk freed after the last round  
of index vacuuming was put on the context's freelist. The failure  
to update the vacrel->dead_items pointer was evident by nudging the  
system to allocate memory in a different area. This was not discovered  
at the time of the earlier commit since our regression tests didn't  
cover multiple index passes with parallel vacuum.  
  
Backpatch to v17, when TidStore came in.  
  
Author: Kevin Oommen Anish <kevin.o@zohocorp.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Tested-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/199a07cbdfc.7a1c4aac25838.1675074408277594551%40zohocorp.com  
Backpatch-through: 17  

commit   : c00637b5fdbf756d48021db82f1f9a877429e2a7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:00 +0900    

Currently, pgbench aborts when a COPY response is received in  
readCommandResponse().  However, as PQgetResult() returns an empty  
result when there is no asynchronous result, through getCopyResult(),  
the logic done at the end of readCommandResponse() for the error path  
leads to an infinite loop.  
  
This commit forcefully exits the COPY state with PQendcopy() before  
moving to the error handler when fiding a COPY state, avoiding the  
infinite loop.  The COPY protocol is not supported by pgbench anyway, as  
an error is assumed in this case, so giving up is better than having the  
tool be stuck forever.  pgbench was interruptible in this state.  
  
A TAP test is added to check that an error happens if trying to use  
COPY.  
  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Discussion: https://postgr.es/m/CAO6_XqpHyF2m73ifV5a=5jhXxH2chk=XrgefY+eWWPe2Eft3=A@mail.gmail.com  
Backpatch-through: 13  

commit   : fc295beb7b74d1f216a53cab61d22027121a763e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:10 +0900    

pgstattuple checks the state of the pages retrieved for gist and hash  
using some check functions from each index AM, respectively  
gistcheckpage() and _hash_checkpage().  When these are called, they  
would fail when bumping on data that is found as incorrect (like opaque  
area size not matching, or empty pages), contrary to btree that simply  
discards these cases and continues to aggregate data.  
  
Zero pages can happen after a crash, with these AMs being able to do an  
internal cleanup when these are seen.  Also, sporadic failures are  
annoying when doing for example a large-scale diagnostic query based on  
pgstattuple with a join of pg_class, as it forces one to use tricks like  
quals to discard hash or gist indexes, or use a PL wrapper able to catch  
errors.  
  
This commit changes the reports generated for btree, gist and hash to  
be more user-friendly;  
- When seeing an empty page, report it as free space.  This new rule  
applies to gist and hash, and already applied to btree.  
- For btree, a check based on the size of BTPageOpaqueData is added.  
- For gist indexes, gistcheckpage() is not called anymore, replaced by a  
check based on the size of GISTPageOpaqueData.  
- For hash indexes, instead of _hash_getbuf_with_strategy(), use a  
direct call to ReadBufferExtended(), coupled with a check based on  
HashPageOpaqueData.  The opaque area size check was already used.  
- Pages that do not match these criterias are discarded from the stats  
reports generated.  
  
There have been a couple of bug reports over the years that complained  
about the current behavior for hash and gist, as being not that useful,  
with nothing being done about it.  Hence this change is backpatched down  
to v13.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Nitin Motiani <nitinmotiani@google.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/CAH5HC95gT1J3dRYK4qEnaywG8RqjbwDdt04wuj8p39R=HukayA@mail.gmail.com  
Backpatch-through: 13  

commit   : 8474a3a15056e06ed797530db5419fee8bfd053a    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 1 Oct 2025 08:14:23 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 1 Oct 2025 08:14:23 -0700    

Some macOS machines are having trouble with 002_inline, which executes  
the JSON parser test executables hundreds of times in a nested loop.  
Both developer machines and buildfarm critters have shown excessive test  
durations, upwards of 20 seconds.  
  
Push the innermost loop of 002_inline, which iterates through differing  
chunk sizes, down into the test executable. (I'd eventually like to push  
all of the JSON unit tests down into C, but this is an easy win in the  
short term.) Testers have reported a speedup between 4-9x.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Suggested-by: Andres Freund <andres@anarazel.de>  
Tested-by: Andrew Dunstan <andrew@dunslane.net>  
Tested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Tested-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CA%2BTgmobKoG%2BgKzH9qB7uE4MFo-z1hn7UngqAe9b0UqNbn3_XGQ%40mail.gmail.com  
Backpatch-through: 17  

commit   : 29aabbc432693b3fcda287b953c832d62dda7946    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Sep 2025 23:52:28 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Sep 2025 23:52:28 +0900    

pgbench uses readCommandResponse() to process server responses.  
When readCommandResponse() encounters an error during a call to  
PQgetResult() to fetch the current result, it attempts to report it  
with an additional error message from PQerrorMessage(). However,  
previously, this extra error message could be lost or become incorrect.  
  
The cause was that after fetching the current result (and detecting  
an error), readCommandResponse() called PQgetResult() again to  
peek at the next result. This second call could overwrite the libpq  
connection's error message before the original error was reported,  
causing the error message retrieved from PQerrorMessage() to be  
lost or overwritten.  
  
This commit fixes the issue by updating readCommandResponse()  
to use PQresultErrorMessage() instead of PQerrorMessage()  
to retrieve the error message generated when the PQgetResult()  
for the current result causes an error, ensuring the correct message  
is reported.  
  
Backpatch to all supported versions.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/20250925110940.ebacc31725758ec47d5432c6@sraoss.co.jp  
Backpatch-through: 13  

commit   : b5f898944d1226f8daeb0bda58098f645582c80f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Sep 2025 09:02:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Sep 2025 09:02:35 +0900    

Contrary to its siblings for the archiver, the bgwriter and the  
checkpointer stats, pgstat_report_inj_fixed() can be called  
concurrently.  This was causing an assertion failure, while messing up  
with the stats.  
  
This code is aimed at being a template for extension developers, so it  
is not a critical issue, but let's be correct.  This module has also  
been useful for some benchmarking, at least for me, and that was how I  
have discovered this issue.  
  
Oversight in f68cd847fa40.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com>  
Discussion: https://postgr.es/m/aNnXbAXHPFUWPIz2@paquier.xyz  
Backpatch-through: 18  

commit   : d024160fffc8065b9b007c6be1b5f907eb2122c9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 29 Sep 2025 11:15:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 29 Sep 2025 11:15:44 -0700    

Neighbor get_statistics_object_oid() ignores objects in pg_temp, as has  
been the standard for non-relation, non-type namespace searches since  
CVE-2007-2138.  Hence, most operations that name a statistics object  
correctly decline to map an unqualified name to a statistics object in  
pg_temp.  StatisticsObjIsVisibleExt() did not.  Consequently,  
pg_statistics_obj_is_visible() wrongly returned true for such objects,  
psql \dX wrongly listed them, and getObjectDescription()-based ereport()  
and pg_describe_object() wrongly omitted namespace qualification.  Any  
malfunction beyond that would depend on how a human or application acts  
on those wrong indications.  Commit  
d99d58cdc8c0b5b50ee92995e8575c100b1a458a introduced this.  Back-patch to  
v13 (all supported versions).  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/20250920162116.2e.nmisch@google.com  
Backpatch-through: 13  

commit   : 78a284b0b8d4add8457325b74144bd762156cb0e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Sep 2025 14:29:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Sep 2025 14:29:41 -0400    

Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be  
ignored in PL/pgSQL assignment statements.  It's not surprising that  
no one noticed, since such statements will throw an error if the query  
produces more than one row.  That eliminates most scenarios where  
advanced forms of GROUP BY could be useful, and indeed makes it hard  
even to find a simple test case.  Nonetheless it's wrong.  
  
This is directly the fault of be45be9c3 which added the groupDistinct  
field, but I think much of the blame has to fall on c9d529848, in  
which I incautiously supposed that we'd manage to keep two copies of  
a big chunk of parse-analysis logic in sync.  As a follow-up, I plan  
to refactor so that there's only one copy.  But that seems useful  
only in master, so let's use this one-line fix for the back branches.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : c736808e03b77052f2e08f43210ba64517ff64d6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 26 Sep 2025 21:23:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 26 Sep 2025 21:23:43 +0900    

When running pgbench with --verbose-errors option and a custom script that  
triggered retriable errors (e.g., serialization errors) in pipeline mode,  
an assertion failure could occur:  
  
    Assertion failed: (sql_script[st->use_file].commands[st->command]->type == 1), function commandError, file pgbench.c, line 3062.  
  
The failure happened because pgbench assumed these errors would only occur  
during SQL commands, but in pipeline mode they can also happen during  
\endpipeline meta command.  
  
This commit fixes the assertion failure by adjusting the assertion check to  
allow such errors during either SQL commands or \endpipeline.  
  
Backpatch to v15, where the assertion check was introduced.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGWQMOzNkQs-LmpDHdNC0h8dmAuUMRvZrEntQi5a-b=Kg@mail.gmail.com  

commit   : ef18eeeeaea7f64aadf198875670f9d6e56b52df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Sep 2025 13:29:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Sep 2025 13:29:02 -0400    

The functions test_stat_func() and test_stat_func2() had empty  
function bodies, so that they took very little time to run.  This made  
it possible that on machines with relatively low timer resolution the  
functions could return before the clock advanced, making the test fail  
(as seen on buildfarm members fruitcrow and hamerkop).  
  
To avoid that, pg_sleep for 10us during the functions.  As far as we  
can tell, all current hardware has clock resolution much less than  
that.  (The current implementation of pg_sleep will round it up to  
1ms anyway, but someday that might get improved.)  
  
Author: Michael Banck <mbanck@gmx.net>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/68d413a3.a70a0220.24c74c.8be9@mx.google.com  
Backpatch-through: 15  

commit   : 694057d236b114f8c750b996b9ca5b8a07424650    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Sep 2025 11:43:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Sep 2025 11:43:52 -0400    

If we already have an extension_state array but see a new extension_id  
much larger than the highest the extension_id we've previously seen,  
the old code might have failed to expand the array to a large enough  
size, leading to disaster. Also, if we don't have an extension array  
at all and need to create one, we should make sure that it's big enough  
that we don't have to resize it instantly.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: http://postgr.es/m/2949591.1758570711@sss.pgh.pa.us  
Backpatch-through: 18  

commit   : cbfcb7b466052518e3ddcc784946aa1cfa3f3460    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Sep 2025 11:23:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Sep 2025 11:23:27 -0400    

Fix assorted failures to conform to our normal style for function  
documentation, such as lack of parentheses and incorrect markup.  
  
Author: Marcos Pegoraro <marcos@f10.com.br>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAB-JLwbocrFjKfGHoKY43pHTf49Ca2O0j3WVebC8z-eQBMPJyw@mail.gmail.com  
Backpatch-through: 18  

commit   : efc26d17a7d40e58fa60f7f39dac892eb7f82cbb    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 25 Sep 2025 15:27:33 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 25 Sep 2025 15:27:33 +0200    

When defining an injection point there is no need to wrap the definition  
with USE_INJECTION_POINT guards, the INJECTION_POINT macro is available  
in all builds.  Remove to make the code consistent.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/OSCPR01MB14966C8015DEB05ABEF2CE077F51FA@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 17  

commit   : 47da1745244b25ba8b9396326d7f36e4ed1fb701    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 25 Sep 2025 14:45:08 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 25 Sep 2025 14:45:08 +0200    

... which silently propagates a lot of headers into many places  
via pgstat.h, as evidenced by the variety of headers that this patch  
needs to add to seemingly random places.  Add a minimum of typedefs to  
conflict.h to be able to remove execnodes.h, and fix the fallout.  
  
Backpatch to 18, where conflict.h first appeared.  
  
Discussion: https://postgr.es/m/202509191927.uj2ijwmho7nv@alvherre.pgsql  

commit   : 937741cbe506bcd59363008fa6a9038a981665cd    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 24 Sep 2025 21:39:38 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 24 Sep 2025 21:39:38 +0200    

Remove stray whitespace in xref tag.  
  
This was found due to a regression in xmllint 2.15.0 which flagged  
this as an error, and at the time of this commit no fix for xmllint  
has shipped.  
  
Author: Erik Wienhold <ewie@ewie.name>  
Discussion: https://postgr.es/m/f4c4661b-4e60-4c10-9336-768b7b55c084@ewie.name  
Backpatch-through: 17  

commit   : e5393fc2e4539bfd50e62ad4959c2712cb6505ce    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 24 Sep 2025 14:58:18 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 24 Sep 2025 14:58:18 +0200    

The usage screen incorrectly refered to the --docs option as --sgml.  
Backpatch down to v17 where this script was introduced.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/20250729.135638.1148639539103758555.horikyota.ntt@gmail.com  
Backpatch-through: 17  

commit   : 37fc5de438b423f34ba8551a9902a52963be98f5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Sep 2025 04:00:15 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Sep 2025 04:00:15 +0000    

Previously, the parallel apply worker used SIGINT to receive a graceful  
shutdown signal from the leader apply worker. However, SIGINT is also used  
by the LOCK_TIMEOUT handler to trigger a query-cancel interrupt. This  
overlap caused the parallel apply worker to miss LOCK_TIMEOUT signals,  
leading to incorrect behavior during lock wait/contention.  
  
This patch resolves the conflict by switching the graceful shutdown signal  
from SIGINT to SIGUSR2.  
  
Reported-by: Zane Duffield <duffieldzane@gmail.com>  
Diagnosed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where it was introduced  
Discussion: https://postgr.es/m/CACMiCkXyC4au74kvE2g6Y=mCEF8X6r-Ne_ty4r7qWkUjRE4+oQ@mail.gmail.com  

commit   : 178bbf403cc51d912b50f8ad8ea318e42cc29f42    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 08:03:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 08:03:25 +0900    

The package for the UUID library may be named "uuid" or "ossp-uuid", and  
meson.build has been using a single call of dependency() with multiple  
names, something only supported since meson 0.60.0.  
  
The minimum version of meson supported by Postgres is 0.57.2 on HEAD,  
since f039c2244110, and 0.54 on stable branches down to 16.  
  
Author: Oreo Yang <oreo.yang@hotmail.com>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/OS3P301MB01656E6F91539770682B1E77E711A@OS3P301MB0165.JPNP301.PROD.OUTLOOK.COM  
Backpatch-through: 16