PostgreSQL 19.0 (upcoming) commit log

commit   : 1a562a2661b30e72f37bdf8500fac01c347114ac    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 14 Sep 2026 14:13:30 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 14 Sep 2026 14:13:30 +0300    

The command tag is WAIT, but the reference page called the command  
"WAIT FOR" in its title, index entry, psql help name and throughout its  
prose, and so did the error messages.  FOR is a noise word that makes the  
grammar read like English, exactly as INTO does for INSERT and FROM does  
for DELETE; neither of those is part of the command's name.  Settle on  
WAIT everywhere the command is named, and keep WAIT FOR LSN wherever the  
syntax itself is being shown.  
  
Rename the reference page's id and file name to match, following  
cb2c696b1dd: v19 is not released, so the URL is not yet baked into a  
supported version, and every other page's id matches its title.  
  
Reported-by: Masahiko Sawada sawada.mshk@gmail.com  
Author: Xuneng Zhou xunengzhou@gmail.com  
Reviewed-by: Alexander Korotkov aekorotkov@gmail.com  
Discussion: https://postgr.es/m/CAD21AoBdtiPTbm7T_aNeDON9JpFG9g%3DJDUP4WU-Y8t8_xqvR5Q%40mail.gmail.com  
Backpatch-through: 19  

commit   : f260c03bccb709b61a0ddfdcc214134402150c0f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 14 Sep 2026 14:13:04 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 14 Sep 2026 14:13:04 +0300    

Commit 447aae13b03 accepted TIMEOUT values up to INT64_MAX  
milliseconds, but computing the deadline multiplies by 1000, which  
caused an int64 overflow. And the command reported a timeout at once  
instead of waiting.  
  
Parse the value as an int instead, which simplifies the code and is  
consistent with other timeout values such as the statement_timeout GUC.  
  
The specified values are now rounded to the nearest millisecond, so a  
positive timeout below half a millisecond becomes zero and waits  
indefinitely.  
  
Backpatch to v19, where the TIMEOUT option was introduced.  
  
Reported-by: ChangAo Chen <cca5507@qq.com>  
Author: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/tencent_86B83240785807077600A1778566B5C12908@qq.com  
Backpatch-through: 19  

commit   : 3e44c8a441f34117b3e6369fadfcbc94c7ae537d    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 14 Sep 2026 19:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 14 Sep 2026 19:00:01 +0900    

To import attribute statistics, postgres_fdw sent a query wity COLLATE  
"C" to remote servers without checking their version.  Since COLLATE is  
only supported since v9.1, this could break the import against older  
servers; fix by modifying postgres_fdw to check their version and if  
older, fall back to sampling.  (This commit still allows importing only  
relation statistics from such an older server.)  
  
Also, expand the documentation to mention that attribute statistics are  
stored into the local server without applying the foreign table columns'  
n_distinct option.  
  
Oversight in commit 28972b6fc.  
  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
Reported-by: Osama Abdul Qader <osamaabdulqader.cs@gmail.com>  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwH8%2BuDTwfohpck9v_9L3nwSWACbmC36JYRyqHd5xQN_OA%40mail.gmail.com  
Backpatch-through: 19  

commit   : 9e9dc104badf49c1f2e536ca3468e0f64f9a44a5    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 14 Sep 2026 17:04:13 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 14 Sep 2026 17:04:13 +0900    

contain_context_dependent_node_walker() reports a CaseTestExpr as  
context-dependent unless it sits under a simple CaseExpr or the  
elemexpr of an ArrayCoerceExpr.  A JsonConstructorExpr whose RETURNING  
type requires a coercion also carries a CaseTestExpr placeholder in  
that coercion, so any SQL function called with such a constructor as  
an argument was refused inlining.  
  
Teach the walker that a CaseTestExpr is expected within the coercion  
of a JsonConstructorExpr, the same way it already handles the elemexpr  
of an ArrayCoerceExpr.  This is safe now that eval_const_expressions  
no longer lets an enclosing simple CASE clobber that placeholder.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs48A=VCFbteTkuCoknO1_0-Cu0aMBT0M07dm7vj1QyixDg@mail.gmail.com  
Backpatch-through: 19  

commit   : acd8d3e0f906b4a65d1f155a6ec62bfd623d7a5b    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 14 Sep 2026 17:03:41 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 14 Sep 2026 17:03:41 +0900    

A JSON constructor with a RETURNING clause uses a CaseTestExpr as the  
placeholder for its result in the coercion expression.  When such a  
constructor appears in a WHEN clause of a simple CASE whose test  
expression is a constant, eval_const_expressions substituted that  
constant for the placeholder, so the coercion produced the CASE's test  
value instead of the constructor's result.  For instance,  
  
    CASE 'x' WHEN JSON_OBJECT('a': 'b' RETURNING text) THEN 1 ELSE 0 END  
  
evaluated to 1.  
  
To fix, keep case_val out of scope while simplifying the coercion, as  
is already done for the elemexpr of an ArrayCoerceExpr.  
  
Back-patch to v16, where the SQL/JSON constructor functions were  
introduced.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs48A=VCFbteTkuCoknO1_0-Cu0aMBT0M07dm7vj1QyixDg@mail.gmail.com  
Backpatch-through: 16  

commit   : 17d84c2b67f38cc3fc8b868c668297d59a299d97    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Sep 2026 09:35:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Sep 2026 09:35:02 +0530    

Unlogged tables cannot be replicated, so they can neither be published nor  
be named in a publication's EXCEPT clause.  ALTER TABLE ... SET UNLOGGED  
checked only whether the table was published, so a table in an EXCEPT  
clause could still be made unlogged, leaving a state that CREATE  
PUBLICATION would reject and that pg_dump could not restore.  
  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/CALDaNm1r2MkGu6h8zgU1Kj1sX-FcMQ7wGTeLSnhx-5joiyXEvg@mail.gmail.com  
Backpatch-through: 19, where it was introduced  

commit   : 2d48d0f153dc86c71a1ab80c5252ab35bb1d84b7    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 14 Sep 2026 12:27:21 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 14 Sep 2026 12:27:21 +0900    

When a subquery references an output of another subquery that gets  
pulled up, and that output must be wrapped in a PlaceHolderVar because  
of an intermediate outer join, the PHV expression is pushed down into  
the subquery.  That copy is not preprocessed along with the outer  
query's expressions, so the two copies can diverge.  This used to be  
harmless, but since commit 2ebf25e7d join removal edits the whole  
query tree, walking into subqueries, and can trip an assert in  
ChangeVarNodes if it removes a rel whose Var survives only in such a  
copy.  
  
To fix, preprocess these copies at their owning query level, early in  
subquery_planner, before anything can consume them (in particular  
before SubLinks are turned into SubPlans).  This covers copies pushed  
into both LATERAL subquery RTEs and SubLink subselects, and handles  
nested copies innermost-first.  extract_lateral_references no longer  
preprocesses the copies it pulls out.  
  
Correspondingly, the subquery's own processing must leave the contents  
of an upper-level PHV alone, since the owning level has already  
preprocessed them: eval_const_expressions returns such a PHV  
unchanged, and flatten_join_alias_vars no longer recurses into it.  
  
Back-patch to v16, as with commit 2ebf25e7d.  
  
Reported-by: Tender Wang <tndrwang@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAHewXN=kWGAXV537mKtSyBYobGdHhYJVDJJMXXZEmmPWE_zaPw@mail.gmail.com  
Backpatch-through: 16  

commit   : 4664929e5a2a57477e87745b87c8e40e60d1bcd4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Sep 2026 11:29:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Sep 2026 11:29:09 +0900    

db169985c10f has missed once reference to ddlutils.c in adt's Makefile,  
making the build fail with ./configure.  Meson was fine.  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/aqdaP73B-CIrmSPV@paquier.xyz  
Backpatch-through: 19, only  

commit   : db169985c10f02fa6d97920b0fafdde0ade3fde8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Sep 2026 11:54:41 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Sep 2026 11:54:41 -0400    

List of commits reverted:  
  
  4881981f920  Add infrastructure for pg_get_*_ddl functions  
  76e514ebb4b  Add pg_get_role_ddl() function  
  b99fd9fd7f3  Add pg_get_tablespace_ddl() function  
  a4f774cf1c7  Add pg_get_database_ddl() function  
  6c7bce28c83  Fixups for a4f774cf1c7  
  1f108fc02ec  Fix pfree crash in pg_get_role_ddl() and pg_get_database_ddl().  
  cda0c4c5d6f  Reject invalid databases in pg_get_database_ddl()  
  79fba6ebaba  doc: Fix missing role attribute in pg_get_tablespace_ddl() description.  
  c529ee38b9e  Convert ddlutils regression tests to TAP tests.  
  df1bac400fb  Fix timezone dependence in test_misc/012_ddlutils.pl  
  5642a0367c2  Avoid SIGSEGV in pg_get_database_ddl() on NULL tablespace  
  2af70e93747  Fix incorrect declarations of variadic pg_get_*_ddl() functions.  
  d6ed87d1989  Use named boolean parameters for pg_get_*_ddl option arguments  
  
plus the corresponding release notes entries.  
  
Discussion: https://postgr.es/m/20260827015242.54.noahmisch@microsoft.com  

commit   : e14a2354d9f7e44b0ffcaeaf187aa475e3e7d11b    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 13 Sep 2026 14:06:00 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 13 Sep 2026 14:06:00 +0200    

Like VACUUM FULL, non-concurrent REPACK would try to rebuild such  
indexes, which can sometimes succeed.  Concurrent REPACK would however  
fail.  The inconsistency is not good, so make them both throw an error  
quickly to force the user to make a decision on those indexes (most  
likely, drop them).  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Suggested-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/CAN4CZFO5A3YE0Dd-bn7eKrB20pECO3=U0wKg1z2rO=DxgWJJHQ@mail.gmail.com  

commit   : 6bc236c8a5b198e7ffde80377777167f1d4b78bb    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 12 Sep 2026 23:30:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 12 Sep 2026 23:30:03 +0300    

WaitForLSN() samples the current position before checking whether  
recovery is still in progress. If recovery reaches the target and ends  
between those operations, the promotion path can compare against the  
stale sample and incorrectly return NOT_IN_RECOVERY.  
  
Read the position again after observing that recovery has ended, before  
deciding whether promotion reached the target.  
  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CABPTF7U0gW5%2B-4oL7-qdML-yerZxUb7ku4QXp7JxCYo0qyJ_Tw%40mail.gmail.com  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Backpatch-through: 19  

commit   : 854be98cc4aad48a960197e4d70b1da9063a906e    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 12 Sep 2026 23:29:46 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 12 Sep 2026 23:29:46 +0300    

XLogWrite() can advance the flush position when it finishes a WAL  
segment, even if its caller requested only a write. When this happens  
while AdvanceXLInsertBuffer() recycles a buffer, primary_flush waiters  
are not notified and can sleep until an unrelated flush or checkpoint.  
  
Track such progress with a process-local pending flag and perform the  
wakeup after releasing WAL write and insertion locks, keeping  
WaitLSNLock acquisition outside the contended WAL path. Add a  
deterministic injection-point test that forces this path and inspects  
the registration directly in shared memory.  
  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CABPTF7U0gW5%2B-4oL7-qdML-yerZxUb7ku4QXp7JxCYo0qyJ_Tw%40mail.gmail.com  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Backpatch-through: 19  

commit   : f7c0929170a370f8229e66f54ea7396441efaaf1    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 12 Sep 2026 23:29:30 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 12 Sep 2026 23:29:30 +0300    

A backend waiting for WAL replay can retain locks acquired by earlier  
statements.  If the startup process needs one of those locks, directly or  
through another backend, before reaching the target LSN, a deadlock can  
arise: startup waits for the backend to release the lock, while the backend  
waits for startup to advance replay.  The lock manager records the  
backend's held locks, but WAIT FOR LSN does not register its dependency on  
replay as a lock wait.  The deadlock detector therefore cannot see the  
complete cycle.  With unlimited standby conflict delays and no other  
timeout or cancellation, this deadlock can persist indefinitely.  
  
Write and flush waits are restricted as well.  Their positions are floored  
by the replay position, so without an active walreceiver the startup  
process can be their only source of progress.  If a held lock blocks  
replay, these waits can form the same cycle: the backend waits for replay  
to advance, while replay waits for the backend to release the lock.  
  
Streaming does advance them independently, but only while WAL keeps  
arriving.  If reception stops before the target is reached, a blocked  
startup process cannot restart the walreceiver.  It also cannot replay  
newer checkpoint records needed to advance restartpoints and recycle WAL,  
so continued reception can exhaust available space in pg_wal before the  
target is reached.  An active receiver at the start of the wait therefore  
does not guarantee that the wait can finish while replay remains blocked.  
  
Reject an unsatisfied standby_replay, standby_write, or standby_flush wait  
while recovery is active when the backend already holds a granted  
heavyweight lock.  This conservative restriction covers direct  
relation-lock cycles and indirect cycles involving advisory locks.  It  
also rejects some write and flush waits that an active receiver could  
satisfy.  Requests whose target is observed as already reached are exempt  
from this check, as are primary_flush requests and requests issued after  
recovery has ended.  Existing snapshot and recovery-state checks still  
apply.  
  
Report one of the held locks so the user can find it, using the same  
description the deadlock report uses.  
  
Add replay-mode tests for relation and advisory locks and for the  
already-reached case, and document the restriction along with the  
recommended usage pattern.  
  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CABPTF7U0gW5%2B-4oL7-qdML-yerZxUb7ku4QXp7JxCYo0qyJ_Tw%40mail.gmail.com  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Backpatch-through: 19  

commit   : b3609cd2db8d7fd13cc261b8b00d642cd31947cf    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Fri, 11 Sep 2026 20:37:53 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Fri, 11 Sep 2026 20:37:53 -0400    

b46e1e54d078 pinned the VM after acquiring a cleanup lock on the heap  
page when on-access pruning. This was not correct, as pinning the VM may  
require I/O. Pin the VM before acquiring the lock. This could mean  
occasional unneeded pinning when the buffer is under contention, but  
that should be rare.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAAKRu_aR6e2mNVo-DNHDUfBE5i0cbE4%3Du%3D_Qi9%2Bv573qiGtBig%40mail.gmail.com  
Backpatch-through: 19  

commit   : e31766933ad63f76277d706ecee9e65e0870c169    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Sep 2026 09:04:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Sep 2026 09:04:07 +0900    

pg_stat_get_backend_subxact()'s second attribute was written as  
"subxact_overflow" in the docs, but its name is "subxact_overflowed".  
Note that the attribute name is still wrong in the TupleDesc generated  
in the function; pg_proc agrees with "overflowed".  
  
