PostgreSQL 17.7 commit log

commit   : fbb530a3dff569222bea7098ad4de3d8bde97740    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 16:53:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 16:53:58 -0500    

commit   : 2c0382f98b3fa05f482b94c706169f6bebbc92ea    
  
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   : e2fb3dfa817fbe89494a62c100e9cb442f4d6b15    
  
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   : f5999f01815969dfe8df33bac9c0f1aa38dd6cd5    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:03 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:03 -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   : 3b5a61d4139180f00579621a3756411c1daa551b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 13:02:28 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 13:02:28 +0100    

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

commit   : d40ad00c2f5af68370de553343ea323f8c24d8eb    
  
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   : 03d9140cbd00caf946c59e154ebb3af651a27306    
  
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   : 17bf6f1098b54f0732c1596bd6568ba42035e2a9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:56:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:56:17 +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   : b841c91c7b552fee2a0e1a665d7c5e2f28f0e078    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:43:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:43:24 +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   : 33727aff18d05f24232e7fffc3bde310203ece96    
  
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   : 07f787e57399ad6108c181b020723db24fa1dbe0    
  
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.  
  
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   : 726e77d7a94fd6d6ad99e439351ae6d4a48d3441    
  
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   : d898e6846979e75728acfa8eedebd25b77786073    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:02 +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   : e1445d1bf718ec38da986f5d41de91f030df6d01    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:15:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:15:02 +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   : 61cd67425f1ad907c02cd2470eff69ba85585ed2    
  
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   : a9515f294de153360e58d17a9aa468532cbab7e5    
  
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   : 1dad5594c19ed46672b4fbad0527df63e502d444    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:24 +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   : 3e45d8c67fe0e0b6229fb356fa91e67a3617d419    
  
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   : 3b5007347b5db0fa34cb54773be89e22f5d68b61    
  
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   : cfcdae5513210e6bdaf2a5469350354790e4f27b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:25:39 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:25:39 -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   : 0f8a2b133644b3cf17a54c10153ba7941d0d8936    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:24:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:24:57 -0500    

Backpatch commit 7bc9a8bdd2d to 13-17. The motivation for backpatching is that  
we want to update CI to Debian Trixie. Trixie contains a newer mingw  
installation, which would trigger the warning addressed by 7bc9a8bdd2d. The  
risk of backpatching seems fairly low, given that it did not cause issues in  
the branches the commit is already present.  
  
While CI is not present in 13-14, it seems better to be consistent across  
branches.  
  
Author: Thomas Munro <tmunro@postgresql.org>  
Discussion: https://postgr.es/m/o5yadhhmyjo53svzwvaocww6zkrp63i4f32cw3treuh46pxtza@hyqio5b2tkt6  
Backpatch-through: 13  

commit   : e1e79791af1cac78159901b39aef449f1096cfeb    
  
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   : 0b44f2443f699b54d8036ac64a048dd6f59adb3a    
  
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   : f4b68b0336bd3ff91f2ee131519b1efe1cb6fc39    
  
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   : 1e6dfdaa04399a531789660864648919be071686    
  
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   : e7340b484c349455f77b498c9d2d2cbaa781ae09    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:35 +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   : 27f714b5dad7c06fce8efc03a3d6a2495dc93118    
  
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   : 436d9ed690ebad81df2f98d702e2578def002699    
  
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   : 14044eb25866113147ae82631f1e9259e5317cae    
  
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   : 3f0b994cf3a68b74f63cd6f9bde954cc0ae70ceb    
  
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   : d6e6abc9c1aeec5faa540745360f7a08028484aa    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 16:08:50 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 16:08:50 -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   : 3f059dd3977c25ab87310f39e9209d6ec49f6819    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 13:07:03 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 30 Oct 2025 13:07:03 -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   : f3fb6bc9feec39a174c584164577d26b70bfe699    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Oct 2025 13:13:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Oct 2025 13:13:34 +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   : bd6f986c9e0ed654bd517af3507a0eba723a0913    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:49:42 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:49:42 +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   : 0024f5a1022e61c6f9d5377515cc1cdee28c5939    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 27 Oct 2025 06:34:29 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 27 Oct 2025 06:34:29 +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   : 0d307461538082880151c804e037ab3bd85936e7    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 26 Oct 2025 11:01:53 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 26 Oct 2025 11:01:53 +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   : 256698d26746644e2f688bf3495bd6c55a7d58be    
  
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   : 39d24475c18059a2fe1de1d05352fd5eed6092b3    
  
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   : fbc41a145ae00166b8cdd22c236566e76864732c    
  
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   : 8ceab82ca5264f5896463782fb1103a64ef577fa    
  
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   : 9310be78ae668f697b6b2e2107b44a56c31e09da    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 22 Oct 2025 17:17:43 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 22 Oct 2025 17:17:43 -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   : 10945148eec689cc114fe872d623c3c7c4f546e6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:12:49 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:12:49 +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   : 4eb6992af1954cd81f4a8b503e8c45bae2a9c1fe    
  
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   : 5c659da980e11cd2a9f7b98d0434ee2e25214cc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Oct 2025 11:13:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Oct 2025 11:13:00 -0400    

Per buildfarm.  The breakage was discussed and deemed acceptable  
in the patch thread, but it was not mentioned in the commit log,  
so I missed spotting this one yesterday.  
  
Discussion: https://postgr.es/m/787065.1761144050@sss.pgh.pa.us  
Backpatch-through: 17 only  

commit   : 1db2870bb5abcfbd05e74195814706b737372472    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 20:11:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 20:11:47 +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   : 62d5ee75bbc44c76ca3c6930fc104a96be0f1aa7    
  
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   : a91f2d822522d03164f73fe925012d18abb43217    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 16:37:29 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 21 Oct 2025 16:37:29 -0500    

This file was previously added to v18 by commits a72f7d97be and  
93fb76ca4e.  Unlike the v18 version of the file, the back-branch  
versions set the original baseline point to the most recent ABI  
break documented in the git commit history.  While we'd ordinarily  
set it to something just before the .0 release, we're unlikely to  
act upon ABI breaks in released minor versions, so it doesn't seem  
worth the trouble to construct a comprehensive history.  
  
Discussion: https://postgr.es/m/aPfDOD6F4FaJJd7M%40nathan  
Backpatch-through: 13-17  

