PostgreSQL 13.23 commit log

commit   : 89df812eb890814b105d871185935b580478e660    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 16:59:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2025 16:59:18 -0500    

commit   : 9a219bb0038a7c56eb4ea9680e1d0c7043a81c88    
  
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   : 8a2530ebcdef1aafa08ad1d019aec298dcebb952    
  
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   : d6f0c0d6d6d3f14177848e4a00df988fa2f0a09a    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:06 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:06 -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   : 498ff7761c93a27703ca42d5bacc254e3d4a0931    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 13:07:38 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 13:07:38 +0100    

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

commit   : 2d89905b59e2dd28fd215fa9f33915c182a82bc9    
  
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   : 77b5b2c6f47cce79c64d7f5772e24e671bb507ad    
  
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   : 2dfda09ad77b1873f51a565041090af37743e576    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:58:53 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 7 Nov 2025 14:58:53 +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   : 20bafb0972882eaf0fb50349fc4023e1e5505a57    
  
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   : 3717849e622d6d38be8f021cf230903d70926d5a    
  
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   : 324051fb890b927a5f85aa899d800f0162952d69    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:05 +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   : e7b0c814dcfb2d93f02b25fa51a327cfdfa534ad    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:15:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:15:05 +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   : 2adf3032841b2257ecd7ec5b1b9301004e4ca538    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:31 +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   : 7609b342c3bf74f93522061962a58add42185790    
  
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   : ef81697fee774d3e21e0c479f3f9515a7d0f256f    
  
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   : d7aeb03d2418f3c01b125218f62af41ffad1aacf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:24:59 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:24:59 -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   : 9c742c3943c404e59f42e6de6247a5678d901340    
  
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   : 7f239c72a897f7e0f884f92ea2f92efde92c60f8    
  
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   : 3c7b47974ec7332a2bb98cf51888dd4a4f367506    
  
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   : 25b484080f14bf2a3ab3dcaa5b9304cfbc921f97    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:44 +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   : 438ccd33a37a9c3bf77fbe5424c1c0a1acb769e4    
  
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   : 78d542b2bc0a71370fae2334e8c5ace443dbd36e    
  
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   : 6b4b8d5f359b24ccfa16093ed7051d5034fd1344    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 30 Oct 2025 19:11:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 30 Oct 2025 19:11:52 -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   : 7b955c2279f4b485f328a95bf60a3cdf048b6e2d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:51:08 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:51:08 +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   : d91620406ae964f75878f0554b6c36afc9dfd8eb    
  
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   : dc0a208ac2e9435418a0660e5b42c52fd72284bb    
  
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   : d90c92d1c16dbd01026bbd3bca5d9e7b24dae0e1    
  
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   : b4810b4bb8859107a76a6caba48ae3d776ee03ec    
  
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   : 4afab175bc13a08277ad40400a11db4e16905547    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:14:33 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:14:33 +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   : b00a16baeb2ab8551ae752e86263e1c0bfc52d9c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 20:13:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Oct 2025 20:13:15 +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   : 7d7ebdb800fe99ba8fd9b0a1012458856c0d1f3d    
  
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   : 7d47278933f461cbd46f702c99aec7c87db75a77    
  
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   : bcc6e13570c714a5dc14f8fcfbd5c33300a320d1    
  
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   : 3f1ef7dcc2cb25c9c6d0c54d35713298ebe6fcbc    
  
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   : c28f8ca294457ac915b224ec381cbac103f4cba6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:49:00 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:49:00 +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   : 33276cd0272efd72e098840a5f3d3c6b795214c1    
  
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   : d20df9590aef652627b847421e874e77fef215d3    
  
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   : 19a64f5676bb51a3c01891c4bdb184ae48944936    
  
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   : f768f5a7d408c7a5efe45d49136818f7d4d0a62a    
  
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   : 12b0c0e51b2fed1f36816a0ea53a4f8e44455ec1    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 15 Oct 2025 17:15:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 15 Oct 2025 17:15:05 +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   : 75a555d61b3b407c904f41c6a5cb922675f237e2    
  
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   : c3b9e565137b187cd9b271fff366075020df6b1d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:27:38 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:27:38 +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   : af302ff6b84ab136533e98b69f645fc271338915    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:12 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:12 -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   : c878d98084208551e6c44ede046c4d7a5be9dc56    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:59 +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   : fc287cf3c4c98cef16297e89e5946a7c66ffa33e    
  
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   : f1a2f3a0c4ea51d9904fd30c9c11cb474312353b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:08 +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   : c207bf473ee93d2521921295d814acb56bc71822    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:19 +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   : 7d7e81d1e6b8cff9b8e6047609df2b8fbf8d76f3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Sep 2025 23:55:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Sep 2025 23:55:33 +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   : afb2cce743d4455f9ef88373cffcdadaf0600352    
  
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   : a4dbb11bb9acf9b97994ef278a368744aee01147    
  
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   : b649ef2446a46a800bc031787de1e03cf64fe3d7    
  
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   : 940f3cd5df57df41bb3d71f7f91fe0c713699e4d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:51:21 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:51:21 +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   : a685c057ad4cacfb5648903adcb940edeffdefc4    
  
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   : dff7591a7041b4ccbb42806c6492a29d86fece86    
  
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   : 8fbd1f8ea2e14a1ac1d16a7d90d301833c76e273    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 10:38:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 10:38:40 +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   : 59d6e843e9a8cbdb982121871c3af6db0eb87d68    
  
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   : 308773617d2dc8c717a695498c052722c5558660    
  
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   : ff6819c0dbd81912e216e2605bd2f7f038afb502    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:35 +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   : 8b6c29afd1254481a63e08e89bcefcde1c8d5418    
  
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   : dbef9cbaa4e9f07e2db254c0d8f65ddbc0135b37    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 15:55:59 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 15:55:59 +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   : 0610b843c9718dafba54590da38fed0cda52cd6d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:37:46 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:37:46 +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   : 8c02d92c6475c2488f6e64b9096d812713692f82    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Sep 2025 16:09:23 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Sep 2025 16:09:23 +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   : 3e0f5f00b34b5bb08e98511bdb89dd31150abdef    
  
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   : b2d71c455f05d9d7f959789fcebdc035189defde    
  
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   : fb75e1ef72123476209a4cd5b511f1b9e3c240f2    
  
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   : 05341b2e9914d8c5690ba38c081c0af450c7d3e9    
  
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   : 30b32b08c9e980b7ee1d8e690203127ead8b95a4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:42 +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   : 3f134ce7001b8d526b0bb0b8362a24d0966bb732    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:58 +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   : 8ed079cad8241ae8ba6bf8ffd1212d0ca487cb19    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:17 +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   : 7d8d36289f6a688c52004be16d657316c82ffb14    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:25 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:25 -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   : 0a98f24a65cdf8520b6b36154f8b425e85b78854    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 04:17:03 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 04:17:03 +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   : e3b3fa863810f62f7a9c23b2d21a392d75cc4422    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Aug 2025 11:59:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Aug 2025 11:59:47 -0400    

