PostgreSQL 14.20 commit log

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

commit   : ee953cd8f0a9325ad67fef94539df8b4201efafe    
  
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   : 95cce56696867c7629d12c3ba1da8edd5bedaa8e    
  
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   : 96d2c7e96e8bb6563b0b6e0d8d02162ed67ff12e    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:05 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 10 Nov 2025 06:03:05 -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   : e792be6f43bcb2ea5a7a3ca4dd2139a925cbb491    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 13:06:35 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Nov 2025 13:06:35 +0100    

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

commit   : 06827c5fc882448dcca04b0a1a7ce0aaf2b9c3ba    
  
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   : d8ba910b09c0573ac795a15ff5ec75f3b3692d5f    
  
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   : 9326cf9ce997ce99fb518bab1c38608e5536a5a3    
  
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   : d2965f627fe35bfc9c212528159d95f46b8e83ef    
  
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   : ccfe28eb42370c1ce7b62c03fc4f2081ab6ba25d    
  
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   : b8b37f0ee2a38154199bdc3b61df89ac9b8ae1e8    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 6 Nov 2025 12:25:04 +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   : 66ea95f3c5386a72a8b3fd08c48cfc470a038ee3    
  
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   : beba3c2b916272a286f4f3831281c41af654c65a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Nov 2025 16:48:29 +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   : 0418716e1c694fdc84a26f2551e764ee83e21520    
  
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   : 65b0d1f74098d845f088d53b8922884a05db2f9c    
  
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   : 371d40c1a3ff8e29f6d38120eb67997b8d83f636    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:24:58 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Nov 2025 13:24:58 -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   : 2c56b7069519126b64cf0e55747133c3df3079ad    
  
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   : 04345d7a423ab60016824e672da578941841b7d1    
  
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   : f0ad417161977d034e3d5845d043c44bef3d1f8a    
  
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   : a1b8b3b2e38595efc67165cf748947a64910af0e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Nov 2025 10:52:42 +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   : faba2595d6194b1a805ee31b5ab0dc574e1ba311    
  
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   : d26997c71281def407df25e1fc7606f30a084681    
  
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   : 4c0b7bdd5e9d02e1a8fcdb6a8f269ab9daa14d89    
  
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   : 86bd9497f87ddcddc1533903cfdd624d7a3d61f1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:50:46 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 30 Oct 2025 14:50:46 +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   : d4542415c38ead3c356abbfd476be63b9101ffc0    
  
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   : 7b542cdbcdcc8676c38ebac940d81fa808081681    
  
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   : 7fb8c924042ea918ab95cfe757d60f8953b6c61c    
  
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   : 10799d025f2cce491be3a5a94cd91604bfc617e1    
  
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   : c4a6444a65ac305869450aae2c712043f0fbefde    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 22 Oct 2025 17:17:36 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 22 Oct 2025 17:17:36 -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   : e4316ec4dd0cc9ef777185a59556249656f5a0ed    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:14:08 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 23 Oct 2025 13:14:08 +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   : f106f53df6f58cb3559b3e8b825a048f04863c52    
  
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   : a7ab6ce6a0fccf016e74794a896508ba2546cce8    
  
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   : 58ba7e5ebfdff6ecfd760bb5b5aecb7b06d48237    
  
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   : 0a358eb45ed4ab44397bcf6aad20bae9be28c057    
  
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   : e95010a9c0bad33cca21d762dd1151167993fd37    
  
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   : eea24eb0ac2f7fa0f3eb9611483653beb976b41e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:48:34 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 21 Oct 2025 20:48:34 +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   : 5274f11c17493a4011156a99e44cb1a8f5f9692e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 08:08:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Oct 2025 08:08:42 +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   : 40dc710a61aa5112b98cdd3d4caca51bd148ffb0    
  
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   : 6062c3db3093d92d6240b88c6818d0e7aaa73341    
  
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   : f146eb45cb1ae3e6fb0e1684e33ebaba21c8726d    
  
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   : 56cd332f80b260ebc1eef825d4b5acd6d6a54310    
  
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   : 24e74b9621e4e40a36ac03ee5e9f059787fefb5c    
  
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   : e91eb4ad66c96cca014c5ba111239e29c051b0ea    
  
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   : 715eb62e30ac54963be63f625a1d8d50fa7d29b7    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:27:11 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Oct 2025 09:27:11 +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   : b753be38a4a239b7cd4d2c289d8737c955c46f6f    
  
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   : 314004021e549770d3d57fd0cf286050b948472d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:14 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Oct 2025 14:52:14 -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   : f57f2760e6651bb51bf99189e25a29ab4507860d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Oct 2025 09:24:57 +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   : f46d77377b9a0be25524a6339296c8a892059f2c    
  
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   : 9b3beb7c6f12597830c68ffa36abe1c23f366454    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Oct 2025 14:04:06 +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   : ee2dbcad02c71ce73681ed4fb67a55cca1f86898    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Oct 2025 11:09:17 +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   : cb21e1f92fb3b9c2208611db8c7051660fc0afb2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Sep 2025 23:55:02 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Sep 2025 23:55:02 +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   : 5816baa9bcf3db6cb98e689dabe06276aa8fb3f2    
  
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   : 0be39b4b1a018aa6cea73b0aee4294fb6f57f58d    
  
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   : bc476f8b8b64c3f6f4e1c77f4baceda842fe88dc    
  
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   : 31bf0963208f1a5121a81aa7c17b4e55bfdc5596    
  
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   : f78a69034740687669c72f15382a113ee4c482db    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 12:21:29 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 12:21:29 +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   : 2eb7ea97d8af4f4a8c65ff9f95fcbe4e4ab8e7a8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:50:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:50:58 +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   : 85d6ed31fc7cd61fb5717a29044f3b3d5f61222d    
  
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   : 295c0a644af5c32e5310c5523cac0ccec64115e5    
  
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   : db900ec358bd0ffa59b60a906f2ddc5305bc6b8b    
  
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   : cbd3732cbbaa0fa083a12ca2d9df18ff606736da    
  
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   : fbfc36e9471b22998acfe6d31ecf1721ca2b62cb    
  
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   : f75ff1b141a5ceccfc6292af5e94238c360f89e9    
  
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   : 5e131489fe99025dafa7ec425a7130fbad1d8015    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:32 +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   : 5eab9b0a473ed83851d01b16acde77e9d93fc3d4    
  
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   : ea65c882384c36f184bd8a1e8046f93ec0b7576d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 15:57:18 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 15:57: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   : 5fd569ef2d621d3a36d69b6ceb669866014db39d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:36:25 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:36:25 +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   : 160ef51c8dbab47b04c5aa65b6909e7be5ec5af6    
  
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   : 0cc540f0d03f280625ea9cda4d43bd79b5f8321d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 12:54:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 12:54:34 +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   : b830f9d67463f770e7c92ac989112c90c1f28dbf    
  
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   : 4a593043eee9b399ff6c1fc40862f820289786c1    
  
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   : a7da746c11777780f01475c6123bc1efeaefe508    
  
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   : 22c6a44f01fd751c2ed229be4003f7c26d671933    
  
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   : 4948bb9df4210e30492caf3fa4e982bac376fd0b    
  
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   : 222130edd81f4202719090508360b56994a8512b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:40 +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   : 24145bbb9e6c651b56ae61ed8625a4c484035d18    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:56 +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   : 32d388d00f9f8c0873ad02ec4be2d88caaa3a359    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:16 +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   : 79643105a29dbe7e11ccf328c6ac62ce3f5cb076    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:29 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:29 -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   : ef77502746fed4cca0ea8ab45c95f56ef55a95e5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 04:28:19 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 04:28:19 +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   : 59bab34160285a9f38beb8c986d3f9adcfe78baa    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 17 Aug 2025 19:40:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 17 Aug 2025 19:40:04 +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   : 2c7c08a090f2a37d2bec6109813d246b43343bcf    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 18:07:44 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 18:07:44 +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   : b3d6e8b63bc1a4c6a846b49b60a9b8264c132677    
  
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