commit   : e9514a2f73162578fd53d391dd6eff4359c82b61    
  
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   : c0897125171035e4d4b9fc8cf8a099131ac45281    
  
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   : c4f5a59ab16b6b0f799e0d63783826f684eb3f2c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:47:10 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:47:10 +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   : 199a0ecbcff770f2c99bb4e46d4aff44003c3f98    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 08:08:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 08:08:35 +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   : 2fa8f94db1c36ad3774f7e16fe8381ceeb9c4081    
  
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   : 2efca163399ba1be4c2991635960ed509f6e7cfd    
  
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   : d4e8c37cca39362b4281ce254f92ff2fe5a4b4b0    
  
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   : c945b06d5f03e30cec279df516688c70787b2b2c    
  
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   : 7419c99a25fb0f6138062eddddbbc15d61e57437    
  
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   : a0551bc5734b16029bdbed3e7222fa6a1eb1625c    
  
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   : f01c4eb4e901522859367ddfef69098224b36321    
  
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   : 61b5fa029a432e6c5f516c633b5467d4cc55f264    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Oct 2025 13:06:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Oct 2025 13:06:11 +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   : a8933194e51585ed896c5c2b4a8e2ec5e3667a67    
  
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   : 2bb84ea7ef89961ab3c02c4496a44b6335fc79e9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 15 Oct 2025 17:15:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 15 Oct 2025 17:15:02 +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   : a7346770813e31c3fd38616ebcc1beb61d551eea    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Oct 2025 08:31:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Oct 2025 08:31:25 +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   : 4c53519e15da6c055a9b63107ceb9fe6f6fb68b9    
  
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   : f428b1231ccf39eded9db86acb72c87ad8aa0a8f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:25:57 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:25:57 +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   : bf18e9bd70decd294a9be517cb5b3a260ccfdd15    
  
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   : eac2b1697d48b2ee5e6836fb63ae0966363055c2    
  
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   : ea06f97eeb335ca8dd70be5f8c11a32ec4f3eb12    
  
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   : f9993ac646b9db202a2aa3d18444e0971b63e21f    
  
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   : ae15cebc2035b77626e7d55757324b429c5e1f38    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:21 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:21 -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   : ede2f6b893219296d953177de11df4f43a593e81    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 11:51:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 11:51:51 +0900    

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

commit   : 42348839d8b788987361e76639d6d2a0b5e19a33    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:50 +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   : a61592253e57b7e7034e9a6158f709343280bb43    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 9 Oct 2025 10:59:31 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 9 Oct 2025 10:59:31 -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   : 09f86a42f25cd32d8d268484252671341033b2c0    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 9 Oct 2025 01:07:36 -0400    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 9 Oct 2025 01:07:36 -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   : 1c4671f7b7c378cc26d1953785a3aa249152958b    
  
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   : 3549ffb6afaf045d715be6ca42814f0a08ad2af9    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 3 Oct 2025 16:06:03 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 3 Oct 2025 16:06:03 +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   : de6de069d9c6b432a5dfd98b0784ed7f60a793ce    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:01 +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   : 036decbba2af60dfed4afe564689a0475ef844ab    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:12 +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   : c3357759080c3f8b02c87b3d5c09411feb6e26d0    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 1 Oct 2025 09:25:21 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 1 Oct 2025 09:25:21 -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   : a912118c6055f683d51763546ee3c14b6e732893    
  
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   : 6778fbca63c9efffefee8086914cef8428c4ccad    
  
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   : 3fc9aa5b0233883e0f73902200777d251e848e18    
  
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   : f39d9164b70a8ead8e1b6847f067532b784bbf0e    
  
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   : b4ef835f5e7d66c9a72f8e6c011cf68ed4907f0b    
  
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   : 53a2246ddf9b1e641654dd0654ff8f24e952920a    
  
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   : 2e84996b03f55e4f5230658cb28077cf10d36ef1    
  
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   : 2f6e1a49066f512813c0ad0b4a77e0fd04a3a508    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Sep 2025 03:49:02 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Sep 2025 03:49:02 +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   : 0072fb3076cdd45cdd1c2b0f2335b9c7dea511ad    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 22 Sep 2025 10:12:31 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 22 Sep 2025 10:12:31 +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   : b948c575a6d1270387c044111da0ed2ab99eb1f4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 08:03:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 08:03:28 +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  

commit   : dc8aa2f586d039d53198c895c3de762a98e59016    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 18 Sep 2025 11:09:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 18 Sep 2025 11:09:15 +0900    

Previously, pg_restore did not skip security labels on publications or  
subscriptions even when --no-publications or --no-subscriptions was specified.  
As a result, it could issue SECURITY LABEL commands for objects that were  
never created, causing those commands to fail.  
  
This commit fixes the issue by ensuring that security labels on publications  
and subscriptions are also skipped when the corresponding options are used.  
  
Backpatch to all supported versions.  
  
Author: Jian He <jian.universality@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 13  

commit   : e830896c16ee9ea2ba4eaa8a49b6bb3079505003    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Sep 2025 16:32:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Sep 2025 16:32:57 -0400    

If an aggregate function call contains a sub-select that has  
an RTE referencing a CTE outside the aggregate, we must treat  
that reference like a Var referencing the CTE's query level  
for purposes of determining the aggregate's level.  Otherwise  
we might reach the nonsensical conclusion that the aggregate  
should be evaluated at some query level higher than the CTE,  
ending in a planner error or a broken plan tree that causes  
executor failures.  
  
Bug: #19055  
Reported-by: BugForge <dllggyx@outlook.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19055-6970cfa8556a394d@postgresql.org  
Backpatch-through: 13  

commit   : 0fb06e8933312e67398af9728a8eb98cafe9e742    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 12:20:19 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 12:20:19 +1200    

The EvalPlanQual recheck for TID Range Scan wasn't rechecking the TID qual  
still passed after following update chains.  This could result in tuples  
being updated or deleted by plans using TID Range Scans where the ctid of  
the new (updated) tuple no longer matches the clause of the scan.  This  
isn't desired behavior, and isn't consistent with what would happen if the  
chosen plan had used an Index or Seq Scan, and that could lead to hard to  
predict behavior for scans that contain TID quals and other quals as the  
planner has freedom to choose TID Range or some other non-TID scan method  
for such queries, and the chosen plan could change at any moment.  
  
Here we fix this by properly implementing the recheck function for TID  
Range Scans.  
  
Backpatch to 14, where TID Range Scans were added  
  
Reported-by: Sophie Alpert <pg@sophiebits.com>  
Author: Sophie Alpert <pg@sophiebits.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/4a6268ff-3340-453a-9bf5-c98d51a6f729@app.fastmail.com  
Backpatch-through: 14  