Author: Shihao Zhong <zhong950419@gmail.com>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAGRkXqTBZ+zbVuDC8xGEB6Btj61hsui5H5nGqzFBDyOXc=4bjQ@mail.gmail.com  
Backpatch-through: 16  

commit   : a160883053c3712af14c3035c7a1d5462a836a89    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Sep 2026 15:18:40 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Sep 2026 15:18:40 -0500    

The in-tree getopt_long() moves each non-option to the end of argv,  
which might put it right where an option's argument lookup expects  
to find the argument.  For example, "vacuumdb postgres --jobs"  
takes "postgres" as the number of jobs instead of complaining that  
--jobs is missing its argument.  To fix, stop the argument lookups  
at the start of the moved non-options, which we already track to  
know when to stop scanning.  
  
Oversight in commit 411b720343.  
  
Author: Sehrope Sarkuni <sehrope@jackdb.com>  
Reviewed-by: solai v <solai.cdac@gmail.com>  
Discussion: https://postgr.es/m/CAH7T-arxDuVCSkorO%3Dk7%2BM-_JV0JFzMpN_EtKMyD2K0RDqZ2OA%40mail.gmail.com  
Backpatch-through: 17  

commit   : 7ed016a1de345ffac2d54979914c61617abae4ce    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 11 Sep 2026 10:54:25 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 11 Sep 2026 10:54:25 -0700    

REPACK (CONCURRENTLY) suppresses logical decoding of the changes it  
applies to the transient heap. For an update, suppression keeps the  
tuple data out of the WAL record, but the record itself is still  
written, and decoding turned it into a change carrying neither a new  
nor an old tuple. An output plugin that asks for the changes made by  
heap rewrites therefore outputs an UPDATE with no data at all,  
reported under the name of the table being repacked.  
  
Ignore such records, as decoding already does for inserts. Updates on  
catalog relations don't carry the new tuple either, so we ignore them  
too. For deletes, REPACK sets XLH_DELETE_NO_LOGICAL instead.  
  
Backpatch to v19, where REPACK (CONCURRENTLY) was introduced.  
  
Reported-by: Thom Brown <thom@linux.com>  
Reviewed-by: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAA-aLv7L_-dOuHXjLh0Di66dExdOb=uTOzR=jtrqCmV0Wxyd2Q@mail.gmail.com  
Backpatch-through: 19  

commit   : fbaeb88978f023e724bef1ce74fc46c65841401c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 11 Sep 2026 19:12:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 11 Sep 2026 19:12:43 +0200    

Several global variables are only used in Windows build.  This causes  
-Wunused-but-set-global warnings that the new clang 23 enables via  
-Wall.  
  
This commit marks these with an unused attribute to silence the  
warnings.  
  
(In the master branch, this is addressed differently, but for  
backpatching, this just silences the warnings without any behavior  
change.)  
  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org  

commit   : e8601cb3d48de06e642683e91ef21f528e2ab462    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 11 Sep 2026 17:43:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 11 Sep 2026 17:43:11 +0200    

The new clang 23 has a new warning about set-but-unused  
static (internal-linkage) global variables: -Wunused-but-set-global,  
which is activated in PostgreSQL builds via -Wall.  This triggers a  
few warnings in PostgreSQL code.  This commit removes several such  
variables that were either never used or whose last use was removed  
some time ago.  
  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org  

commit   : 741f9d741e6dd9bc9174e4f522fc65b87b8d5ee3    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 11 Sep 2026 10:20:46 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 11 Sep 2026 10:20:46 -0700    

Previously, heap_update() honored TABLE_UPDATE_NO_LOGICAL for the main  
tuple but passed a hardcoded 0 to the tuple toaster, so the tuples it  
wrote to the TOAST relation were logged for decoding anyway. That was  
harmless until commit 28d534e2ae0a gave updates the flag; the insert  
path has propagated its own ever since suppression was introduced for  
heap rewrites.  
  
REPACK (CONCURRENTLY), the only user of the flag, relies on it to keep  
the changes it applies to the transient heap out of the logical  
stream. Logical decoding therefore reassembled the TOAST value and  
then dereferenced a new tuple that the suppressed record doesn't  
carry, crashing the backend. This is reachable only if an output  
plugin asks for the changes made by heap rewrites. In core that is  
just test_decoding with include-rewrites.  
  
Fix this by passing HEAP_INSERT_NO_LOGICAL down to the tuple toaster  
when TABLE_UPDATE_NO_LOGICAL is set.  
  
Backpatch to v19, where REPACK (CONCURRENTLY) was introduced.  
  
Reported-by: Thom Brown <thom@linux.com>  
Author: Antonin Houska <ah@cybertec.at>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAA-aLv7L_-dOuHXjLh0Di66dExdOb=uTOzR=jtrqCmV0Wxyd2Q@mail.gmail.com  
Backpatch-through: 19  

commit   : 6351dadfcf962a0bfa430cdbba05482acc45876e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Sep 2026 11:51:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Sep 2026 11:51:14 -0400    

Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20260904180712.cc.noahmisch@microsoft.com  

commit   : e0fdc3f54b417daeca957eb95b5eb04a418cc3bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Sep 2026 11:38:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Sep 2026 11:38:16 -0400    

This reverts commit a9c350d9ee66745aadcf7c0c95a567752a762171.  
While that intentionally changed our semantics for CREATE SCHEMA  
subcommands, it's being argued that the functionality gain does  
not justify potentially-subtle compatibility breakage.  The most  
useful bit of functionality gain came from commit 404db8f9e  
("Execute foreign key constraints in CREATE SCHEMA at the end"),  
which we're keeping because it's required by SQL spec and doesn't  
seem to create a compatibility hazard by itself.  
  
This is not an exact revert, partly because we're keeping 404db8f9e,  
and partly because I kept the API changes that allowed passing down  
a ParseState (which allows providing an error cursor for many of the  
errors thrown in CREATE SCHEMA).  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20260904180712.cc.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : 3c5d28ba64e2b9a309076106cf0b66a013eaf180    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Sep 2026 11:32:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Sep 2026 11:32:16 -0400    

This reverts commit d516974840f4059d331ae6057ede3e4edd3c6747,  
along with parts of commit 049b742daad0965be4a846035408ae27ce1f9e14  
("psql: Tighten heuristics for BEGIN/END within CREATE SCHEMA").  
  