It turns out that on some platforms (at least current macOS, NetBSD,  
OpenBSD) semget(2) will return EINVAL if there is a pre-existing  
semaphore set with the same key and too few semaphores.  Our code  
expects EEXIST in that case and treats EINVAL as a hard failure,  
resulting in failure during initdb or postmaster start.  
  
POSIX does document EINVAL for too-few-semaphores-in-set, and is  
silent on its priority relative to EEXIST, so this behavior arguably  
conforms to spec.  Nonetheless it's quite problematic because EINVAL  
is also documented to mean that nsems is greater than the system's  
limit on the number of semaphores per set (SEMMSL).  If that is  
where the problem lies, retrying would just become an infinite loop.  
  
To resolve this contradiction, retry after EINVAL, but also install a  
loop limit that will make us give up regardless of the specific errno  
after trying 1000 different keys.  (1000 is a pretty arbitrary number,  
but it seems like it should be sufficient.)  I like this better than  
the previous infinite-looping behavior, since it will also keep us out  
of trouble if (say) we get EACCES due to a system-level permissions  
problem rather than anything to do with a specific semaphore set.  
  
This problem has only been observed in the field in PG 17, which uses  
a higher nsems value than other branches (cf. 38da05346, 810a8b1c8).  
That makes it possible to get the failure if a new v17 postmaster  
has a key collision with an existing postmaster of another branch.  
In principle though, we might see such a collision against a semaphore  
set created by some other application, in which case all branches are  
vulnerable on these platforms.  Hence, backpatch.  
  
Reported-by: Gavin Panella <gavinpanella@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CALL7chmzY3eXHA7zHnODUVGZLSvK3wYCSP0RmcDFHJY8f28Q3g@mail.gmail.com  
Backpatch-through: 13