commit   : 3d939a9b1c72ac34df69aa7540f212b9a79aadc5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:49:49 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:49:49 +1200    

The EvalPlanQual recheck for TID Scan wasn't rechecking the TID qual  
still passed after following update chains.  This could result in tuples  
being updated or deleted by plans using TID Scans where the ctid of the  
new (updated) tuple no longer matches the clause of the scan.  This isn't  
desired behavior, and isn't consistent with what would happen if the  
chosen plan had used an Index or Seq Scan, and that could lead to hard to  
predict behavior for scans that contain TID quals and other quals as the  
planner has freedom to choose TID or some other scan method for such  
queries, and the chosen plan could change at any moment.  
  
Here we fix this by properly implementing the recheck function for TID  
Scans.  
  
Backpatch to 13, oldest supported version  
  
Reported-by: Sophie Alpert <pg@sophiebits.com>  
Author: Sophie Alpert <pg@sophiebits.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/4a6268ff-3340-453a-9bf5-c98d51a6f729@app.fastmail.com  
Backpatch-through: 13  

commit   : 047306a3fe269e16f4cd4af5dcb4328d184743cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 14:36:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 14:36:51 -0400    

Cover contrib/pgcrypto, per buildfarm.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/443709.1757876535@sss.pgh.pa.us  
Backpatch-through: 17  

commit   : e127764b65da609c0b983e8c46f3b989855d8efb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 16 Sep 2025 09:40:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 16 Sep 2025 09:40:44 -0700    

The COMMENT should depend on the separately-dumped constraint, not the  
domain.  Sufficient restore parallelism might fail the COMMENT command  
by issuing it before the constraint exists.  Back-patch to v13, like  
commit 0858f0f96ebb891c8960994f023ed5a17b758a38.  
  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/20250913020233.fa.nmisch@google.com  
Backpatch-through: 13  

commit   : a865b654c7735008092511d7c170b48b8bfa6419    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 10:09:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 10:09:49 -0400    

In our previous discussions around making our regression tests  
pass in FIPS mode, we concluded that we didn't need to support  
the different error message wording observed with pre-3.0 OpenSSL.  
However there are still a few LTS distributions soldiering along  
with such versions, and now we have some in the buildfarm.  
So let's add the variant expected-files needed to make them happy.  
  
This commit only covers the core regression tests.  Previous  
discussion suggested that we might need some adjustments in  
contrib as well, but it's not totally clear to me what those  
would be.  Rather than work it out from first principles,  
I'll wait to see what the buildfarm shows.  
  
Back-patch to v17 which is the oldest branch that claims  
to support this case.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/443709.1757876535@sss.pgh.pa.us  
Backpatch-through: 17  

commit   : d719e2ecb1886d8eae15bb46384751db783719a8    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 16 Sep 2025 18:42:20 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 16 Sep 2025 18:42:20 +0900    

JsonConstructorExpr can produce non-NULL output with a NULL input, so  
it should be treated as a non-strict construct.  Failing to do so can  
lead to incorrect query behavior.  
  
For example, in the reported case, when pulling up a subquery that is  
under an outer join, if the subquery's target list contains a  
JsonConstructorExpr that uses subquery variables and it is mistakenly  
treated as strict, it will be pulled up without being wrapped in a  
PlaceHolderVar.  As a result, the expression will be evaluated at the  
wrong place and will not be forced to null when the outer join should  
do so.  
  
Back-patch to v16 where JsonConstructorExpr was introduced.  
  
Bug: #19046  
Reported-by: Runyuan He <runyuan@berkeley.edu>  
Author: Tender Wang <tndrwang@gmail.com>  
Co-authored-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/19046-765b6602b0a8cfdf@postgresql.org  
Backpatch-through: 16  

commit   : 968141898777a484e6250b912b89289bd47e1340    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 16:44:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 16:44:58 +0900    

Previously, pg_dump incorrectly queried pg_seclabel to retrieve security labels  
for subscriptions, which are stored in pg_shseclabel as they are global objects.  
This could result in security labels for subscriptions not being dumped.  
  
This commit fixes the issue by updating pg_dump to query the pg_seclabels view,  
which aggregates entries from both pg_seclabel and pg_shseclabel.  
While querying pg_shseclabel directly for subscriptions was an alternative,  
using pg_seclabels is simpler and sufficient.  
  
In addition, pg_dump is updated to dump security labels on event triggers,  
which were previously omitted.  
  
Backpatch to all supported versions.  
  
Author: Jian He <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 13  

commit   : f7f9c5d6581602d7bc264572753b6b95dc2173a8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 10:36:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 10:36:54 +0900    

Previously, pg_restore did not skip comments on publications or subscriptions  
even when --no-publications or --no-subscriptions was specified. As a result,  
it could issue COMMENT commands for objects that were never created,  
causing those commands to fail.  
  
This commit fixes the issue by ensuring that comments on publications and  
subscriptions are also skipped when the corresponding options are used.  
  
Backpatch to all supported versions.  
  
Author: Jian He <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 13  

commit   : f9b41f3e1ecd0bd8aab673bc49f4222f683b9c24    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 11:38:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 11:38:58 +0200    

The previous change (commit f225473cbae) was still not on target,  
because it talked about relation kinds, which are not what is being  
checked here.  Provide a more accurate message.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACJufxEZ48toGH0Em_6vdsT57Y3L8pLF=DZCQ_gCii6=C3MeXw@mail.gmail.com  

commit   : 755f01ad743c09a5fcaf04df1c0e465bb48b85ed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 08:13:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 08:13:21 +0200    

LLVM-21 renamed llvm::GlobalValue::getGUID() to  
getGUIDAssumingExternalLinkage(), so add a version guard.  
  
Author: Holger Hoffstätte <holger@applied-asynchrony.com>  
Discussion: https://www.postgresql.org/message-id/flat/d25e6e4a-d1b4-84d3-2f8a-6c45b975f53d%40applied-asynchrony.com  

commit   : e09adb5b9fc9dec27c7ff9e9592723d7d8098b03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Sep 2025 16:55:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Sep 2025 16:55:51 -0400    

Commit e3ffc3e91 fixed the translation of character classes in  
SIMILAR TO regular expressions.  Unfortunately the fix broke a corner  
case: if there is an escape character right after the opening bracket  
(for example in "[\q]"), a closing bracket right after the escape  
sequence would not be seen as closing the character class.  
  
There were two more oversights: a backslash or a nested opening bracket  
right at the beginning of a character class should remove the special  
meaning from any following caret or closing bracket.  
  