While there's nothing particularly wrong with d51697484 in itself,  
it depends on a9c350d9e ("Don't try to re-order the subcommands of  
CREATE SCHEMA"), and concerns have been raised that the compatibility  
impact of that outweighs the benefit of allowing more object types  
within CREATE SCHEMA.  
  
It's not possible to revert 049b742da verbatim, because the  
CVE-2026-6464 patches 3045a25ba ("Teach psql to skip in-line COPY  
... FROM STDIN data after a failure") and cf754f741 ("Save/restore  
more lexer state when skipping text due to \if") depend on  
infrastructure it added.  Instead, rip out just the bits specifically  
needed to parse CREATE FUNCTION within CREATE SCHEMA.  This results in  
lexer code that matches v18-and-earlier as modified by CVE-2026-6464.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20260904180712.cc.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : 434bde9ce6b0c71c051e47f03641d5ebd1c68a3b    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 11 Sep 2026 13:42:45 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 11 Sep 2026 13:42:45 +0200    

The replica identity determination was "flawed": it fell back to the  
primary key if the marked index was dropped, which is a defensible  
choice, but logical decoding has a differing opinion and fails to  
provide usable tuple identity data in this case.  "Fix" REPACK by  
refusing to use the primary key in that case.  
  
This is arguably broken behavior in RelationGetIndexList, but I'll  
refrain from changing that at this stage.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Author: Ewan Young <kdbase.hack@gmail.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/apCBRKCH8jwKiaSY@nathan  

commit   : 090b44557d45686403d2d98c32d1d3add4337361    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Sep 2026 15:19:17 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Sep 2026 15:19:17 +0530    

ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY leaves the partition  
marked as detach-pending if its wait is interrupted, and only DETACH  
PARTITION ... FINALIZE clears that mark. In that state pg_class still says  
relispartition while get_partition_ancestors() already reports nothing,  
which RelationBuildPublicationDesc() was not ready for. It took  
relispartition to mean that the ancestor list is not empty and asked for  
its last element, which is an assertion failure, or a NULL pointer  
dereference without assertions. CheckCmdReplicaIdentity() needs the  
descriptor for every UPDATE and DELETE of a publishable relation and  
builds it on first use, so no publication has to exist for this, and a  
plain UPDATE crashes the backend.  
  
Treat such a partition as a standalone table, as after the detach is  
finalized. It is then published by FOR ALL TABLES publications, but cannot  
be added to an EXCEPT clause until the detach completes, which is now  
reported with a hint to run DETACH PARTITION ... FINALIZE.  
  
Oversight in fd366065e06a, which added the exclusion.  
  
Author: Mikhail Nikalayeu <mihailnikalayeu@gmail.com>  
Author: shveta malik <shveta.malik@gmail.com>  
Author: Nisha Moond <nisha.moond412@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Discussion: https://postgr.es/m/CADzfLwWoFPT%2Ba73%3DA%3DbsNWRMZQ98NpBEMgE%3Dt1FS4O4_%3DQVLfA%40mail.gmail.com  
Backpatch-through: 19, where it was introduced  

commit   : 043bc68b224e25578b1cc7e8ee7d54e0d03c762e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Sep 2026 18:14:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Sep 2026 18:14:14 +0900    

The tab-completion query used for ALTER DATABASE ... RESET referenced  
pg_db_role_setting and pg_database without schema qualification, so a  
same-named relation earlier in search_path could be used instead of the  
system catalogs.  This could make psql offer misleading RESET candidates.  
  
Commit dbf5a83d465 schema-qualified the unnest() call in this same query,  
but the catalog references were still left unqualified.  Fix that by  
referring to pg_catalog.pg_db_role_setting and pg_catalog.pg_database  
explicitly.  
  
Backpatch to 18, where the tab-completion for ALTER DATABASE ... RESET  
was introduced.  
  
Bug: #19523  
Reported-by: Zhou Digoal <digoal@126.com>  
Author: Vismay Tiwari <vismay.t@gmail.com>  
Reviewed-by: Paul Kim <mok03127@gmail.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19523-424457118202f570@postgresql.org  
Discussion: https://postgr.es/m/CALHMmB84qkCgv3QAR78YawgfqQZCxSPkRhppxzU=e6fg8RA+AA@mail.gmail.com  
Backpatch-through: 18  

commit   : 2bc7b71dc168d537c67a307e5ac5d6c764bbc721    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 11 Sep 2026 17:49:42 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 11 Sep 2026 17:49:42 +0900    

The fast path probes using the referenced index's collation. When that  
collation differs from the referenced column's, it can reject valid  
references or accept invalid ones. Changing the scan key's collation  
is not sufficient, since btree navigation must use the ordering under  
which the index was built.  
  
Cache index eligibility lazily after locking the referenced table,  
reloading the constraint information, and opening the index. Compare  
index and column collations using the held relation descriptors, and  
fall back to SPI on a mismatch. Also move the btree eligibility check  
here, avoiding a lookup of an index that REINDEX CONCURRENTLY could  
drop before the referenced-table lock is acquired.  
  
Cache both acceptance and rejection until the constraint information  
is reloaded, so subsequent rows need not repeat the comparisons. Check  
before probing a row, and let the caller use SPI if the index is  
unsuitable.  
  
Add ICU regression coverage for per-row validation, ordinary inserts,  
reordered index columns, and both directions of collation mismatch.  
  
Reported-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CAA4eK1Lk1DfgiFPL-HccZm-Nm+exg+FcsODH8KPw6BOBuzfHtA@mail.gmail.com  
Backpatch-through: 19  

commit   : f6b2d6b827a0f1a7485ca43a64b9ddfbebcd2934    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Sep 2026 09:48:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Sep 2026 09:48:51 +0530    

AlterPublicationOptions() can use stale publication state when the  
publication is modified concurrently while waiting for the publication  
lock. In particular, a concurrent ALTER PUBLICATION ... SET ALL TABLES  
can change puballtables, causing the validation to make decisions based  
on the old value and leads to assertion failure. Likewise,  
CheckAlterPublication() could miss a table added concurrently, letting  
SET ALL TABLES EXCEPT (...) leave pg_publication_rel with a mixture of  
inclusion and exclusion rows.  
  
Fix by acquiring the lock and re-reading the publication tuple in  
AlterPublication() before either path runs, and by calling  
CheckAlterPublication() only after that.  
  
Also fix 037_except.pl, which left one computed result untested and  
silently reused a subscription created by an earlier test.  
  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/CALDaNm1r2MkGu6h8zgU1Kj1sX-FcMQ7wGTeLSnhx-5joiyXEvg@mail.gmail.com  
Backpatch-through: 19, where it was introduced  

commit   : c58566d06f964166370e93f1bc8444a534bd0bd2    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Sep 2026 18:13:17 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Sep 2026 18:13:17 -0700    

Those changes were intended to avoid dependencies on the global libc  
locale settings by basing identifier casefolding on the default  
locale.  They introduced an unintentional behavior difference for the  
builtin provider with locale C and a single-byte encoding.  
  
Instead of fixing that edge case, just revert the changes.  The  
identifier casefolding behavior has always been based on the global  
libc locale, and clients make an effort to use the same rules.  Until  
we have a plan to change that, provider-specific identifier  
casefolding doesn't make sense.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260826225510.10.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : 9ed2684b89a43a2dd6295fdb151a0a98608457d4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Sep 2026 13:54:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Sep 2026 13:54:30 -0400    

The general nature of this interaction has been understood (at least  
by me) since before the original commit, but I failed to explicitly  
document it. I also left behind an XXX in the README which I intended  
to remove before commit. Fix those things.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/CA+TgmoYmXy-jiP5qDhqNEiYFEBzQsArO6O2d9E8szNZqi1bePQ@mail.gmail.com  

commit   : 6610a41ac7155d0d131dd861cb64c051554b4f73    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Sep 2026 13:46:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Sep 2026 13:46:26 -0400    

Oversight in 1129570f654e96d45bbc63397079171af29710b9  
  
Reported-by: Nazir Bilal Yavuz <byavuz81@gmail.com> (off-list)  
Backpatch-through: 19  

commit   : 07aef52eba3c2b10fb706f2ac48819597a339067    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 10 Sep 2026 17:56:39 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 10 Sep 2026 17:56:39 +0200    

Commit ac58465e0618 moved the discussion on clustering from CLUSTER's  
refpage to REPACK's, but somehow introduced a mistake regarding when  
exactly can the seqscan-and-sort strategy be used with respect to btrees  
(spoiler: it was 100% backwards).  Fix that, but also restructure and  
reword the whole subsection more fully to try and make it more coherent.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Antonin Houska <ah@cybertec.at>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/69CA7636-0359-42B6-B971-16A036698187@gmail.com  

commit   : 683ce2329c2d5fb2f7bf625131cd5d9de15987a8    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2026 17:30:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2026 17:30:01 +0900    

The previous warning message when falling back to sampling in a certain  
case failed to properly mention the reason for that.  
  
Also, for clarity, rewrite a comment about the fallback and add a note  
about it to postgres-fdw.sgml.  
  
Follow-up to commit 6a8571568.  
  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwHq1VuXwxeDU8N4dd9U4RFEW982qQ9C26mRQDs3nu_Naw%40mail.gmail.com  
Backpatch-through: 19  

commit   : ca3fd678f47becc5b84e0b027b2f062c5ad05b2b    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 10 Sep 2026 17:17:29 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 10 Sep 2026 17:17:29 +0900    

Explain that returning false for TM_SelfModified follows ExecLockRows(),  
which skips such tuples. This differs from TM_Updated, which is  
unexpected in READ COMMITTED with FIND_LAST_VERSION.  
  
Also remove "fall through to error" from the TM_Updated comment, since  
the code calls elog(ERROR) directly.  
  
Reported-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CAA4eK1Lk1DfgiFPL-HccZm-Nm+exg+FcsODH8KPw6BOBuzfHtA@mail.gmail.com  
Backpatch-through: 19  

commit   : 25649d6e791c2d803fff0ce8b69ed968028a5edc    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 10 Sep 2026 14:41:54 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 10 Sep 2026 14:41:54 +0900    

Commit b7b27eb41a5 added batching to the direct-index fast path for  
foreign key checks introduced by 2da86c1ef9b. Instead of probing the  
referenced index once per row, it accumulated referencing rows and  
checked them in groups, using SK_SEARCHARRAY for single-column foreign  
keys.  
  
The batching requires state to survive across trigger invocations and  
to be flushed at the end of each trigger-firing cycle. Follow-up work  
has had to define how that state interacts with nested trigger firing,  
subtransactions, deferred constraints, and SET CONSTRAINTS.  
  
Failure to handle one of those cases can leave a buffered check  
unperformed, allowing a transaction to commit a permanent foreign key  
violation without reporting an error. With PostgreSQL 19 close to  
release, there is not enough time to gain confidence that all relevant  
trigger and transaction states have been covered.  
  
Remove the batching and its after-trigger callback infrastructure,  
including the per-batch RI cache and associated subtransaction cleanup.  
Restore the early exit in AfterTriggerFireDeferred(), since batch  
callbacks can no longer queue additional deferred triggers after  
afterTriggerInvokeEvents() returns.  
  
Remove tests that exercise only the batching implementation and its  
callback and cache lifetime machinery. Retain tests that continue to  
exercise the underlying per-row fast path, including validation,  
scan-key construction, cross-type rechecks, deferred checks, and  
metadata invalidation.  
  
Keep the underlying per-row fast path. It performs each check  
synchronously and retains no pending checks across trigger invocations.  
Also retain the fixes made to the per-row probe path, including support  
for domain-typed referencing columns, restriction to btree referenced  
indexes, concurrent index replacement, metadata invalidation, and  
nullable referenced keys.  
  
This removal applies only to REL_19_STABLE.  
  
Discussion: https://postgr.es/m/CA+HiwqEDcCSDoYTtoXH4Ta_BpGN+revMZSLLj6GRz2_5ybwE1g@mail.gmail.com  

commit   : 139018268375b3f09995d2c1819b0d838ddacf36    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 10 Sep 2026 13:31:39 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 10 Sep 2026 13:31:39 +0900    

ri_FastPathCheck() acquired its scan snapshot before opening the  
referenced relation.  If it then waited for the relation lock in READ  
COMMITTED mode, a referenced row committed during the wait would not be  
visible to the old snapshot.  The check could consequently report a  
foreign key violation even though the referenced row existed.  
  
The batched path acquires its scan snapshot after opening the relations,  
so it does not have the lock-wait problem.  The per-row path remains  
reachable during constraint validation and checks re-entered from a  
batch flush.  
  
Take the snapshot after opening the referenced relation and reloading  
the constraint information.  This also agrees with the SPI path, which  
acquires the referenced-relation lock before selecting the snapshot  
used for the check.  
  
Also make the scan snapshot active for the duration of the check, so  
STABLE cast and equality functions use the same snapshot as the index  
scan.  Otherwise, a STABLE cast can miss rows inserted by earlier AFTER  
triggers and cause a valid foreign key to be rejected.  Add a  
regression test comparing this case with the SPI path.  
  
Finally, also advance the command counter after acquiring the  
referenced-relation lock and before reloading the constraint  
information, so local invalidations are processed under the lock, as in  
the SPI path.  
  
Add an injection-point test that pauses a per-row check before locking  
the referenced relation, commits the missing referenced row in another  
session, and verifies that validation succeeds.  Force per-row  
validation by using a role without SELECT privilege on the referenced  
table, so the test exercises this path even with batching enabled.  
  
Add isolation-test coverage for the visibility of a referenced row  
committed after the referencing transaction has executed an earlier  
command.  A later command can see such a row in READ COMMITTED, but not  
in REPEATABLE READ or SERIALIZABLE.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CA+HiwqEhm+_=bs=2wavAJz-UqC+1KebD31++mapJQQGweE8iQQ@mail.gmail.com  
Backpatch-through: 19  

commit   : b264391a846e8b5917b00dde2399c38843c75bb8    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 9 Sep 2026 20:39:53 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 9 Sep 2026 20:39:53 -0700    

Commits 630706ced0 and 9c8de15969 lost some encoding-specific nuances:  
in libc with EUC encodings, or in ICU with any non-UTF8 encoding, we  
cannot easily classify characters, so we must assume they are  
case-varying. Restore these behaviors.  
  
Previously, ILIKE using an index scan could cause wrong results.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260826221526.89.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : e418e8eb92aa1dccca18b297a85c7ff38a7ee2a0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 10 Sep 2026 11:54:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 10 Sep 2026 11:54:08 +0900    

pg_stat_progress_cluster translates REPACK into VACUUM FULL when  
pg_stat_progress_repack.repack_index_relid is zero, and into CLUSTER  
otherwise.  
  
Previously, repack_index_relid was set only when an index scan was used.  
When REPACK used a sequential scan and sort to order the table by an index,  
the field remained zero even though index ordering had been requested. As a  
result, pg_stat_progress_cluster incorrectly reported the command as  
VACUUM FULL instead of CLUSTER.  
  
Fix this by setting repack_index_relid to the OID of the requested ordering  
index when progress reporting starts, regardless of the scan method. This  
allows pg_stat_progress_cluster to correctly report REPACK as CLUSTER when  
index ordering is requested.  
  
Also update the documentation to clarify the meaning of the index columns  
and how REPACK is translated into CLUSTER or VACUUM FULL.  
  
Suggested-by: Fujii Masao <masao.fujii@gmail.com>  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Discussion: https://postgr.es/m/CAN4CZFMzy2V_wvRCBW5K8=wVCk1-C7nq=8otXO=u+s_1KZHqyA@mail.gmail.com  
Backpatch-through: 19  

commit   : d1f742d5d12654173b022fd7723ab206a3e3a3de    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 10 Sep 2026 11:51:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 10 Sep 2026 11:51:06 +0900    

Previously, when another session ran REPACK, CLUSTER, or VACUUM FULL and  
the user lacked permission to view its progress details,  
pg_stat_progress_cluster incorrectly reported the command as CLUSTER  
instead of NULL.  
  
pg_stat_progress_cluster is based on pg_stat_progress_repack and  
translates REPACK into CLUSTER or VACUUM FULL depending on whether index  
ordering is requested. However, this translation defaulted to CLUSTER,  
incorrectly converting NULL commands returned for insufficient privileges  
into CLUSTER.  
  
Fix this translation to preserve a NULL command when the user lacks  
permission to view the progress details.  
  
Bump catalog version.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Discussion: https://postgr.es/m/CAN4CZFMzy2V_wvRCBW5K8=wVCk1-C7nq=8otXO=u+s_1KZHqyA@mail.gmail.com  
Backpatch-through: 19  

commit   : 7c620d2bf87bdb9508dd8cb40377f84388244dca    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 10 Sep 2026 10:03:53 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 10 Sep 2026 10:03:53 +0900    

A clause connecting the same two EC members can be requested from the  
EC machinery in different contexts.  When building parameterized index  
paths for a relation, generate_implied_equalities_for_column derives  
an indexable clause with parent_ec set, to mark it as redundant with  
other join clauses derived from the same EC.  Meanwhile, at a join  
where the relations of a multi-relation EC member first come together,  
generate_join_implied_equalities emits a clause equating the same two  
members with parent_ec unset, since that clause is the sole enforcer  
of its member there and must not be dropped as redundant.  Because  
create_join_clause treats parent_ec as part of its cache-lookup key,  
such requests can yield two different RestrictInfos for the same  
condition, carrying different rinfo_serials.  
  
This breaks the assumption that one condition has exactly one serial  
number, which create_nestloop_path relies on to drop join clauses that  
are already enforced within a parameterized inner path.  As a result,  
the same condition could be enforced twice at different plan levels,  
wasting execution effort and applying the clause's selectivity twice,  
underestimating the join's row count.  
  
To fix, make create_join_clause copy the rinfo_serial from an existing  
clause that connects the same two members with the opposite parent_ec  
marking, so that the two clauses keep their distinct markings but are  
recognized as the same condition.  
  
As a result, a duplicate join filter disappears from one of the  
existing regression plans (the "cardinal_number" query in join.sql);  
the other plan changes are join-order differences between plans of  
essentially equal cost.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAMbWs4-3yZeBMGQDpmYRPdV-sL_=6H2AN=MoeneOT+VUk28PPg@mail.gmail.com  
Backpatch-through: 19  

commit   : be2602cfcc1578480ccefca66eda93975d2c10de    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 10 Sep 2026 10:03:13 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 10 Sep 2026 10:03:13 +0900    

Commit f836b688f ensured that at most one clone of a join clause is  
chosen for a parameterized path, so long as the clone variants are  
parse-tree distinct.  Two ways remained to end up enforcing the same  
condition more than once, which wastes execution effort and applies  
the clause's selectivity multiple times, underestimating the row  
count.  
  
If a commuting outer join nulls no Var referenced by a particular  
qual, the clone variants of that qual are parse-tree identical, and  
the incompatible_relids test cannot tell them apart.  To fix, enforce  
just the first surviving variant, identified by rinfo_serial.  
  
The other case is in get_joinrel_parampathinfo, where the  
clause-recovery pass for dropped EquivalenceClasses queries the EC  
machinery with a context that overlaps the preceding loop's, so the  
derived-clause cache can hand back a clause that that loop already  
accepted.  To fix, skip any clause that is already present in the  
collected list.  
  
Also add assertions verifying that the clauses to be enforced at a  
join or within a parameterized path contain no duplicate rinfo_serial,  
to catch any remaining or future violations.  These assertions are  
added in master only, since hard prevention of duplicate clauses is a  
new goal and other unfixed cases may remain.  
  
Back-patch to v19, as with commit f836b688f.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAMbWs4_Ezb1Lnj7BqcTQSysC6B5UFZxfhib8xr6rqpu5uqr8dA@mail.gmail.com  
Backpatch-through: 19  

commit   : ddee5d03077c05925e83533e50ebe805c934d2cf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Sep 2026 17:48:54 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Sep 2026 17:48:54 -0400    

Without CHECK_FOR_INTERRUPTS(), backends might not respond to query  
cancellations in a timely fashion, especially for JOIN_ORDER()  
specifications, where matching against each join can take O(n^2) time  
in the length of the join order list in degenerate cases.  
  
Recursive functions should check_stack_depth().  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/CA+TgmoYmXy-jiP5qDhqNEiYFEBzQsArO6O2d9E8szNZqi1bePQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 50ba390a4f81536aac13c1b8cf75c646a1156527    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 9 Sep 2026 16:02:24 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 9 Sep 2026 16:02:24 -0500    

The SIMD path for this command reads ahead via CopyLoadInputBuf()  
whenever fewer than sizeof(Vector8) bytes remain in the input  
buffer, even if those bytes hold a complete end-of-copy marker.  
If the input is a pipe whose writer has sent the marker but not  
closed the pipe, that read blocks, and COPY waits for data it will  
never use.  The scalar loop asks only for the bytes it needs, so  
it stops at the marker without reading any further.  
  
To fix, teach CopyLoadInputBuf() to decline a speculative load  
when the caller's remaining bytes contain a backslash, which in  
text mode might begin such a marker.  (CSV mode doesn't treat  
\. as special, so it is unaffected.)  The SIMD path then hands  
those bytes to the scalar loop, as it already does when a load  
comes up short.  Checking for the marker in the SIMD helper itself  
would be more direct, but a call there costs the compiler  
registers on every line, which measurably slowed COPY of short  
lines in testing.  
  
Oversight in commit e0a3a3fd53.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/CAN55FZ1qFb4Yo3-MWeQfGQnu1_Ksx4xcFC2m3hyw8a--%2BeHQYQ%40mail.gmail.com  
Backpatch-through: 19  

commit   : 94cc8c443a3115531be7abe414dad5034ee3bb57    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Sep 2026 13:45:46 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Sep 2026 13:45:46 -0700    

Commit 86f7c82cf102 reported the user catalog table restriction as a  
detail, but the other checks in check_concurrent_repack_requirements()  
were still a mix: some were hints, and the details repeated  
"REPACK (CONCURRENTLY)", which the primary message already names.  
  
Report them as details with the same "This operation ..." wording. The  
one actionable hint, ALTER TABLE ... REPLICA IDENTITY USING INDEX,  
stays.  
  
Backpatch to v19, where REPACK (CONCURRENTLY) was introduced.  
  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Suggested-by: Alvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/apBIFWzHYOaG0auN%40nathan  
Backpatch-through: 19  

commit   : 5dec175fb4c537947faaba504cda394b4ca6b726    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 Sep 2026 10:50:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 Sep 2026 10:50:09 -0400    

DROP TABLESPACE checked pg_shdepend for dependent objects without  
first locking the tablespace.  A concurrent command that recorded a  
shared dependency on the tablespace right after that check could still  
commit, leaving an object whose pg_shdepend entry (or, for a relation,  
pg_class.reltablespace) pointed to a tablespace that no longer existed.  
  
Close the race by having DropTableSpace() take an AccessExclusiveLock  
on the tablespace before calling checkSharedDependencies().  That  
conflicts with the AccessShareLock shdepLockAndCheckObject() takes when  
recording a new dependency, so the loser of the race blocks and  
rechecks once the winner commits.  
  
That AccessExclusiveLock creates a new deadlock: ALTER TABLESPACE  
RENAME/SET and the internal ACL/owner updates in DROP OWNED and  
REASSIGN OWNED touched the catalog tuple without locking the  
tablespace, risking a lock-order cycle with DROP.  Fix by taking an  
AccessShareLock first in all four paths, rechecking pg_shdepend after  
any wait in the DROP OWNED and REASSIGN OWNED cases.  GRANT, REVOKE,  
and ALTER TABLESPACE ... OWNER TO already lock the object.  
  
Add isolation tests covering both orderings of the original race  
(dependency-first and drop-first) and all four previously-unlocked  
update paths.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://postgr.es/m/CAJTYsWXjAQFnGKzXsht3XK8KHhyhontwFJw4JAHsUSfs_ptR4g@mail.gmail.com  
Backpatch-through: 14  

commit   : 40d811540a589cbddeb0736966f2541088134163    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 9 Sep 2026 12:58:00 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 9 Sep 2026 12:58:00 +0200    

Previously, running REPACK (CONCURRENTLY) on a materialized view failed  
with a confusing "has no identity index" error.  
  
REPACK (CONCURRENTLY) replays changes decoded from WAL, but a  
materialized view produces none, since it cannot be modified by DML and  
REFRESH rewrites it through a transient heap that is not logically  
decoded.  
  
Fix this by reporting a clear error for materialized views upfront,  
alongside the existing checks for system catalogs and TOAST tables, and  
document the limitation.  
  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Kiran Kaki <itskkpg@gmail.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/CALj2ACXPvy4_LkQ0nHKgbZjAGK9fkDqRYUvXA3hgwxPm_X7Eng@mail.gmail.com  

commit   : 46c6fb9a82f2eaa0b56f1231e12e65af39e5ec84    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 9 Sep 2026 11:10:15 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 9 Sep 2026 11:10:15 +0200    

An XXX comment in launcher.c added by commit 2af1dc89282b questioned why  
the slot drop does not request disabling logical decoding.  But the  
conflict detection slot is a physical slot, so there is no logical  
decoding state to disable.  Remove that comment and clarify the  
situation elsewhere.  
  
Author: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/TY4PR01MB177186C8AB596F30DF704ECDC94B62@TY4PR01MB17718.jpnprd01.prod.outlook.com  

commit   : 04bb1500253489de049a0f26ff1843197c9da0c0    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 13:04:59 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 13:04:59 -0700    

REPACK (CONCURRENTLY) is not an MVCC-safe operation; it doesn't  
preserve the visibility information, which logical decoding needs  
because it reads user catalog tables under a historic snapshot.  
  
Disallow REPACK (CONCURRENTLY) on user catalog tables. Removing this  
check requires making it MVCC-safe and logical rewrite mappings.  
  
Backpatch to v19, where REPACK (CONCURRENTLY) was introduced.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/apBIFWzHYOaG0auN%40nathan  
Backpatch-through: 19  

commit   : 9bf3a414560d93ef8e8cf61748cd5783ab4bc9f9    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 12:06:09 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 12:06:09 -0700    

REPACK (CONCURRENTLY) launches a background worker to decode changes  
made while the table is being rewritten. The worker connects as the  
table owner but bypassed the LOGIN check only, so CONNECT was still  
checked against a role that need not have it, and the command could  
fail with "permission denied for database".  
  
Pass BGWORKER_BYPASS_ALLOWCONN as well, as we do for parallel  
workers. That is safe because the leader already checked the invoking  
user's privileges on the table before starting the worker.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Author: Matheus Alcantara <mths.dev@pm.me>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/apBbzFd_EYAfHV45@nathan  
Backpatch-through: 19  

commit   : fe7b60723420c5279824c35efc45630889239a70    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 11:49:14 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 11:49:14 -0700    

REPACK (CONCURRENTLY) didn't check the table AM of the table being  
repacked, so if the table AM doesn't support logical decoding, the  
concurrent changes are never decoded and are silently lost from the  
rewritten table.  
  
Fix by erroring out for tables that use a non-heap access method.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/apBkixO4xAGFoiT3@nathan  
Backpatch-through: 19  

commit   : fa48e39526b8d1cdc5b6e86074d6a3149fbd059b    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 11:12:36 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 8 Sep 2026 11:12:36 -0700    

Commit 266543a made initial table synchronization use "COPY table TO"  
for a partitioned table, but decided that from the relation kind  
alone. A partitioned table is only accepted there since v19, so a v19  
subscriber replicating from an older publisher with  
publish_via_partition_root failed at table sync.  
  
Check the publisher version, and fall back to the "COPY (SELECT ...)  
TO" variant otherwise.  
  
Backpatch to v19, where 266543a changed the initial table  
synchronization.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260905040020.57.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : 21b2808536859f1ffe257088df0f6f09edfd96a1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 8 Sep 2026 10:00:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 8 Sep 2026 10:00:22 -0400    

There's not really any good reason to store an empty advice string  
in an advice stash, but it's entirely possible that some people might  
do it by accident. If they do that without this fix, restarting the  
system will result in failure while reloading pg_stash_advice.tsv.  
  
The root cause is that I (rhaas) did not think clearly enough when  
defining pgsa_next_tsv_field(). After returning each field on the  
line, it set *cursor to the start of the next field, and after  
returning all of them, it set *cursor to the trailing NUL byte. But  
when the last field on the line is empty, this is ambiguous: if we're  
pointing at the trailing NUL byte, it could be either because it's the  
start of the zero-length field or because we're out of fields. To  
remove the ambiguity, this commit decides that *cursor will instead  
be set to NULL when there are no more fields.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260827171830.68.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : 98f6984e5c0d180264d1e972c36252c8b36206ef    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Sep 2026 14:34:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Sep 2026 14:34:31 +0200    

ExecInitModifyTable() evaluated ForPortionOfExpr.targetRange  
unconditionally at executor start-up, with no EXEC_FLAG_EXPLAIN_ONLY  
guard. This caused three problems:  
  
- EXPLAIN (GENERIC_PLAN) failed with "no value found for parameter 1".  
  
- Plain EXPLAIN with FOR PORTION OF (null) raised "FOR PORTION OF  
  target must not be null".  
  
- Plain EXPLAIN ran user functions appearing in the target a second  
  time, beyond the one evaluation the planner already does for  
  selectivity estimation.  
  
Now we skip the evaluation and the accompanying null check in  
explain-only mode.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA%2BrenyXci9khYXJ8uSwzF30DVw%2Bzc4QwGb1RdsuOu_YtrFuy1g%40mail.gmail.com  

commit   : 24dd8c369e5656a9c38f5494c9c57c38705ce62f    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 8 Sep 2026 14:06:06 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 8 Sep 2026 14:06:06 +0200    

The current implementation doesn't support it correctly, leading to  
mysterious warnings and some worse problems.  Have the combination throw  
an error.  
  
This is intended as a temporary stopgap until we can implement it in a  
future release, as it's a useful feature.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Author: Antonin Houska <ah@cybertec.at>  
Author: Osama Abdul Qader <osamaabdulqader.cs@gmail.com>  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/apBCEl4hBHlq0axm@nathan  

commit   : d0518cb3e40503859e5dd17a0a75de9b8967fe4b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 8 Sep 2026 13:30:55 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 8 Sep 2026 13:30:55 +0300    

This reverts commit c06d1a4ba6b26eef27b04074683cccade6c277ee.  
  
The commit assumed that if the FSM code tolerates torn pages, everything else  
does so.  Readers that do not tolerate that include RelationCopyStorage(),  
used by ALTER TABLE ... SET TABLESPACE for every fork, the read stream in  
RelationCopyStorageUsingBuffer() used by CREATE DATABASE ... STRATEGY =  
wal_log, and, most awkwardly, the checksum verification in base backups and  
pg_checksums.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260901211837.f6.noahmisch%40microsoft.com  
Backpatch-through: 14  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  

commit   : f1940321687644a3ef38dccca8bbeb7c50d4cbdc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Sep 2026 09:35:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Sep 2026 09:35:44 +0200    

FOR PORTION OF valid_at FROM $1 TO $2 fails with "could not determine data  
type of parameter $1", so using PREPARE requires users to say $1::date  
etc. But transformForPortionOfClause() already coerces the bounds, since  
it builds a constructor for the targeted range. We just need to store the  
coerced expressions in targetFrom and targetTo.  
  
This also improves pg_get_ruledef(), which now renders an untyped NULL  
bound as NULL::date instead of NULL::unknown.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA%2BrenyW1uJp1dw%3DiK7MsWfbbZf-dKP_4JLoQ65wj%3Dfry35FjCw%40mail.gmail.com  

commit   : c13e961c603cd0abb282d2a846ff8574dd80d3a1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 8 Sep 2026 16:48:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 8 Sep 2026 16:48:29 +0900    

On slow machines, this test can take long enough to generate WAL that a  
time-based checkpoint occurs before the primary is stopped. If the  
checkpoint record is written to the tail WAL segment that the test later  
removes, a standby initialized from the resulting backup tries to read  
the missing checkpoint record and fails with a PANIC during startup.  
This caused the test to fail on buildfarm member skink.  
  
Fix this by setting checkpoint_timeout high enough to prevent unrelated  
checkpoints during the test. This follows the approach used by other  
recovery tests, such as 043_no_contrecord_switch.pl, that depend on a  
specific WAL layout.  
  
Backpatch to all supported versions.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwFajfjKhvNSTkTcE-wFn30p_A0_i1cvk-Q=FJhDr_5cXA@mail.gmail.com  
Discussion: https://postgr.es/m/9ffdb19a-7a89-424e-925a-dd981c37f0ba@gmail.com  
Backpatch-through: 14  

commit   : d2384bc30f6882d30cb49e2912580ab95d642f3c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 8 Sep 2026 10:45:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 8 Sep 2026 10:45:33 +0530    

Commit 6168c65ddc added a test verifying that the conflict detection  
slot's xmin regresses to the horizon pinned by an in-progress transaction  
in the database of a newly added subscription that has retain_dead_tuples  
enabled. However, it used query_until(), which can return before starting  
a transaction, allowing the test to proceed without a pinned xid.  
  
Use query_safe() so the transaction setup completes synchronously and the  
xid is assigned before the xmin checks run.  
  
Per buildfarm.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/OS9PR01MB12149257A97EE1BD3296F6AEBF5B12@OS9PR01MB12149.jpnprd01.prod.outlook.com  
Backpatch-through: 19  

commit   : 729e4a322786381c68b83d014f8ad5be300b942f    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 8 Sep 2026 10:06:06 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 8 Sep 2026 10:06:06 +0900    

When creating a nestloop plan for a partitionwise child join, the  
outer rel's relids are child relids, but PlaceHolderInfo.ph_eval_at is  
always expressed in terms of the topmost parent rels.  As a result,  
replace_nestloop_params() and identify_current_nestloop_params()  
failed to recognize that a PlaceHolderVar evaluated at the outer child  
rel can be supplied as a nestloop param.  Instead, the Vars within the  
PHV's expression were replaced with params, but the outer child rel  
emits only the PHV, not those bare Vars, leading to "variable not  
found in subplan target list" errors from setrefs.c.  
  
To fix, also include the outer rel's top parent relids in the relid  
set used for these checks, so that ph_eval_at comparisons are done in  
terms of parent rels while Var checks continue to work in terms of  
child rels.  
  
On v18 and later, the required-outer set passed to  
identify_current_nestloop_params() has the same problem: it is in  
terms of child rels once a parameterized child join path has been  
reparameterized by an upper child join.  With the above fix in place,  
a PlaceHolderVar that depends on both the outer rel and the parameter  
source becomes a single NestLoopParam, and that param was never  
claimed by any nestloop node, leading to "failed to assign all  
NestLoopParams to plan nodes" errors.  To fix, also include the top  
parents of any child rels in that set.  Older branches lack this code  
path, so they receive only the first change.  
  
Back-patch to all supported branches.  
  
Bug: #19653  
Reported-by: Annie <10215501441@stu.ecnu.edu.cn>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19653-9352cc6ba17b662f@postgresql.org  
Backpatch-through: 14  

commit   : 2b9e1aff4d3d933ae8ee377fef22c2af9c7797e8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Sep 2026 19:18:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Sep 2026 19:18:08 +0200    

List of commits reverted:  
  
  2f094e7ac69  SQL Property Graph Queries (SQL/PGQ)  
  cd8844e7db6  Make some tests more stable by adding more explicit ordering  
  182cdf5aeaf  pg_dump: Add appropriate version check  
  c9babbc8816  Dump labels in reproducible order  
  040a56be4bc  Cleanup users and roles in graph_table_rls test  
  5282bf535e4  Fix some typos and make small stylistic improvements  
  720f0f89d69  Reject consecutive element patterns of same kind  
  288ae968726  Add a graph pattern variable only once  
  c5b3253b8ab  Property references are preferred over regular column references  
  a0dd0702e46  Fix cross variable references in graph pattern causing segfault  
  2ff289d0393  Check for stack overflow when rewriting graph queries  
  9082680c34e  Fix typos and grammar in graph table rewrite code  
  ac3bcc041c5  Fix collation of expressions in GRAPH_TABLE COLUMNS clause  
  9d2979dd685  pg_get_viewdef() and lateral references in COLUMNS of GRAPH_TABLE  
  891a57c7394  Do not define type for a property graph  
  dc9e7c9ed93  Handle nodes that may appear in GraphPattern expression trees  
  f6edd8ed708  Add ORDER BY to test query to stabilize test  
  1190f858eaf  doc: Small synopsis wording change for consistency  
  d0eac3cafb0  Make spelling consistent  
  6827de95ee0  Simplify code in objectaddress.c for some property graph objects  
  5778fb3eafd  Fix typo in error message  
  72498a86989  Handle element label and label property objects in object address functions  
  4cb2a9863d8  Fix LATERAL references in GRAPH_TABLE with multi-label pattern  
  9d8cdcbe0c8  Record dependencies on graph labels and properties  
  2a7e95b659d  Readable identity strings for property graph objects  
  ac0ad6a7c9d  Prevent dropping the last label from a property graph element  
  36aae3d0297  Fix handling of dropping a property not associated with the given label  
  cc9aa7f3a98  Resolve unknown-type literals in GRAPH_TABLE COLUMNS  
  d8687368300  Make property graph object descriptions better translatable  
  45d4c917ff4  Fix properties orphaned by dropping a label  
  33bfad0f3ca  Remove apparent support for SECURITY LABEL ON PROPERTY GRAPH  
  ccca2cd81b2  Fix pg_dump ACL minimization for PROPERTY GRAPH.  
  7883ea13ffd  Fix replace_property_refs() ignoring the root of expression tree  
  b820c623dd5  Resolve unknown-type literals in property expressions  
  01c544e1afb  Prohibit locking clauses on GRAPH_TABLE  
  8d2beee027a  Restore the ability to use | and -> as prefix operators.  
  d2ac26eb9b1  Fix missing space before WHERE in GRAPH_TABLE deparse  
  4054ec5b4f3  Prohibit GRANT ... ON TABLE on a property graph  
  77964322d60  doc: Add PROPERTY GRAPH to the access privilege tables  
  c5e11de2f37  More tab-completion for DROP PROPERTY GRAPH  
  8ce749f8f65  Disallow aggregates, window functions, and SRFs in GRAPH_TABLE COLUMNS  
  22d0eebfef7  Report duplicate property and label names with a proper error  
  41a300ae3df  Make generate_queries_for_path_pattern_recurse() interruptible  
  58af2138740  Fix inferred property graph keys with INCLUDE columns  
  63f8e9773aa  Fix pg_event_trigger_ddl_commands for GRANT ON PROPERTY GRAPH  
  07df2b25327  doc: reformat GRAPH_TABLE examples  
  1c8c790ec10  Coerce GRAPH_TABLE pattern WHERE clauses to boolean  
  
plus release notes entries and typedefs.list changes.  
  
Discussion: https://www.postgresql.org/message-id/CAAKRu_bEtjWYWhYxSo0o_t3DaZYRQd5PkC0abA0g9Mp4%2BovH0w%40mail.gmail.com  

commit   : 9186ffd6336763b9f38fee25b32f3e556b4ca518    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 7 Sep 2026 14:34:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 7 Sep 2026 14:34:15 +0530    

Since the retain_dead_tuples feature uses a single cluster-wide  
replication slot across all subscriptions, adding a new subscription on a  
database with an older active transaction can require  
conflict_detection_slot.xmin to move backward to avoid missing dead tuples  
needed for update_deleted conflict detection.  
  
Previously, if a newly created subscription had an older active  
transaction than the slot's current xmin, the slot update occurred during  
worker apply, leading to an assertion failure.  
  
Fix this by having the launcher track the set of databases with active  
tuple-retaining subscriptions. When a database joins this set (either via  
a new subscription or when retention restarts), the launcher resets the  
slot's xmin to the cluster-wide safe decoding horizon before starting any  
workers. Because this horizon accounts for all active transactions across  
the entire cluster, it serves as a safe seed without requiring retroactive  
backward movement by individual apply workers.  
  
In passing, update the retain_dead_tuples documentation to clarify two  
operational boundary cases:  
(a) Conflict data continues to accumulate even when a subscription is  
disabled or its apply worker is stopped.  
(b) track_commit_timestamp must be enabled for conflict detection to  
function properly.  
  
Reported-by: Nisha Moond <nisha.moond412@gmail.com>  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/TY4PR01MB177182F547A62FC2666EC04EC94B72@TY4PR01MB17718.jpnprd01.prod.outlook.com  
Backpatch-through: 19, where it was introduced  

commit   : 2ad899642020ef7125818fddd494f5c76b928293    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 7 Sep 2026 11:50:56 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 7 Sep 2026 11:50:56 +0900    

When outer-join identity 3 permits a join to commute with lower outer  
joins, we generate multiple clone versions of its join clause, of  
which only one should be applied in any given plan.  When building a  
join relation's restriction list, subbuild_joinrel_restrictlist  
selects the appropriate clone by checking required_relids and  
incompatible_relids, but no such selection was made for movable join  
clauses pushed down into a parameterized path.  As a result, a  
parameterized scan or join could enforce more than one clone of the  
same condition, shown by EXPLAIN as a duplicate qual.  This wastes  
effort evaluating the same condition repeatedly.  What is worse, it  
applies the clause's selectivity multiple times, underestimating the  
result's row count.  
  
To fix, in get_baserel_parampathinfo and get_joinrel_parampathinfo,  
skip a clone clause if any outer join listed in its  
incompatible_relids has already been computed below the point of  
evaluation.  
  
Back-patch to v19, but no further.  While this bug goes back to v16,  
applying the fix in released branches risks destabilizing plans that  
users are currently happy with, and there have been no field  
complaints.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs4-g5TFF5k=jfe3JVWqtv_cCTOMmQRUp0_E8fApgqcqBng@mail.gmail.com  
Backpatch-through: 19  

commit   : 941568a9067267f71d5f68862584a92294828230    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 5 Sep 2026 09:12:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 5 Sep 2026 09:12:45 +0900    

When neither BKPIMAGE_HAS_HOLE nor BKPIMAGE_COMPRESSED is set,  
DecodeXLogRecord() checks that bimg_len needs to be equal to BLCKSZ.  
However, the associated error message reported the data length  
associated to a block (DecodedBkpBlock.data_len), and not the length of  
the block (DecodedBkpBlock.bimg_len).  
  
Oversight in 57aa5b2bb11a, probably due to some copy-paste from the  
surroundings.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAJTYsWVz9ymE7aMt2ZiQvs1bxNvhjfTf+XaJEsdFw7MT5dvtYQ@mail.gmail.com  
Backpatch-through: 14  

commit   : f4012672bb2e5f1b0a4641826e14e9d209049dea    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 4 Sep 2026 18:40:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 4 Sep 2026 18:40:01 +0900    

When analyzing a foreign table pointing to a partitioned or inherited  
table on the remote server, this method just imported relpages and  
reltuples for the parent table from the remote pg_class, causing a  
discrepancy or an error in results compared to the sampling method.  
  
* In the partitioning case, while the sampling method sets relpages=0,  
  this method set relpages=-1.  (For reltuples, the results of both  
  methods match.)  
* In the inheritance case, while the sampling method sets  
  reltuples=(# of rows in the parent and child tables), this method set  
  reltuples=(# of rows in the parent table).  (For relpages, the results  
  of both methods match.)  
  
As relpages and reltuples are used for costing foreign paths, these  
would lead to incorrect plans or plan changes depending on the method.  
To fix, do the following:  
  
* For the partitioning case, modify postgres_fdw to set relpages=0 to  
  match the sampling method.  
* For the inheritance case, we could also modify it to set the correct  
  reltuples value by fetching reltuples for the child tables as well,  
  but 1) the change isn't small, and 2) table inheritance hasn't been  
  used that much these days, so fix by disabling this method.  
  
While at it, adjust comments and docs slightly.  
  
Oversight in commit 28972b6fc.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK173b2Xvyoeq%3DY7L09H%2BajgMgxC2fYe%3D7CCunZz8tGTfFA%40mail.gmail.com  
Backpatch-through: 19  

commit   : 10a84539b9474310c849c4a6dc965f496864ec94    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Fri, 4 Sep 2026 10:33:39 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Fri, 4 Sep 2026 10:33:39 +0900    

If a LATERAL subquery references a PlaceHolderVar that must be  
evaluated at an outer join, the subquery's lateral_relids include that  
outer join's relid, since the lateral parameter is the outer join's  
output.  join_is_legal() verified that the rels named by a proposed  
join's minimum parameterization could still be joined to from outside,  
but it did not consider such outer-join relids.  As a result, when  
identity 3 permitted a commuted join order, we could approve a join  
that includes part of that outer join's required input, even though  
the outer join could then be completed only above the proposed join,  
leaving the lateral parameter forever unsatisfiable.  
  
In assert-enabled builds this tripped the backstop Assert in  
try_nestloop_path().  In production builds the bogus join generated  
only paths whose parameterization can never be satisfied, so they  
could never appear in a complete plan.  This not only wasted planning  
effort, but also could mislead the clauseless-join heuristics into  
thinking that legality of this join means that some other join rel  
need not be formed, and that could lead to failure to find any plan at  
all.  
  
Such joins used to be rejected by the have_dangerous_phv() check in  
join_is_legal(), which refused any join where a PlaceHolderVar's eval  
set overlapped the other side of the join without being contained in  
it.  Commit a16ef313f removed that restriction, exposing this  
oversight.  
  
To fix, teach join_is_legal() to reject a proposed join if its minimum  
parameterization includes an outer-join relid whose outer join cannot  
be formed strictly outside the join, that is, when any rel needed to  
form that outer join must become part of the proposed join's own join  
tree.  
  
Back-patch to v18, where commit a16ef313f removed the  
have_dangerous_phv() restriction.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49ZveAYx9T5b0=gxn0pnvqq=MbN-Z4KLbLAE+kH06mWVA@mail.gmail.com  
Backpatch-through: 18  

commit   : bb238161f910cefe67c7c24522e817c831ea4909    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 3 Sep 2026 11:49:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 3 Sep 2026 11:49:09 +0200    

Fixups for commits b99b74144f9, 79b101486c1, bf7d19be9b1.  

commit   : 08b016edd568cd154af3c23b8b347a8d1036498d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 3 Sep 2026 13:56:52 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 3 Sep 2026 13:56:52 +0530    

The retain_dead_tuples feature waits for concurrent transactions to be  
applied before advancing conflict_detection_slot.xmin. It gets the WAL  
write position from the publisher and waits until the apply remote  
position passes it. This ensures that dead tuples, commit timestamps, and  
origins needed for conflict detection (update_deleted,  
update_origin_differs, and delete_origin_differs) are retained while  
those transactions are applied.  
  
However, with asynchronous commit enabled on the publisher, a committed  
transaction may not have updated the WAL write position yet. As a result,  
the reported WAL position can lag behind the latest committed transaction.  
This can cause conflict_detection_slot.xmin to advance prematurely,  
allowing dead tuples needed for conflict detection to be removed before  
subsequent asynchronously committed transactions are applied.  
  
Report the end of the last inserted WAL record instead. A transaction  
inserts its commit record before it is marked committed, so the insert  
position cannot be behind a transaction that has already committed.  
Transactions that have entered the commit phase but have not yet inserted  
their commit record are still accounted for by the in-commit transaction  
ID reported in the same message.  
  
In addition to above, add missing trailing period to update_deleted  
conflict detail messages which are added for the same feature.  
  
Reported-by: Nisha Moond <nisha.moond412@gmail.com>  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/TY4PR01MB177182F547A62FC2666EC04EC94B72@TY4PR01MB17718.jpnprd01.prod.outlook.com  
Backpatch-through: 19, where it was introduced  

commit   : e65f21a274eb9de52b8286ff3b721259e6c37e82    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Sep 2026 12:14:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Sep 2026 12:14:44 +0900    

Previously, a session that had created temporary objects could hang during  
exit if its default transaction mode was SERIALIZABLE READ ONLY DEFERRABLE  
and a concurrent serializable transaction was prepared. During backend  
exit, temporary-relation cleanup pushed a regular transaction snapshot,  
which honored the session's default settings and could wait for a safe  
serializable snapshot. So, if the conflicting transaction was prepared,  
this wait could last indefinitely.  
  
The wait occurred while the backend was already exiting and interrupts  
were held off, so even pg_terminate_backend() could not cancel it. The  
backend therefore remained until the prepared transaction was resolved.  
  
Temporary-relation cleanup only needs an active MVCC snapshot for fetching  
TOAST data from catalog tuples while dropping temporary objects. It does  
not need a transaction snapshot affected by the user's default isolation  
settings. So, use a catalog snapshot instead, which provides the needed  
protection without entering the deferrable safe-snapshot wait.  
  
Backpatch to all supported versions.  
  
Bug: #19441  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19441-ec29f3b1363b4a68@postgresql.org  
Backpatch-through: 14  

commit   : 9431cce4dc97fe3eaad73e6f98ac16d62755eb82    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Sep 2026 12:09:49 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Sep 2026 12:09:49 +0900    

The buildfarm member akepa reported a failure in the  
031_recovery_conflict.pl test.  
  
The test checked pg_stat_database_conflicts immediately after detecting  
a recovery conflict in the standby log. However, the conflict counter is  
flushed by the canceled backend during backend exit, so WAL replay  
completion and the log message did not guarantee that the updated  
statistics are visible yet. So, previously, the test could see a conflict  
counter of 0 even though the conflict had already occurred, triggering  
the test failure.  
  
Fix this by polling for the expected conflict counter instead of reading  
it only once, handling the asynchronous pgstats update.  
  
Per buildfarm member akepa.  
  
Backpatch to v17, where this test is enabled and has the same race.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com  
Backpatch-through: 17  

commit   : 1c8c790ec104bbef338eb52a9dc17030cee7c82e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Sep 2026 20:43:32 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Sep 2026 20:43:32 +0200    

transformGraphElementPattern() and transformGraphPattern() ran their  
WHERE clauses through transformExpr() without ever applying  
coerce_to_boolean(), so a WHERE clause of any type was accepted and  
its bare datum was used as the qual, which resulted in wrong results  
without a diagnostic.  Route both sites through  
transformWhereClause(), like every other WHERE clause, and add  
regression tests for the element-level and pattern-level cases.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAON2xHNZUS8ZwzVEJFeRirsC_-7EJvdbwABSzdGaJ_DF9DvHoQ%40mail.gmail.com  

commit   : 75716fe3ddbd98737459f1d24c7f459a7173ff27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Sep 2026 10:53:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Sep 2026 10:53:35 -0400    

Not many buildfarm members run this test, since it's gated behind  
PG_TEST_EXTRA=xid_wraparound, but of those that do, the slower ones  
not infrequently fail.  The reason seems to be that the test expects  
an INSERT command to either succeed or fail, but there's a window  
where it can succeed while issuing a warning about impending  
wraparound.  poll_query_until treats nonempty stderr as a failure,  
so it loops an extra time until the INSERT succeeds with no warning.  
There seems no reason to treat this behavior as wrong, so adjust  
the test to accept it.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Diagnosed-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/7a68bee2-91bd-481d-be44-160e6beebc83@gmail.com  
Backpatch-through: 17  

commit   : c0584c27f4f70935b3ccf31e58edb8e175fec447    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Sep 2026 09:22:40 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Sep 2026 09:22:40 -0500    

Commit f63ae72bbc converted postgresql.conf.sample to spaces so  
that it lines up at any tab width, but replace_guc_value() still  
pads with tabs when it re-aligns the trailing comment of a  
rewritten setting.  Fix that.  
  
Oversight in commit f63ae72bbc.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/apRezMywHRuR5h-6%40nathan  
Backpatch-through: 19  

commit   : a3bc7f2c0de8ad5c6ae746cb6c1c5c187a60c124    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 2 Sep 2026 15:32:54 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 2 Sep 2026 15:32:54 +0900    

Commit 44fb59fc6 taught the grouping-conflict walker to treat the arg  
of a simple CASE as a direct operand of each WHEN comparison, but it  
only checked the collation, on the assumption that the WHEN operator  
is always the type-default "=" and thus matches the grouping eqop.  
That assumption fails once the arg is relabeled to another type: the  
WHEN then compares under that type's "=", which need not agree with  
the grouping equality.  For instance, with a DISTINCT over a citext  
column, a qual such as "CASE t::text WHEN 'A' THEN ..." was pushed  
below the Unique, although the equivalent "t::text = 'A'" is correctly  
kept above it.  
  
Instead of special-casing the arg, have the walker bind a Var arg  
while walking the WHEN conditions and resolve each CaseTestExpr to it,  
so that the arg is checked exactly as each WHEN uses it: with the  
opfamily and collation checks of a direct operand when the WHEN is a  
comparison, and as a non-operand reference otherwise.  A non-Var arg  
is walked once as a non-operand, as before.  The CaseTestExpr in an  
ArrayCoerceExpr's elemexpr and a JsonConstructorExpr's coercion stand  
for something else and are left alone.  
  
Reported-by: Tender Wang <tndrwang@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://postgr.es/m/CAHewXNkvGTOgijRLjmudpg=wz0d-J8ChY2o7ksh3Be+Q_Bxwog@mail.gmail.com  
Backpatch-through: 18  

commit   : 7b4c2c1bcd366d4324fdee4f99c15e0b391d5f43    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Sep 2026 14:32:02 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Sep 2026 14:32:02 +0900    

When recovery starts from a backup without a signal file, pg_subtrans  
is not started at the beginning of recovery and remains unstarted  
throughout recovery. However, previously, a restartpoint run by  
the checkpointer during recovery nevertheless tried to truncate  
pg_subtrans, triggering the assertion failure:  
  
    TRAP: failed Assert("TransactionIdIsValid(initial)")  
  
This commit fixes this by tracking whether pg_subtrans has been  
started during recovery, and have the checkpointer check this flag  
before truncating pg_subtrans at restartpoints.  
  
Backpatch to all supported versions.  
  
Reported-by: Imran Zaheer <imran.zhir@gmail.com>  
Author: Imran Zaheer <imran.zhir@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CA+UBfamzfEReT0VOGRUW_=_AecCYQ-CNKLR_T4Q+YEmJAH3fdg@mail.gmail.com  
Backpatch-through: 14  

commit   : 7635a3206797a9c793bcf2e43d107c9fe08dc17d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Sep 2026 14:14:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Sep 2026 14:14:22 +0900    

The query is now stored as normalized in pg_stat_statements, with its  
LSN position ignored in the jumbling, resulting in:  
WAIT FOR LSN $1;  
  
The option values in the WITH clause are left untouched.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Author: Sirisha Chamarthi <sirichamarthi22@gmail.com>  
Reviewed-by: Sami Imseih <samimseih.pg@gmail.com>  
Reviewed-by: Rithvika Devisetti <devisettirithvika@gmail.com>  
Discussion: https://postgr.es/m/1f04f78c-2cfa-47a0-997f-f02572cd10eb@eisentraut.org  
Backpatch-through: 19  

commit   : f23de8dcba906ba27250f5f878e0684795eaf853    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 2 Sep 2026 14:03:50 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 2 Sep 2026 14:03:50 +0900    

Several queries in the foreign_key test sort pg_constraint rows with  
"ORDER BY oid::regclass::text".  These OIDs are constraint OIDs, not  
relation OIDs, so the regclass cast renders them as numeric strings,  
and text comparison of numeric strings depends on digit count.  If the  
OID counter crosses a power of ten while the test runs, the output  
order flips, causing spurious test failures.  This cannot happen in a  
fresh cluster, but installcheck against a long-lived cluster can hit  
it.  
  
To fix, sort by constraint name, which is unique within each of these  
queries, and use COLLATE "C" so that the order does not depend on the  
database's default collation either.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49KaJFGs4rfBWk+YmHPTXZ+pJTMJ12iaz7ruZdSK+sC5w@mail.gmail.com  
Backpatch-through: 18  

commit   : 763d563eaec82528fdd49c07830a2dae00567778    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 2 Sep 2026 13:37:41 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 2 Sep 2026 13:37:41 +0900    

When reduce_outer_joins reduces an outer join to an antijoin, any IS  
NULL qual on a Var from the antijoin's nullable side is necessarily  
true.  Previously, such quals were discarded later in  
distribute_qual_to_rels, mainly to avoid bogus selectivity estimates.  
But that discard was incomplete: the qual remained in the jointree,  
while its Vars were not counted in attr_needed.  Since commit  
2ebf25e7d, join removal edits the jointree and expects it to contain  
no other references to a removed rel, so it could remove a rel that  
such a discarded qual still references, and then trip an assertion on  
the qual's stale Var.  
  
To fix, move this processing to an earlier phase: such quals are now  
removed from the jointree by reduce_outer_joins itself.  This way  
later phases see a consistent query tree, and  
check_redundant_nullability_qual is no longer needed, so remove it.  
  
Back-patch to v16, as with commit 2ebf25e7d.  
  
Reported-by: Tender Wang <tndrwang@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAHewXNk8b0TsSy4dL=CO7FXL2W3WBm0BcdP-zwNJePa-Qj4HzA@mail.gmail.com  
Backpatch-through: 16  

commit   : 8e6860fb9638b5db784a24419d4441f0bf2cd04c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Sep 2026 09:19:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Sep 2026 09:19:32 +0900    

Several invocations decoded and printed the full WAL range even though  
the test only needs to confirm that a command form works or that  
decoding reaches a specific error. Limit those checks to one record,  
and start the fall-off-the-end checks near the end of the generated WAL.  
  
This change reduces the IPC overhead overall, particularly on Windows,  
without reducing coverage.  
  
I am usually hesitant to backpatch such changes as this is only an  
improvement, but the gains are too good in terms of IO and runtime, for  
both the CI and the buildfarm.  Based on the numbers provided, the CI  
takes 30% less time to run the test with this change on Windows (worst  
case shown on the lists).  These tests have been introduced in  
96063e28366b.  
  
Author: Sehrope Sarkuni <sehrope@jackdb.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAH7T-araSEdsNpxiKaMOW8kr_ZHhekCLHx5yzm2ksq4FdgULbA@mail.gmail.com  
Backpatch-through: 17  

commit   : c586a5336a5bd0fef2136424542f4738ae96bf94    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Sep 2026 17:03:27 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Sep 2026 17:03:27 -0700    

While some <refentry> instances of supported PostgreSQL versions use the  
sql-alter-table style, sql-altertable is the dominant style.  Change  
these before they're baked into the doc URLs of a supported version.  
  
Backpatch-through: 19  

commit   : 6dbc931a39976dbbffca99e4e9c77d4d2a8cc240    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Sep 2026 17:03:27 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Sep 2026 17:03:27 -0700    

Backpatch-through: 19  

commit   : 7da24355a2993721bf9bc54224b3bb3e601530ce    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Sep 2026 16:27:18 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Sep 2026 16:27:18 -0500    

After adding pg_stats.tableid, we taught pg_dump to use it in the  
attribute statistics query for servers running v19 or later.  
Notably, we did not give this new form of the query a "redundant  
filter clause" like we did the pre-v19 form.  Testing indicates  
that produces a significant performance regression, and that adding  
a similar filter clause to the v19-or-later form of the query fixes  
it.  
  
Oversight in commit 4b5ba0c4ca.  
  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/apQ9nvLW_zFdarYd%40nathan  
Backpatch-through: 19  

commit   : 1bda0b23bce47ab19d518ba51b26b9caed967782    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Sep 2026 15:20:01 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Sep 2026 15:20:01 -0500    

Sufficiently large settings of the *_freeze_score_weight parameters  
can lower the scaling thresholds below the *_freeze_max_age  
settings.  This can lead the scoring code to raise a value < 1.0 to  
a power > 1.0, thus lowering the score, which is the opposite of  
what is intended.  To fix, only exponentiate the scores when doing  
so won't lower their values.  
  
Oversight in commit d7965d65fc.  
  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/apWcbq91BAfhmsKU%40nathan  
Backpatch-through: 19  

commit   : f26ab219e28ceb88b29f9165800879548dcc6646    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Sep 2026 14:20:16 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Sep 2026 14:20:16 -0500    

The SIMD path for these commands reads ahead into the input buffer  
via CopyLoadInputBuf(), which reports encoding and conversion  
errors.  The problem is that the errant data might lie beyond the  
end-of-copy marker, which we aren't copying and thus needn't error  
for.  To fix, add a "speculative" parameter to CopyLoadInputBuf()  
that defers these errors, and use it in the SIMD path.  The errors  
are instead reported only if we actually reach the errant data.  
Testing indicates this does not meaningfully impact performance.  
  
Oversight in commit e0a3a3fd53.  
  
Reviewed-by: Greg Burd <greg@burd.me>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/apWOr1kgVSqweBnU%40nathan  
Backpatch-through: 19  

commit   : 938f4f8f343415f5ce17d0e3f0736b2c118d422e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Sep 2026 20:45:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Sep 2026 20:45:13 +0200    

We must handle cases where an inserted temporal leftover gets routed to  
a different partition than the original tuple's. This happens if the  
partition key depends on the application-time column used in the FOR  
PORTION OF clause. Everything works for UPDATE, but for DELETE we can  
hit some Asserts, since that operation never needed to be covered  
before. One Assert is for the RETURNING list; the other, for WITH CHECK  
OPTION. This commit updates both to include CMD_DELETE.  
  
Author: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/03276924-6d55-470d-8192-a49c053c940f@eisentraut.org  

commit   : 61e64cb19a08c23dca1df46f1ae09df514059fc6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 1 Sep 2026 10:32:41 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 1 Sep 2026 10:32:41 -0400    

The test expects a 128 kB request to exceed the shared memory available after  
startup.  Huge pages can round up the main shared memory segment enough for  
that request to succeed, defeating the test.  
  
Disable huge pages for the allocation-failure phase so that it exercises the  
intended error path independently of shared memory segment rounding.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/rpkhzrrmo7qiz7rr3qlufksb2oci33wcg3ao75le7dqindgoif@6yozkjwb6bdf  
Backpatch-through: 19  

commit   : ef67d599eff86203371e38f2d08ec6fa6236b5b2    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 1 Sep 2026 10:26:10 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 1 Sep 2026 10:26:10 -0700    

This reverts commit 4966bd3ed95e0d02bf220c4bad2b292963827dd4, which  
introduced the 19beta grease campaign, now that Beta 3 has been stamped.  
(The reservation and documentation for the grease version code, done in  
d8d7c5dc8f, remains.)  
  
Discussion: https://postgr.es/m/CAOYmi%2Bkqt_gn-wvUjJG1j3MM4LDDsRMURSPz2eMxfABu0iGtpw%40mail.gmail.com  
Backpatch-through: 19  

commit   : 1956251afa8bee718a236fcbf31a8f0da46e5055    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Sep 2026 09:51:44 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Sep 2026 09:51:44 -0700    

Out of an abundance of caution.  
  
This reverts commit 5e6e42e44fe10cab616b4fbe9725df03c987c90a.  
  
Requested-by: Daniel Verite <daniel@manitou-mail.org>  
Requested-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260826232534.13.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : f3ac68ffe38692582c24880ef10cc365ec683fa6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2026 12:16:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2026 12:16:45 -0400    

eval_const_expressions() didn't constant-fold XmlExpr.  In some cases  
it cannot, but often it can.  Failure to do so can cause visible  
regressions in SQL-language function behavior compared to pre-v18,  
though only in a rather narrow set of contexts: basically, if you're  
trying to use a CASE to prevent evaluation of a failure-prone XML  
function.  
  
While we're at it, make contain_mutable_functions() handle XmlExpr  
more precisely, and adjust some comments that justify not treating  
XmlExpr explicitly.  
  
This seems worth sneaking into v19, but I'm hesitant to put it into  
v18.  It's not really a bug fix, because we disclaim the safety of  
using CASE this way, and it carries some risk of de-optimizing queries  
that worked satisfactorily before.  
  
Bug: #19487  
Reported-by: Ilya Portnov <i.portnov@compassplus.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19487-367258bc497b923a@postgresql.org  
Backpatch-through: 19  

commit   : a4da80419305797a24da544bb8514b6399ce0b1f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 1 Sep 2026 22:46:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 1 Sep 2026 22:46:10 +0900    

The VALUES reference page said that an AS clause was required when  
VALUES is used in a FROM clause. This was imprecise because AS is  
optional when specifying an alias.  
  
In v14 and v15, a table alias is still required in this case, so state  
that explicitly instead. In v16 and later, commit bcedd8f5fce made table  
aliases for subqueries in FROM clauses optional, so state that the  
table alias is optional there. In all branches, continue to recommend  
explicit column aliases as good practice.  
  
Backpatch to all supported versions.  
  
Author: Ian Barwick <barwick@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAB8KJ=jrvZdNLLhYSiCgbjLTz2LKEjYw+-HVQkaF+kgk61KtHA@mail.gmail.com  
Backpatch-through: 14  

commit   : 135b867a530cac2e3796d87c852b53bef40f0077    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 1 Sep 2026 11:14:25 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 1 Sep 2026 11:14:25 +0200    

The test for disabling data checksums after a failure didn't wait  
for the state transition to complete before testing, which could  
lead to false negatives in testing.  Fix by passing the wait param  
when disabling.  Identified on buildfarm member culicidae.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/b2f34fd3-8e98-450e-9e8c-ac08238e9116@gmail.com  
Backpatch-through: 19  

commit   : 2291b6ffbe2351deaada0f9bf7967c4db21a86e9    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 1 Sep 2026 10:13:30 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 1 Sep 2026 10:13:30 +0200    

A negative n means "return all but the first |n| characters", so  
text_right() negates n before clipping.  Negating PG_INT32_MIN  
overflows; with -fwrapv the result is PG_INT32_MIN again, still  
negative, and pg_mbcharcliplen() then returns an offset of zero,  
so the whole string is returned where the correct answer is an  
empty string:  
  
  SELECT right('abcdef', (-2147483648)::int4); -- 'abcdef', want ''  
  SELECT right('abcdef', -2147483647);         -- '', correct  
  
Clamp to PG_INT32_MAX instead.  Any n whose absolute value is at  
least the string's length skips all of it, and a text value cannot  
be longer than PG_INT32_MAX, so this gives the same answer for every  
other input.  Erroring out, as text_format_string_conversion() does  
for a width of INT_MIN, would not be correct here: unlike a format  
width, an out-of-range skip count has a well-defined result.  
  
Using pg_neg_s32_overflow() would be a slightly more optimal fix but  
as it's only available in PostgreSQL 18 and later the decision was  
taken to apply the same fix to all backbranches.  
  
Backpatch to all supported versions.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAON2xHNnBz-AcPJgDmd5_39+8qR5AUKEZk4X3ZM-0zdsATn8kQ@mail.gmail.com  
Backpatch-through: 14  

commit   : 07df2b253277321d68d515615ec6c0a3d70ec591    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 1 Sep 2026 12:54:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 1 Sep 2026 12:54:31 +0900    

The GRAPH_TABLE examples in ddl.sgml and queries.sgml were written  
as single long lines, making their structure harder to read in the  
generated documentation.  
  
Reformat these examples so that the graph name, MATCH clause, and  
COLUMNS clause appear on separate lines, making them easier to read.  
  
Author: Koshino Taiki <koshino@sraoss.co.jp>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/OS9P286MB64860BD6CD6D4B4B0E1CEDE894A32@OS9P286MB6486.JPNP286.PROD.OUTLOOK.COM  
Backpatch-through: 19  

commit   : 9efc2f9d8964ec927ccdeb4d461ff8070b0e6255    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 1 Sep 2026 11:42:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 1 Sep 2026 11:42:13 +0900    

When to_char() formatted an integer value with a V pattern, it could  
return an incorrect result instead of reporting an overflow. V shifts  
the decimal point by multiplying the input value by a power of ten before  
formatting it, so, for example,  
  
    to_char(3, '9V999999999')  
  
requires computing 3 * 10^9. This result does not fit in int4, but  
the integer variant of to_char() performed the multiplication using a  
plain int32 expression. The intermediate result could therefore  
overflow, causing the function to output incorrect digits instead of  
raising "integer out of range".  
  
Use dtoi4() and int4mul() for this calculation so that both an  
out-of-range multiplier and an out-of-range product are detected, as  
with ordinary integer arithmetic. This also matches the existing int8  
implementation, which uses dtoi8() and int8mul() for the same  
operation.  
  
After this change, to_char() with V format either returns the  
correctly formatted result when the scaled value fits in int4, or  
raises "integer out of range" when it does not.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com  
Backpatch-through: 14  

commit   : ca8d4bdb047f97f00f03915bcd5fcb3d89534027    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Sep 2026 08:12:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Sep 2026 08:12:38 +0900    

Oversight in ce207d2a7901.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CADkLM=eo7MtuCE=YjovW+=ASw1=q39qQ3qarrsw+EKfU901ztA@mail.gmail.com  
Backpatch-through: 18  

commit   : 347486775812573f09c79e1f4d26d1f7506d261f    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 31 Aug 2026 12:34:24 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 31 Aug 2026 12:34:24 -0500    

Oversight in commit 283e823f9d.  
  
Backpatch-through: 19  

commit   : 4186d7169b068a3f248e9795702d41ea9842a954    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 31 Aug 2026 12:07:07 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 31 Aug 2026 12:07:07 -0500    

Oversight in commit 38b602b028.  
  
Backpatch-through: 19  

commit   : 59335b5e71d552229f74ac41f3ef6b5a4d966535    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 30 Aug 2026 09:40:40 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 30 Aug 2026 09:40:40 -0500    

Oversight in commit b45137f315.  
  
Backpatch-through: 19 only  

commit   : efc3db99c41192be5bbce20be2199448ec227572    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 30 Aug 2026 09:13:09 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 30 Aug 2026 09:13:09 -0500    

Oversight in commit a4f126516e.  
  
Backpatch-through: 19  

commit   : 50daffb0665e31ba9e223e3c9106a49f2c44eab5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Aug 2026 19:56:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Aug 2026 19:56:49 -0400    

The compound flags collected from COMPOUNDFLAG and friends are stored in  
either the string or the integer member of a union, according to the  
flag mode that the affix file's FLAG line declares.  NIImportOOAffixes()  
converted each flag as soon as it read it, using the mode in effect at  
that point, and recorded that mode in the entry.  Since FLAG may appear  
anywhere in the file, including after the compound flags, entries written  
before and after it could disagree about which member of the union holds  
the flag.  
  
In assert-enabled builds, this would result in an assertion failure.  
Otherwise, cmpcmdflag() takes the mode from its first argument and  
applies it to both, so it can read an integer as a char pointer and pass  
that to strcmp().  Depending on which way the mismatch goes, the result  
is a segfault while sorting the array, a segfault in the bsearch() that  
later looks flags up (the lookup key is built with the final mode, so  
this happens even when the array itself is consistent), or, when both  
members happen to be readable, no crash at all and a compound flag that  
is never found, which silently disables compound word splitting.  This  
isn't a security bug because we consider dictionary files to be trusted  
data, but it's still worth fixing.  (In practice, dictionary files  
usually put the FLAG line first, which is why this went unreported for  
so long.)  
  
Fix by keeping the flags as strings while the file is read and converting  
them once it has been read in full, when the mode is final.  This also  
makes the position of the FLAG line irrelevant, which is how the flags on  
AF, SFX and PFX lines are already treated: those are parsed in a second  
pass and so always use the final mode.  That precedent is reason for  
behaving this way rather than throwing an error.  
  
The old ispell file format reaches addCompoundAffixFlagValue() too,  
from NIImportAffixes(), and returns without entering NIImportOOAffixes(),  
so it needs the conversion step as well.  
  
While we're here, also fix some integer width mismatches: store the  
result of strtol() into a "long", and cast to int only after we've done  
range checks.  Typically a value too wide for int would fail the range  
checks anyway, but in some cases it would be silently accepted after  
truncation to int.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAON2xHN3QmsaySM6DGWa1gttcbJoFh0wjAE-_ZpSPo=LKN1hYw@mail.gmail.com  
Backpatch-through: 14  

commit   : f23de46e15ba3faf38a97915df29ae98a472a16b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 29 Aug 2026 10:23:23 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 29 Aug 2026 10:23:23 -0500    

The REPACK grammar accepts ONLY before the table name and * after  
the table name, but that's neither documented nor handled in the  
code.  Perhaps REPACK should support that syntax, but for now let's  
just bring it in line with its documentation.  
  
Oversight in commit ac58465e06.  
  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/apBTsWGwkLXVh8Ow%40nathan  
Backpatch-through: 19  

commit   : 4af0528a0e49d06b997c443b044cb013503e1546    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 28 Aug 2026 23:24:47 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 28 Aug 2026 23:24:47 +0200    

AutoVacuumUpdateCostLimit() runs after each nap in vacuum_delay_point()  
and follows av_nworkersForBalance, but the new limit never reached the  
shared cost params in the vacuum DSM: propagation only required config  
reload.  Parallel workers computed their delays from the stale limit,  
so a parallel autovacuum could run at up to twice the configured budget  
(or half of it) until the next SIGHUP, contradicting the propagation  
promise in maintenance.sgml.  
  
Call parallel_vacuum_propagate_shared_delay_params() after rebalancing.  
Gated on the leader: parallel workers take the same nap path and must  
not overwrite the shared parameters.  
  
This also adds a test to validate the behaviour: pause the leader at the  
existing injection point, start a second autovacuum worker and hold it at  
a new injection point placed after it joined the balance, then check the  
first parameter load of the parallel workers reports the balanced limit.  
The hold is needed because a second worker left running can finish its own  
vacuum before the leader resumes, which puts the balance back where it  
started.  Autovacuum is disabled for everything but the two test tables  
via thresholds, as a worker spawned by catalog churn would get trapped at  
the hold point and starve the test of its second worker slot.  
  
Backpatch to v19 where autovacuum gained the ability to use parallel  
vacuum workers.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAN4CZFOZtEPwGQ6oa9LvHvN522zEp8h_dW9hHExSh7pVXofoKQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 7ddb9c41a13534011bb64a856fb5a60e41b82b75    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 28 Aug 2026 15:11:06 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 28 Aug 2026 15:11:06 -0500    

In v19, pg_stat_autovacuum_scores computes a TOAST table's scores  
from its own storage parameters alone.  On the other hand,  
autovacuum falls back to the main table's parameters when the TOAST  
table has none.  This means that the view may report scores that  
don't match what autovacuum would calculate.  This contradicts the  
documented promise that the view generates its results the same way  
autovacuum workers do.  To fix, teach the view to do the same  
fallback.  As in do_autovacuum(), we must make a preliminary pass  
over pg_class to collect the main tables' parameters, since the  
pg_class scan may see TOAST tables before their main tables.  
  
Commit fad70a09ff for v20 improved autovacuum's handling of TOAST  
storage parameters and adjusted the view to match, but it was  
deemed too intrusive to back-patch.  This fix is for v19 only.  
  
Oversight in commit 87f61f0c82.  
  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoB1CJRVfCDh8qYuD3eueiygXxk7F3nybgjN0RZXSD-QUw%40mail.gmail.com  
Backpatch-through: 19 only  

commit   : 0ab90a5c94188ab0a2113e36c73f093f741129c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Aug 2026 15:12:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Aug 2026 15:12:26 -0400    

analyzejoins.c decided which joins could be dropped by consulting the  
planner's derived data structures, but then implemented the removal  
by updating those structures in-place.  That is a lot of fiddly work,  
and nothing keeps it in step with the rest of the planner:  
remove_leftjoinrel_from_query only bothered to update "parts of the  
planner's data structures that will actually be consulted later", with  
no good way to know what those are.  Bug #19560 is one consequence.  
In that report, removing a join leaves an EquivalenceClass that now  
gives rise to a base restriction clause, but base restriction clauses  
have already been generated and nothing reconsiders them, so the WHERE  
condition disappears from the plan and we return wrong answers.  
  
The self-join elimination code has the same design and the same type  
of hazard.  We have seen many related bugs over the years too, so it's  
time to do something drastic.  
  
To fix, do the removals by editing root->parse->jointree (which is a  
far simpler and more stable representation than the derived data),  
and then have query_planner() discard everything it computed from the  
jointree and derive it over again.  This requires quite a bit less  
code, and doesn't require touching analyzejoins.c every time we change  
the data derived by query_planner().  For typical cases it can actually  
save a bit of planning time, though in cases where we have to iterate  
the derivation loop many times it does add some time.  
  
reduce_unique_semijoins() gets the same treatment: rather than deleting  
the semijoin's SpecialJoinInfo and relying on the jointree not being  
consulted again, it now changes the JoinExpr's jointype to JOIN_INNER  
and recalculates everything.  
  
Some plans change in the join regression test.  Qual evaluation order  
shifts in a few cases, because the conditions now reach later planning  
in jointree order rather than in whatever order the removal code  
re-distributed them.  A few plans improve, since the rebuilt relation  
targetlists no longer carry columns that only a removed join needed.  
We also detect a constant-false filter condition whose test used to  
carry a FIXME label.  One plan gets marginally worse, because the old  
code recomputed attr_needed from equivalence classes after a join  
removal; that is more accurate than what deconstruct_jointree()  
derives from the original clauses, but we no longer do that.  Making  
that recomputation happen anyway could be worth doing, but it should  
be considered independently and perhaps implemented differently.  
  
Back-patch to v16, on the grounds that the introduction of  
varnullingrels in v16 made the old approach significantly more complex  
and bug-prone; notably, bug #19560 does not manifest before v16.  
In released branches, do not remove externally-visible fixup  
functions such as remove_join_clause_from_rels, in case any  
extensions are relying on them; but they're no longer used by core  
code.  But we must nonetheless break API/ABI for remove_useless_joins,  
reduce_unique_semijoins, and remove_useless_self_joins, as those now  
have different outputs and very different behavior than before.  
It seems unlikely that any extensions are calling those; but just in  
case, make the breakage more obvious by renaming remove_useless_joins  
to remove_useless_outer_joins, which is a more sensible name for it  
anyway since the addition of remove_useless_self_joins.  
  
Full disclosure: initial drafts of this patch were made with  
Claude Opus 4.8.  
  
Bug: #19560  
Reported-by: Orestis Markou <orestis@orestis.gr>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Thom Brown <thom@linux.com>  
Reviewed-by: Jacob Brazeal <jacob.brazeal@gmail.com>  
Discussion: https://postgr.es/m/1186816.1784573544@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 9d888cd3f34c4e9a8f7fbe7e78c70bbd84a481de    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 28 Aug 2026 17:49:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 28 Aug 2026 17:49:38 +0300    

If SHMEM_CALLBACKS_ALLOW_AFTER_STARTUP is used to allocate shared  
memory after startup, but the initialization fails half-way through,  
the shmem area is left in an indeterminate state.  Furthermore, if  
multiple shmem areas are registered in one RegisterShmemCallbacks()  
call, some might be allocated while others are not.  
  
This commit adds an explicit 'initialized' flag to each shmem area.  
We still leave behind an uninitialized area on error, but at least  
they are now clearly marked, and you get a slightly nicer error  
message if you try to re-register them.  It'd be nice to clean up more  
thoroughly and support actually retrying the allocations, but in  
practice, the most likely reason for a shmem allocation or  
initialization to fail is that you are out of shared memory and  
retrying wouldn't help with that.  
  
This isn't exactly a new problem, the old ShmemInitStruct() interface  
had similar issues if the initialization code failed, or if you  
allocated multiple structs and some allocations failed.  It was just  
left to the calling code to deal with it.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAJTYsWVRRWH48=PcuAo_2Y4Ap6M0QRmzxgUfFkNRtdWK74LjBQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 92d44b200e12c7ecbaee57d37fcd5e8803811358    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 28 Aug 2026 17:48:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 28 Aug 2026 17:48:46 +0300    

RegisterShmemCallbacks() left the backend in a bad state, if an error  
occurred in the callbacks or if an allocation failed.  Firstly,  
'shmem_request_state' was left in wrong state, causing a subsequent  
call to RegisterShmemCallbacks() to wrongly take the postmaster  
startup codepath or assertion failures in some other functions.  
Secondly, the 'pending_shmem_requests' list was not properly cleaned  
up, causing a subsequent RegisterShmemCallbacks() to try to process  
the stale, already-freed requests.  
  
To fix, add a PG_TRY() block to clean those things up on error.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAJTYsWVRRWH48=PcuAo_2Y4Ap6M0QRmzxgUfFkNRtdWK74LjBQ@mail.gmail.com  
Backpatch-through: 19  

commit   : da8da39102788aabe2d479354cb146651825b094    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 28 Aug 2026 10:04:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 28 Aug 2026 10:04:58 -0400    

Reported-by: Masahiko Sawada  
  
Author: Masahiko Sawada  
  
Discussion: https://postgr.es/m/CAD21AoC1dJGqngg_cdT_ayQjOdw6gmSBfVOTtAWOq-5C+XeLZQ@mail.gmail.com  
  
Backpatch-through: 19 only  

commit   : 5523e4d9add7379398b5a998b83ddce3f64d72a4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 Aug 2026 09:36:13 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 Aug 2026 09:36:13 -0400    

collate.linux.utf8 skips itself unless version() matches "linux-gnu",  
and infinite_recurse skips itself when version() matches  
"powerpc64[^,]*-linux-gnu".  configure substitutes the GNU host triplet  
into that string, but the meson build composes it from  
host_machine.cpu_family() and host_system, which never carries the ABI  
suffix.  So ever since meson support arrived in 16, collate.linux.utf8  
has not run at all on a meson build, and infinite_recurse has been  
running on ppc64 Linux the very case it means to stay away from.  
Meson documentation says it reports 'ppc64' instead of 'powerpc64'.  
  
Fix by matching "-linux[-,]" and "p(ower)?pc64[^,]*-linux", which match  
all spellings.  Keeping the punctuation on either side confines the  
match to the platform field.  Neither pattern excludes musl, but  
collate.linux.utf8's other conditions already require a set of glibc  
locales to be present.  
  
Backpatch to 16, where the meson build was introduced.  
  
Discussion: https://postgr.es/m/a40b19da-9a02-47b4-8afd-2bbbde8db1e8@dunslane.net  
  
Reviewed-By: Jonathan Gonzalez V. <jonathan@abdiel.eu>  
Reviewed-By: Nazir Bilal Yavuz <byavuz81@gmail.com>  

commit   : 15ccc2041ee864cccc8b72de4a1f21e9b51ccc47    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Fri, 28 Aug 2026 14:51:36 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Fri, 28 Aug 2026 14:51:36 +0900    

create_append_path() skips cost_append() when an Append has exactly  
one child whose parallel awareness matches its own, since setrefs.c  
strips such an Append out entirely.  In that case it copies the  
child's rowcount and costs directly, but it failed to copy  
disabled_nodes.  An Append over a disabled child therefore claimed to  
contain no disabled nodes, letting a disabled path win over one that  
is not disabled.  
  
This is a regression in v18; before e22253467, disable_cost was folded  
into a path's startup and total costs, so it rode along in the fields  
this shortcut already copies.  
  
Back-patch to v18.  This can change plans in stable branches, but only  
for installations that have explicitly disabled a node type, and only  
to stop using the node they asked us to avoid.  
  
Reported-by: Man Zeng <zengman@halodbtech.com>  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAHewXNm_Zx5EDoaD7wo7bq6cfRroNznS+RBCzT_p2-CWQXpgSw@mail.gmail.com  
Backpatch-through: 18  

commit   : 7a74e5ed92d4e36f5b8da3db66457d6f32cf80f3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 28 Aug 2026 13:10:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 28 Aug 2026 13:10:56 +1200    

When performing partition pruning with a RANGE partitioned table where  
the pruning quals are only present for a leading prefix of the partition  
key, it was possible that partition pruning would accidentally prune away  
some partitions which shouldn't be pruned and include some partitions that  
were not needed.  
  
This happened due to an incorrectly coded loop bound which was  
terminating the loop when the bound reached the first or last element in  
the partition bound array.  This resulted in those end elements not being  
checked in cases where they should be checked.  It appears that it might  
have been coded this way to avoid stepping off the array, but that was  
done incorrectly as it failed to take into account the direction of travel  
through the array (the loop can go forwards or backwards).  I.e., it's  
valid to loop when 'off' is the last element if we're going backwards  
through the array, and valid to loop if 'off' is 0 and we're looping  
forward through the array, but the code as it was didn't allow that.  
  
Here we fix this by moving the loop condition check to after we've  
calculated the array element to process, and break from the loop if that  
element is beyond either end of the array.  
  
Example of accidentally pruned partition:  
  
p: partition by range (a, b);  
p1: for values from (1, 4) to (1, 7);  
p2: for values from (1, 7) to (3, 8);  
p3: for values from (4, 8) to (6, 9);  
def: default;  
  
select * from p where a <= 1;  
  
Here p2 was pruned by mistake.  
  
Example of accidentally not pruning a partition:  
  
p: partition by range (a, b);  
p1: for values from (7, 2) to (7, 7);  
def: default;  
  
select * from p where a > 7;  
  
No partitions would be pruned in this case, despite it being impossible  
for matching rows to exist in p1.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAApHDvp5ne9AWaH-tG1Lke-USLz3NwWLWTUdP5NT7ypKtcFqcg@mail.gmail.com  
Backpatch-through: 14  

commit   : 3fcb7167198e1b2ecf8cc0d934c8ffe53755e0ae    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 27 Aug 2026 12:25:04 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 27 Aug 2026 12:25:04 -0700    

Commit bd8d9c9bdfa widened MultiXactOffset to 64 bits, but  
pg_control_checkpoint() still handle checkPointCopy.nextMultiOffset as  
xid type and declared next_multi_offset column as xid. Since xid is 32  
bits wide, an offset above 2^32 was reported truncated, while  
pg_controldata printed the full value of the same field.  
  
This commit reports the column as bigint instead. That matches  
pg_get_multixact_stats(), which already reports num_members and  
members_size, both derived from these same offsets, as int8.  
  
Backpatch to v19, where MultiXactOffset was widened.  
  
Bump catalog version.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoCvzerscfU8o4ARQ793yAGHpQ72r2x5apeC_W2-k=SLCQ@mail.gmail.com  
Backpatch-through: 19  

commit   : e721ce48dc78b58827c35d6a13f9f72a591e68f2    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 27 Aug 2026 12:10:49 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 27 Aug 2026 12:10:49 -0700    

Commit bd8d9c9bdfa widened MultiXactOffset to 64 bits and widened  
ControlData.chkpnt_nxtmxoff accordingly, but get_control_data() still  
read the "Latest checkpoint's NextMultiOffset" line with str2uint(),  
which returns unsigned int.  
  
This commit adds str2uint64(), mirroring the str2uint() helper used  
for the other control file fields, and reads the offset with it.  
  
Backpatch to v19, where MultiXactOffset was widened.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoCvzerscfU8o4ARQ793yAGHpQ72r2x5apeC_W2-k=SLCQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 400c810ddbd7890f751913977e4442d71a0ebfc4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Aug 2026 14:14:15 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Aug 2026 14:14:15 -0400    

FOREIGN_JOIN target sublists must contain at least two relation  
identifiers.  However, the parser checked only for sublists with  
exactly one identifier, so FOREIGN_JOIN(()) was accepted.  
  
Reject sublists with fewer than two relation identifiers, and add  
regression coverage.  
  
Author: Chao Li <lic@highgo.com>  
Discussion: http://postgr.es/m/BEDC04E0-6732-4310-95BA-6EC34BC1442C@gmail.com  

commit   : 764d31b8ae360685b06913c7c6195ec1bfefcd33    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Aug 2026 01:15:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Aug 2026 01:15:23 +0900    

Previously, when wal_receiver_create_temp_slot was enabled, a timeline  
switch could cause the walreceiver to try to create the same temporary  
replication slot again on the same connection. The slot had already been  
created before the first streaming attempt and still existed, so the  
second creation attempt failed with a FATAL error such as  
"could not create replication slot ...".  
  
The walreceiver would later be restarted and streaming replication could  
continue, so this did not permanently break replication. Nevertheless,  
the unexpected failure is a bug and should be fixed.  
  
Fix this by tracking whether the temporary replication slot has already  
been created for the lifetime of the walreceiver and skipping subsequent  
creation attempts. Also copy the retained slot name to shared memory on  
each streaming attempt, since RequestXLogStreaming() clears it when  
streaming is restarted without a configured primary slot. This also  
keeps pg_stat_wal_receiver.slot_name populated after timeline switches.  
  
Backpatch to all supported versions.  
  
Author: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: Quan Zongliang <quanzongliang@yeah.net>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/tencent_628FDAF814231923BC8E8357BBBC50F94207@qq.com  
Backpatch-through: 14  

commit   : d225057849e2d4e013f1cd828f04084d004feb8f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 27 Aug 2026 23:51:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 27 Aug 2026 23:51:21 +0900    

The test assumed that advancing WAL would lead to a checkpoint that  
invalidates the obsolete replication slot.  If a checkpoint that started  
before the WAL switch completes first, the following checkpoint can be  
skipped as idle, so the expected walsender termination is not logged.  
  
Force a CHECKPOINT in a background psql session after advancing WAL, so  
the slot invalidation is exercised deterministically.  
  
This has been observed on buildfarm members alligator and partridge:  
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2024-12-13%2001%3A24%3A58  
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-08-06%2018%3A00%3A11  
  
Backpatch to all supported versions.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/0b07ead5-a5da-445e-9698-a7d340708bdf@gmail.com  
Backpatch-through: 14  

commit   : 4c5291435d40a0cf02b131b680a71e42243fcd04    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 27 Aug 2026 23:40:20 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 27 Aug 2026 23:40:20 +0900    

The pg_restore_*_stats() functions could report SQLSTATE XX000 for  
invalid variadic arguments, such as an unmatched name/value pair, a NULL  
argument name, or a non-text argument name. Attribute and extended  
statistics restores could also report XX000 when the supplied statistics  
exceed the number of slots PostgreSQL can store.  
  
These are not internal errors. They result from invalid caller input or  
a PostgreSQL implementation limit, but the lack of specific SQLSTATEs  
made clients treat them as internal errors.  
  
Assign appropriate SQLSTATEs to these errors so that applications and  
tests can classify them correctly.  
  
Backpatch to v19, but no further; changing ERRCODE assignments in  
released stable branches doesn't seem like a good idea.  
  
Bug: #19629  
Reported-by: Zheng Wang <hackerzheng666@gmail.com>  
Reported-by: Yanjie Zhao  
Reported-by: Yiyang Liu  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19629-76babc04b683594d@postgresql.org  
Backpatch-through: 19  

commit   : ba12a202ce1b5581dc0ed149cf3f637d7897ad5d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 27 Aug 2026 14:31:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 27 Aug 2026 14:31:44 +0300    

Refactor the checks in the function to move all the conditions for  
when to attempt creating a shell type into one place.  Add a check for  
the array syntax.  
  
In addition to rejecting array syntax, another user-visible effect is  
that the error message is now different if the type specified a  
typmod.  You now get "type does not exist" instead of the more  
specific "type modifier cannot be specified for shell type".  That  
seems better; the implicit shell type creation exists only for  
backwards compatibility, and it never worked with type modifiers, so  
if there's a type modifier it's most likely not because the user tried  
to create a shell type,  
  
Add test for the array syntax, the type modifier, and some other cases  
for which we don't create shell types.  
  
Discussion: https://www.postgresql.org/message-id/de673feb-41b4-4685-b24b-6408b95e58ab@iki.fi  
Backpatch-through: 14  

commit   : 63f8e9773aadba37661f70629a0a0e8f5933afc8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Aug 2026 11:32:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Aug 2026 11:32:55 +0200    

stringify_grant_objtype() treated OBJECT_PROPGRAPH as unused, so  
pg_event_trigger_ddl_commands() failed with "unsupported object type"  
when a ddl_command_end trigger inspected GRANT/REVOKE on a property  
graph.  Return "PROPERTY GRAPH" like the GRANT command syntax.  
  
Bug: #19637  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/19637-4446f72945492ed8%40postgresql.org  

commit   : 58af2138740b3da0c866f1e20045c43bb7bacc0b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Aug 2026 10:42:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Aug 2026 10:42:14 +0200    

Inferred property graph keys used all attributes stored in the primary  
key index, causing non-key INCLUDE columns to become part of the graph  
key. Use only the index's key attributes.  
  
Author: Muhammad Taha Naveed <m.taha.naveed27@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAPTqav%2BVUjYgm1jZy0Scy%3D1-PfdgznVj2%3DPwH8disiXF76HEow%40mail.gmail.com  

commit   : 3e8bcc8644feaa9ca1cc954197b6994817af4290    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 27 Aug 2026 00:56:41 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 27 Aug 2026 00:56:41 +0300    

This commit reverts f2e4cc4279 and 4b3d173629, and the subsequent fixes and  
improvements c5ae07a90a, 713e553e32, 52e629be95, ecb2508aaf, 9354896920,  
971017c495, 83df16f1fa, e64a9ba2b4, ff8bec8c46, cdae794af3, 57f19774d6, and  
881033ae8b.  d8af730100 and 0392fb900e cancelled each other out and are not  
reverted separately.  
  
The feature is reverted due to multiple design issues which are too late to  
address in this release cycle.  
  
Discussion: https://postgr.es/m/CAN4CZFNCU%3Dt09M%3D%2Br2t9hHLJuujdM4oQ8hCK_Sx-GpfiwMAicw%40mail.gmail.com  

commit   : 3c73b272b42ecad68ad5c970bfd62d714ae03828    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 Aug 2026 10:05:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 Aug 2026 10:05:51 +0530    

For a REPLICA IDENTITY FULL remote relation whose local counterpart has  
no primary key or replica identity, FindUsableIndexForReplicaIdentityFull()  
chooses the first index of a suitable shape from RelationGetIndexList().  
That list excludes only indexes that are not indislive, so an invalid  
index left behind by a failed CREATE INDEX CONCURRENTLY can be selected.  
  
Such an index need not contain every row. Consequently, changes for rows  
that it fails to find can be silently dropped as missing-tuple conflicts.  
If the index contains no rows at all, the scan can instead error out and  
cause the apply worker to exit.  
  
Skip invalid indexes, as the planner does.  
  
Author: Mikhail Nikalayeu <mihailnikalayeu@gmail.com>  
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Ajin Cherian <itsajin@gmail.com>  
Discussion: https://postgr.es/m/CADzfLwWuubcbJBDRZ_J1SSqHDNjNmUYSAgf5y=17LxmP401xbw@mail.gmail.com  
Backpatch-through: 16, where it was introduced  

commit   : 073bd832772fa9ee2460d8420d2275687fbe88bc    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 22 Aug 2026 17:47:24 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 22 Aug 2026 17:47:24 -0400    

test_regex_utf8 decides whether to run by looking at the database  
encoding alone, but two of its cases, [[:graph:]] and [[:print:]] over  
E'xᔀሷ', depend on the ctype as well.  In a database with encoding  
UTF8 and locale C they match just the x, because isgraph() and isprint()  
are false for anything outside ASCII, and the file fails.  
  
No buildfarm animal builds such a cluster, which is why this went  
unnoticed, and why the to_date() crash in 18.5 went undetected for want  
of exactly this coverage.  A pending buildfarm client change will let an  
animal be configured that way.  
  
Fix by giving the two cases an explicit collation, so that they exercise  
a fixed Unicode ctype instead of whatever the database happened to be  
initialized with.  test_regex() already passes its input collation down  
to the regex compiler.  The expected results are unchanged; only the  
echoed queries differ.  
  
Backpatch-through: 17 (15 and 16 get a different fix)  
  
Reviewed-by: Jonathan Gonzalez V. <jonathan@abdiel.eu>  

commit   : ef89c839cdc8398095be0d24e65a688115e38b72    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Aug 2026 15:38:15 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 26 Aug 2026 15:38:15 -0400