This bug suggests that this code needs to be more readable, so also  
rename the variables "charclass_depth" and "charclass_start" to  
something more meaningful, rewrite an "if" cascade to be more  
consistent, and improve the commentary.  
  
Reported-by: Dominique Devienne <ddevienne@gmail.com>  
Reported-by: Stephan Springl <springl-psql@bfw-online.de>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFCRh-8NwJd0jq6P=R3qhHyqU7hw0BTor3W0SvUcii24et+zAw@mail.gmail.com  
Backpatch-through: 13  

commit   : a220e40d11063cf2e43bdfb5e1ca872fe201f37d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Sep 2025 17:43:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Sep 2025 17:43:15 -0400    

Commit a0b99fc12 caused pg_event_trigger_dropped_objects()  
to not fill the object_name field for schemas, which it  
should have; and caused it to fill the object_name field  
for default values, which it should not have.  
  
In addition, triggers and RLS policies really should behave  
the same way as we're making column defaults do; that is,  
they should have is_temporary = true if they belong to a  
temporary table.  
  
Fix those things, and upgrade event_trigger.sql's woefully  
inadequate test coverage of these secondary output columns.  
  
As before, back-patch only to v15.  
  
Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/bd7b4651-1c26-4d30-832b-f942fabcb145@postgrespro.ru  
Backpatch-through: 15  

commit   : a399db8d5988902da3f7bf55b78fd3511020fc66    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 Sep 2025 07:27:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 Sep 2025 07:27:48 +0200    

Clang 21 shows some new compiler warnings, for example:  
  
warning: variable 'dstsize' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer]  
  
The fix is to initialize the variables when they are defined.  This is  
similar to, for example, the existing situation in gistKeyIsEQ().  
  
Discussion: https://www.postgresql.org/message-id/flat/6604ad6e-5934-43ac-8590-15113d6ae4b1%40eisentraut.org  

commit   : c0c8ee23c8967053d99d5799fe5812d259ebbea1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Sep 2025 17:11:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Sep 2025 17:11:54 -0400    

pg_event_trigger_dropped_objects() would report a column default  
object with is_temporary = false, even if it belongs to a  
temporary table.  This seems clearly wrong, so adjust it to  
report the table's temp-ness.  
  
While here, refactor EventTriggerSQLDropAddObject to make its  
handling of namespace objects less messy and avoid duplication  
of the schema-lookup code.  And add some explicit test coverage  
of dropped-object reports for dependencies of temp tables.  
  
Back-patch to v15.  The bug exists further back, but the  
GetAttrDefaultColumnAddress function this patch depends on does not,  
and it doesn't seem worth adjusting it to cope with the older code.  
  
Author: Antoine Violin <violin.antuan@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFjUV9x3-hv0gihf+CtUc-1it0hh7Skp9iYFhMS7FJjtAeAptA@mail.gmail.com  
Backpatch-through: 15  

commit   : 591aeb5068ae580fec423bd142641585d12d9537    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Sep 2025 11:55:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Sep 2025 11:55:29 +0200    

The Sun Studio compiler complains about an empty declaration here.  
  
Note for future historians:  This does not mean that this compiler is  
still of current interest for anyone using PostgreSQL.  But we can let  
this small fix be its parting gift.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/a0f817ee-fb86-483a-8a14-b6f7f5991b6e%40eisentraut.org  

commit   : fe73a0e6c1c6d39300c30ee2877bfde069a13597    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:26 +0900    

hash_xlog.h included descriptions for the blocks used in WAL records  
that were was not completely consistent with how the records are  
generated, with one block missing for SQUEEZE_PAGE, and inconsistent  
descriptions used for block 0 in VACUUM_ONE_PAGE and MOVE_PAGE_CONTENTS.  
  
This information was incorrect since c11453ce0aea, cross-checking the  
logic for the record generation.  
  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CALdSSPj1j=a1d1hVA3oabRFz0hSU3KKrYtZPijw4UPUM7LY9zw@mail.gmail.com  
Backpatch-through: 13  

commit   : f918916cdbedb6f6b032ad5de091d894ddcc95f0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 10:15:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 10:15:39 +0900    

GucSource_Names was documented as being in guc.c, but since 0a20ff54f5e6  
it is located in guc_tables.c.  The reference to the location of  
GucSource_Names is important, as GucSource needs to be kept in sync with  
GucSource_Names.  
  
Author: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CAKFQuwYPgAHWPYjPzK7iXzhSZ6MKR8w20_Nz7ZXpOvx=kZbs7A@mail.gmail.com  
Backpatch-through: 16  

commit   : 862980f924ff19fbaa6aba39809f1a89fc215027    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Sep 2025 16:05:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Sep 2025 16:05:03 -0400    

If the hash functions used for hashing tuples leaked any memory,  
we failed to clean that up, resulting in query-lifespan memory  
leakage in queries using hashed subplans.  One way that could  
happen is if the values being hashed require de-toasting, since  
most of our hash functions don't trouble to clean up de-toasted  
inputs.  
  
Prior to commit bf6c614a2, this leakage was largely masked  
because TupleHashTableMatch would reset hashtable->tempcxt  
(via execTuplesMatch).  But it doesn't do that anymore, and  
that's not really the right place for this anyway: doing it  
there could reset the tempcxt many times per hash lookup,  
or not at all.  Instead put reset calls into ExecHashSubPlan  
and buildSubPlanHash.  Along the way to that, rearrange  
ExecHashSubPlan so that there's just one place to call  
MemoryContextReset instead of several.  
  
This amounts to accepting the de-facto API spec that the caller  
of the TupleHashTable routines is responsible for resetting the  
tempcxt adequately often.  Although the other callers seem to  
get this right, it was not documented anywhere, so add a comment  
about it.  
  
Bug: #19040  
Reported-by: Haiyang Li <mohen.lhy@alibaba-inc.com>  
Author: Haiyang Li <mohen.lhy@alibaba-inc.com>  
Reviewed-by: Fei Changhong <feichanghong@qq.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19040-c9b6073ef814f48c@postgresql.org  
Backpatch-through: 13  

commit   : 15f9eeef624fee62b0bd1840c0aa6f491b2548ac    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 10 Sep 2025 11:21:12 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 10 Sep 2025 11:21:12 -0500    

autoconf builds have compiled this file with -ftree-vectorize since  
commit 8870917623, but meson builds seem to have missed the memo.  
  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/aL85CeasM51-0D1h%40nathan  
Backpatch-through: 16  

commit   : e25453a3631f9da1f01c119e5841e9869c287da7    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 9 Sep 2025 16:04:04 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 9 Sep 2025 16:04:04 -0700    

Use -funroll-loops and -ftree-vectorize when building checksum.c to  
match what autoconf does.  
  
Missed backport of 9af672bcb2, noticed by Nathan Bossart.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/a81f2f7ef34afc24a89c613671ea017e3651329c.camel@j-davis.com  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Backpatch-through: 16  

commit   : e2dd7b2acf27336d47f78d68f4aac03f7770a6a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Sep 2025 07:23:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Sep 2025 07:23:24 +0900    

The startup process does not process shared invalidation messages, only  
sending them, and never calls AtEOXact_SMgr() which clean up any  
unpinned SMgrRelations.  Hence, it is never able to free SMgrRelations  
on a periodic basis, bloating its hashtable over time.  
  
Like the checkpointer and the bgwriter, this commit takes a conservative  
approach by freeing periodically SMgrRelations when replaying a  
checkpoint record, either online or shutdown, so as the startup process  
has a way to perform a periodic cleanup.  
  
Issue caused by 21d9c3ee4ef7, so backpatch down to v17.  
  
Author: Jingtang Zhang <mrdrivingduck@gmail.com>  
Reviewed-by: Yuhang Qiu <iamqyh@gmail.com>  
Discussion: https://postgr.es/m/28C687D4-F335-417E-B06C-6612A0BD5A10@gmail.com  
Backpatch-through: 17  

commit   : 778f391c26c6c569b3078daff1ac8e218024e46c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 9 Sep 2025 14:35:30 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 9 Sep 2025 14:35:30 -0500    

This section claims that each backend executes the  
shmem_startup_hook shortly after attaching to shared memory, which  
is true for EXEC_BACKEND builds, but not for others.  This commit  
adds this important detail.  
  
Oversight in commit 964152c476.  
  
Reported-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0vEGT1eigGbVt604LkXP6mUPMwPMxQoRCbFny44w%2B9EUQ%40mail.gmail.com  
Backpatch-through: 17  

commit   : 3e6dfcfb0529a9d003e07a56f58d0ff3c46556bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 15:52:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 15:52:51 +0900    

A new pgstats entry is created as a two-step process:  
- The entry is looked at in the shared hashtable of pgstats, and is  
inserted if not found.  
- When not found and inserted, its fields are then initialized.  This  
part include a DSA chunk allocation for the stats data of the new entry.  
  
As currently coded, if the DSA chunk allocation fails due to an  
out-of-memory failure, an ERROR is generated, leaving in the pgstats  
shared hashtable an inconsistent entry due to the first step, as the  
entry has already been inserted in the hashtable.  These broken entries  
can then be found by other backends, crashing them.  
  
There are only two callers of pgstat_init_entry(), when loading the  
pgstats file at startup and when creating a new pgstats entry.  This  
commit changes pgstat_init_entry() so as we use dsa_allocate_extended()  
with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure  
instead of failing.  This way, a backend failing an entry creation can  
take appropriate cleanup actions in the shared hashtable before throwing  
an error.  Currently, this means removing the entry from the shared  
hashtable before throwing the error for the allocation failure.  
  
Out-of-memory errors unlikely happen in the wild, and we do not bother  
with back-patches when these are fixed, usually.  However, the problem  
dealt with here is a degree worse as it breaks the shared memory state  
of pgstats, impacting other processes that may look at an inconsistent  
entry that a different process has failed to create.  
  
Author: Mikhail Kot <mikhail.kot@databricks.com>  
Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com  
Backpatch-through: 15  

commit   : 1819ff4ed67780629268d47adaf3068ba167783a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 10:07:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 10:07:20 +0900    

The README was missing parse_jsontable.c which handles JSON_TABLE.  
Oversight in de3600452b61.  
  
Author: Karthik S <karthikselvaam@gmail.com>  
Discussion: https://postgr.es/m/CAK4gQD9gdcj+vq_FZGp=Rv-W+41v8_C7cmCUmDeu=cfrOdfXEw@mail.gmail.com  
Backpatch-through: 17  

commit   : 6195afbe536afd7b25aa78001d7510ed111f0404    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 5 Sep 2025 08:22:38 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 5 Sep 2025 08:22:38 +0100    

When executing a MERGE UPDATE action, if there is more than one  
concurrent update of the target row, the lock-and-retry code would  
sometimes incorrectly identify the latest version of the target tuple,  
leading to incorrect results.  
  
This was caused by using the ctid field from the TM_FailureData  
returned by table_tuple_lock() in a case where the result was TM_Ok,  
which is unsafe because the TM_FailureData struct is not guaranteed to  
be fully populated in that case. Instead, it should use the tupleid  
passed to (and updated by) table_tuple_lock().  
  
To reduce the chances of similar errors in the future, improve the  
commentary for table_tuple_lock() and TM_FailureData to make it  
clearer that table_tuple_lock() updates the tid passed to it, and most  
fields of TM_FailureData should not be relied on in non-failure cases.  
An exception to this is the "traversed" field, which is set in both  
success and failure cases.  
  
Reported-by: Dmitry <dsy.075@yandex.ru>  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/1570d30e-2b95-4239-b9c3-f7bf2f2f8556@yandex.ru  
Backpatch-through: 15  

commit   : fd3b972d78f60292b7aed8ea06f941a49d0b7144    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Sep 2025 14:10:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Sep 2025 14:10:26 +0900    

SlruRecentlyUsed() is an inline function since 53c2a97a9266, not a  
macro.  The description of long_segment_names was missing at the top of  
SimpleLruInit(), part forgotten in 4ed8f0913bfd.  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/aLpBLMOYwEQkaleF@jrouhaud  
Backpatch-through: 17  

commit   : 57dfb64ecf436888cfc25a828ce6bddb7ad15a78    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 16:01:18 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 16:01:18 +0100    

Per buildfarm member wrasse, void function cannot return a value.  
This only affects v13-v17, where an ABI-compatible wrapper function  
was added.  
  
Backpatch-through: 13-17  

commit   : 76f45be9315bb02b6f9f41b17e5a448c6241bb20    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:48:02 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:48:02 +0100    

When executing a MERGE, check that the target relation supports all  
actions mentioned in the MERGE command. Specifically, check that it  
has a REPLICA IDENTITY if it publishes updates or deletes and the  
MERGE command contains update or delete actions. Failing to do this  
can silently break replication.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Tested-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/OS3PR01MB57180C87E43A679A730482DF94B62@OS3PR01MB5718.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : 0b934d3994ffdd4b9d557a216a381cca4d6e6f11    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:33:00 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:33:00 +0100    

If an INSERT has an ON CONFLICT DO UPDATE clause, the executor must  
check that the target relation supports UPDATE as well as INSERT. In  
particular, it must check that the target relation has a REPLICA  
IDENTITY if it publishes updates. Formerly, it was not doing this  
check, which could lead to silently breaking replication.  
  
Fix by adding such a check to CheckValidResultRel(), which requires  
adding a new onConflictAction argument. In back-branches, preserve ABI  
compatibility by introducing a wrapper function with the original  
signature.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Tested-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/OS3PR01MB57180C87E43A679A730482DF94B62@OS3PR01MB5718.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : f34202f51867534fbbb6196fc9e77be25e5e5b23    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Sep 2025 16:00:38 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Sep 2025 16:00:38 +0900    

SubPlan nodes are typically built very early, before any RelOptInfos  
have been constructed for the parent query level.  As a result, the  
simple_rel_array in the parent root has not yet been initialized.  
Currently, during cost estimation of a SubPlan's testexpr, we may call  
examine_variable() to look up statistical data about the expressions.  
This can lead to "no relation entry for relid" errors.  
  
To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since  
the root does not yet contain enough information to safely consult  
statistics.  
  
One exception is SubPlan nodes built for the initplans of MIN/MAX  
aggregates from indexes.  In this case, having a NULL root is safe  
because testexpr will be NULL.  Additionally, an initplan will by  
definition not consult anything from the parent plan.  
  
Backpatch to all supported branches.  Although the reported call path  
that triggers this error is not reachable prior to v17, there's no  
guarantee that other code paths -- especially in extensions -- could  
not encounter the same issue when cost_qual_eval() is called with a  
root that lacks a valid simple_rel_array.  The test case is not  
included in pre-v17 branches though.  
  
Bug: #19037  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
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/19037-3d1c7bb553c7ce84@postgresql.org  
Backpatch-through: 13  

commit   : 0fedb3a27d24c5dd977c5eca3b009c8f4ec09f33    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 12:54:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 12:54:29 +0900    

PQtrace() was generating its output for non-printable characters without  
casting the characters printed with unsigned char, leading to some extra  
"\xffffff" generated in the output due to the fact that char may be  
signed.  
  
Oversights introduced by commit 198b3716dba6, so backpatch down to v14.  
  
Author: Ran Benita <ran@unusedvar.com>  
Discussion: https://postgr.es/m/a3383211-4539-459b-9d51-95c736ef08e0@app.fastmail.com  
Backpatch-through: 14  

commit   : 24ee8678f3c78dd100d1083e0936a200186c0cf9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 10:20:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 10:20:37 +0900    

SLRU bank locks are referred as "bank locks" or "SLRU bank locks" in the  
code comments.  The comments updated in this commit use the latter term.  
  
Oversight in 53c2a97a9266, that has replaced the single ControlLock by  
the bank control locks.  
  
Author: Julien Rouhaud <julien.rouhaud@free.fr>  
Discussion: https://postgr.es/m/aLUT2UO8RjJOzZNq@jrouhaud  
Backpatch-through: 17  

commit   : 92268b35d04c2de416279f187d12f264afa22614    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 Aug 2025 19:28:46 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 Aug 2025 19:28:46 +0200    

Compression in pg_dump is abstracted using an API with multiple  
implementations which can be selected at runtime by the user.  
The API and its implementations have evolved over time, notable  
commits include bf9aa490db, e9960732a9, 84adc8e20, and 0da243fed.  
The errorhandling defined by the API was however problematic and  
the implementations had a few bugs and/or were not following the  
API specification.  This commit modifies the API to ensure that  
callers can perform errorhandling efficiently and fixes all the  
implementations such that they all implement the API in the same  
way.  A full list of the changes can be seen below.  
  
 * write_func:  
   - Make write_func throw an error on all error conditions.  All  
     callers of write_func were already checking for success and  
     calling pg_fatal on all errors, so we might as well make the  
     API support that case directly with simpler errorhandling as  
     a result.  
  
 * open_func:  
   - zstd: move stream initialization from the open function to  
     the read and write functions as they can have fatal errors.  
     Also ensure to dup the file descriptor like none and gzip.  
   - lz4: Ensure to dup the file descriptor like none and gzip.  
  
 * close_func:  
   - zstd: Ensure to close the file descriptor even if closing  
     down the compressor fails, and clean up state allocation on  
     fclose failures.  Make sure to capture errors set by fclose.  
   - lz4: Ensure to close the file descriptor even if closing  
     down the compressor fails, and instead of calling pg_fatal  
     log the failures using pg_log_error. Make sure to capture  
     errors set by fclose.  
   - none: Make sure to catch errors set by fclose.  
  
 * read_func / gets_func:  
   - Make read_func unconditionally return the number of read  
     bytes instead of making it optional per implementation.  
   - lz4: Make sure to call throw an error and not return -1  
   - gzip: gzread returning zero cannot be assumed to indicate  
     EOF as it is documented to return zero for some types of  
     errors.  
   - lz4, zstd: Convert the _read_internal helper functions to  
     not call pg_fatal on errors to be able to handle gets_func  
     returning NULL on error.  
  
 * getc_func:  
   - zstd: Use an unsigned char rather than an int to read char  
     into.  
  
 * LZ4Stream_init:  
   - Make sure to not switch to inited state until we know that  
     initialization succeeded and reset errno just in case.  
  
On top of these changes there are minor comment cleanups and  
improvements as well as an attempt to consistently reset errno  
in codepaths where it is inspected.  
  
This work was initiated by a report of API misuse, which turned  
into a larger body of work.  As this is an internal API these  
changes can be backpatched into all affected branches.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Evgeniy Gorbanev <gorbanyoves@basealt.ru>  
Discussion: https://postgr.es/m/517794.1750082166@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : ed394c4bdf1247fb7e9a6525f7588f49887c33a1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 30 Aug 2025 00:52:22 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 30 Aug 2025 00:52:22 +1200    

It's possible that if the only live partition is concurrently dropped  
and try_table_open() fails, that the bms_del_member() will pfree the  
live_parts Bitmapset.  Since the bms_del_member() call does not assign  
the result back to the live_parts local variable, the while loop could  
segfault as that variable would still reference the pfree'd Bitmapset.  
  
Backpatch to 15. 52f3de874 was backpatched to 14, but there's no  
bms_del_member() there due to live_parts not yet existing in RelOptInfo in  
that version.  Technically there's no bug in version 15 as  
bms_del_member() didn't pfree when the set became empty prior to  
00b41463c (from v16).  Applied to v15 anyway to keep the code similar and  
to avoid the bad coding pattern.  
  
Author: Bernd Reiß <bd_reiss@gmx.at>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/6b88f27a-c45c-4826-8e37-d61a04d90182@gmx.at  
Backpatch-through: 15  

commit   : e9fb314c7ad89a25eade3c3ed918abab4c532fe2    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 Aug 2025 14:43:47 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 Aug 2025 14:43:47 +0200    

I think the error message for a different condition was inadvertently  
copied.  
  
This problem seems to have been introduced by commit a4d75c86bf15.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CACJufxEZ48toGH0Em_6vdsT57Y3L8pLF=DZCQ_gCii6=C3MeXw@mail.gmail.com  

commit   : 00064302cbf2736d8eaf27ac068328981c6b0212    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 28 Aug 2025 17:06:47 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 28 Aug 2025 17:06:47 -0700    

Previously, we used LW_EXCLUSIVE in several places despite only reading  
WalSummarizerCtl fields. This patch reduces the lock level to LW_SHARED  
where we are only reading the shared fields.  
  
Backpatch to 17, where wal summarization was introduced.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoDdKhf_9oriEYxY-JCdF+Oe_muhca3pcdkMEdBMzyHyKw@mail.gmail.com  
Backpatch-through: 17  

commit   : 456c6a05d9900816c94f28b750eda3f13a1049fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 12:08:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 12:08:57 -0400    

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,  
which cannot select matching index entries but can reject  
non-matching tuples, for example a tsquery such as '!term'.  There are  
poorly-documented assumptions that such scan keys do not appear as the  
first scan key.  ginNewScanKey did nothing to ensure that, however,  
with the result that certain GIN index searches could go into an  
infinite loop while apparently-equivalent queries with the clauses in  
a different order were fine.  
  
Fix by teaching ginNewScanKey to place all excludeOnly scan keys  
after all not-excludeOnly ones.  So far as we know at present,  
it might be sufficient to avoid the case where the very first  
scan key is excludeOnly; but I'm not very convinced that there  
aren't other dependencies on the ordering.  
  
Bug: #19031  
Reported-by: Tim Wood <washwithcare@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org  
Backpatch-through: 13  

commit   : d17abaea8eda7e628d91550b0c059596c3d8b6e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 11:38:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 11:38:41 -0400    

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be  
inadequate to prevent a long uninterruptible loop, because  
we now know a case where looping occurs within scanGetItem.  
While the next patch will fix the bug that caused that, it  
seems foolish to assume that no similar patterns are possible.  
Let's do the CFI within scanGetItem's retry loop, instead.  
This demonstrably allows canceling out of the loop exhibited  
in bug #19031.  
  
Bug: #19031  
Reported-by: Tim Wood <washwithcare@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org  
Backpatch-through: 13  

commit   : 49a09c6c51c0d642e87086bbc7eb748c200d3f43    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Aug 2025 16:46:20 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Aug 2025 16:46:20 -0700    

v17 introduced the MAINTAIN ON TABLES privilege.  That changed the  
applicable "baseacls" reaching buildACLCommands().  That yielded  
spurious TestUpgradeXversion diffs.  Change to use a TYPES privilege.  
Types have the same one privilege in all supported versions, so they  
avoid the problem.  Per buildfarm.  Back-patch to v13, like that commit.  
  
Discussion: https://postgr.es/m/20250823144505.88.nmisch@google.com  
Backpatch-through: 13  

commit   : e8d22095e5df4d22513ce553998eef899f5f0692    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 22 Aug 2025 20:50:28 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 22 Aug 2025 20:50:28 -0700    

Commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6 missed DO_DEFAULT_ACL,  
leading to assertion failures, potential dump order instability, and  
spurious schema diffs.  Back-patch to v13, like that commit.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Discussion: https://postgr.es/m/d32aaa8d-df7c-4f94-bcb3-4c85f02bea21@gmail.com  
Backpatch-through: 13  

commit   : 7b434f96462f309098603b01bbc4b319312252c4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 22 Aug 2025 05:15:10 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 22 Aug 2025 05:15:10 +0000    

Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/OSCPR01MB149662EC5467B4135398E3731F532A@OSCPR01MB14966.jpnprd01.prod.outlook.com  

commit   : dcdc95cb4d4ccf3cd798235387e4b789169babad    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:36 +0900    

Temporary relations may share the same RelFileNumber with a permanent  
relation, or other temporary relations associated with other sessions.  
  
Being able to uniquely identify a temporary relation would require  
RelidByRelfilenumber() to know about the proc number of the temporary  
relation it wants to identify, something it is not designed for since  
its introduction in f01d1ae3a104.  
  
There are currently three callers of RelidByRelfilenumber():  
- autoprewarm.  
- Logical decoding, reorder buffer.  
- pg_filenode_relation(), that attempts to find a relation OID based on  
a tablespace OID and a RelFileNumber.  
  
This makes the situation problematic particularly for the first two  
cases, leading to the possibility of random ERRORs due to  
inconsistencies that temporary relations can create in the cache  
maintained by RelidByRelfilenumber().  The third case should be less of  
an issue, as I suspect that there are few direct callers of  
pg_filenode_relation().  
  
The window where the ERRORs are happen is very narrow, requiring an OID  
wraparound to create a lookup conflict in RelidByRelfilenumber() with a  
temporary table reusing the same OID as another relation already cached.  
The problem is easier to reach in workloads with a high OID consumption  
rate, especially with a higher number of temporary relations created.  
  
We could get pg_filenode_relation() and RelidByRelfilenumber() to work  
with temporary relations if provided the means to identify them with an  
optional proc number given in input, but the years have also shown that  
we do not have a use case for it, yet.  Note that this could not be  
backpatched if pg_filenode_relation() needs changes.  It is simpler to  
ignore temporary relations.  
  
Reported-by: Shenhao Wang <wangsh.fnst@fujitsu.com>  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-By: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Reviewed-By: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-By: Takamichi Osumi <osumi.takamichi@fujitsu.com>  
Reviewed-By: Michael Paquier <michael@paquier.xyz>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Reported-By: Shenhao Wang <wangsh.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/bbaaf9f9-ebb2-645f-54bb-34d6efc7ac42@fujitsu.com  
Backpatch-through: 13  

commit   : dc8efd61d929153d185cdf9e842fe7d708b2e761    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:52 +0900    

The description of this GUC provides a list of the situations where  
full-page writes are generated.  However, it is not completely exact,  
mentioning only the cases where full_page_writes=on or base backups.  It  
is possible to generate full-page writes in more situations than these  
two, making the description confusing as it implies that no other cases  
exist.  
  
The description is slightly reworded to take into account that other  
cases are possible, without mentioning them directly to minimize the  
maintenance burden should FPWs be generated in more contexts in the  
future.  
  
Author: Jingtang Zhang <mrdrivingduck@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CAPsk3_CtAYa_fy4p6=x7qtoutrdKvg1kGk46D5fsE=sMt2546g@mail.gmail.com  
Backpatch-through: 13  

commit   : 07a302387176e2107aa09c598091a8eb73a7d70f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:10 +0900    

Some replication slot manipulations (logical decoding via SQL,  
advancing) were failing an assertion when releasing a slot in  
single-user mode, because active_pid was not set in a ReplicationSlot  
when its slot is acquired.  
  
ReplicationSlotAcquire() has some logic to be able to work with the  
single-user mode.  This commit sets ReplicationSlot->active_pid to  
MyProcPid, to let the slot-related logic fall-through, considering the  
single process as the one holding the slot.  
  
Some TAP tests are added for various replication slot functions with the  
single-user mode, while on it, for slot creation, drop, advancing, copy  
and logical decoding with multiple slot types (temporary, physical vs  
logical).  These tests are skipped on Windows, as direct calls of  
postgres --single would fail on permission failures.  There is no  
platform-specific behavior that needs to be checked, so living with this  
restriction should be fine.  The CI is OK with that, now let's see what  
the buildfarm tells.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: Mutaamba Maasha <maasha@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966ED588A0328DAEBE8CB25F5FA2@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : b6090ed96b60374560251c6f3ec65309c9ce4b96    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:37 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:37 -0700    

This commit adds CHECK_FOR_INTERRUPTS to loops iterating over shared  
buffers in several pg_buffercache functions, allowing them to be  
interrupted during long-running operations.  
  
Backpatch to all supported versions. Add CHECK_FOR_INTERRUPTS to the  
loop in pg_buffercache_pages() in all supported branches, and to  
pg_buffercache_summary() and pg_buffercache_usage_counts() in version  
16 and newer.  
  
Author: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>  
Discussion: https://postgr.es/m/CAHg+QDcejeLx7WunFT3DX6XKh1KshvGKa8F5au8xVhqVvvQPRw@mail.gmail.com  
Backpatch-through: 13  

commit   : 288a817bcb04c896c8e3489d106285995489358d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 05:06:37 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 05:06:37 +0000    

The DROP SUBSCRIPTION command performs several operations: it stops the  
subscription workers, removes subscription-related entries from system  
catalogs, and deletes the replication slot on the publisher server.  
Previously, this command acquired an AccessExclusiveLock on  
pg_subscription before initiating these steps.  
  
However, while holding this lock, the command attempts to connect to the  
publisher to remove the replication slot. In cases where the connection is  
made to a newly created database on the same server as subscriber, the  
cache-building process during connection tries to acquire an  
AccessShareLock on pg_subscription, resulting in a self-deadlock.  
  
To resolve this issue, we reduce the lock level on pg_subscription during  
DROP SUBSCRIPTION from AccessExclusiveLock to RowExclusiveLock. Earlier,  
the higher lock level was used to prevent the launcher from starting a new  
worker during the drop operation, as a restarted worker could become  
orphaned.  
  
Now, instead of relying on a strict lock, we acquire an AccessShareLock on  
the specific subscription being dropped and re-validate its existence  
after acquiring the lock. If the subscription is no longer valid, the  
worker exits gracefully. This approach avoids the deadlock while still  
ensuring that orphan workers are not created.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/18988-7312c868be2d467f@postgresql.org  

commit   : 71ee96e9f95806f9f6e2c805496c0dcf25b3946a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Aug 2025 14:54:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Aug 2025 14:54:59 -0400    

Apparently the only Test::More function this script uses is  
BAIL_OUT, so this omission just results in the wrong error  
output appearing in the cases where it bails out.  
  
Seems to have been an oversight in commit 9f899562d which  
split Kerberos.pm out of another script.  
  
Author: Maxim Orlov <orlovmg@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACG=ezY1Dp-S94b78nN0ZuaBGGcMUB6_nF-VyYUwPt1ArFqmGA@mail.gmail.com  
Backpatch-through: 17  

commit   : 61c37630774002fb36a5fa17f57caa3a9c2165d9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 17 Aug 2025 19:40:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 17 Aug 2025 19:40:02 +0900    

Commit c5b7ba4e6 changed things so that the ri_RootResultRelInfo field  
of this struct is set for both partitions and inheritance children and  
used for tuple routing and transition capture (before that commit, it  
was only set for partitions to route tuples into), but failed to update  
these comments.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK14NF5CcdCmTZpxrvpvBiT0y4EqKikW1r_wAu1CEHeOmUA%40mail.gmail.com  
Backpatch-through: 14  

commit   : 2b79e12095351470370d422e291bbb3c929db2c8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 15 Aug 2025 10:29:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 15 Aug 2025 10:29:16 +0200    

Recent changes to src/tools/ci/README triggered warnings like  
  
    src/tools/ci/README:88: leftover conflict marker  
  
Raise conflict-marker-size in .gitattributes to avoid these.  

commit   : 04b384b3efb2de1a9c3a218d9350ff5cef3850c1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 18:06:35 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 18:06:35 +1200    

This seems to have been broken back in be0a66666.  
  
Reported-by: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966E11EEFB37D7857FCEDB7F535A@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : efe705b05cc1a9151e105b66208aa19003dc772f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 17:24:45 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 17:24:45 +1200    

This seems to have been broken for a few years by cc5ef90ed.  
  
Author: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/OSCPR01MB14966E11EEFB37D7857FCEDB7F535A@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 17  

commit   : 73f107b54ec6ecd865acd2ce0befb52f7bb883da    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:48:04 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:48:04 -0400    

Handle 'ci-os-only' occurrences in the .cirrus.star file instead of  
.cirrus.tasks.yml file. Now, 'ci-os-only' occurrences are controlled  
from one central place instead of dealing with them in each task.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/20240413021221.hg53rvqlvldqh57i%40awork3.anarazel.de  
Backpatch: 15-, where CI support was added  

commit   : 3d478f66b651375851c8fa04239a6558861565ec    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:33:47 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:33:47 -0400