PostgreSQL 15.20 commit log

commit   : 6a84c5137e820f46f0123276f546eec5b9a56e70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 15:14:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 15:14:54 -0500    

commit   : 588ac6507696303da5ca645460ebcd7b11659a82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 12:43:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 12:43:05 -0500    

Security: CVE-2026-6460 and many more.  

commit   : 7875e1ec6c96f92cb13d2816a24be85fe32dd421    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 11:45:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 11:45:01 -0500    

Security: CVE-2026-6460  
Backpatch-through: 14-18  

commit   : 6d8d8438b893661c312b4ea6049fda11aeb447cd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    

TimescaleDB crashes if an attribute option is present during chunk  
creation as part of a DDL command, due to calling AlterTableInternal()  
without having set up event trigger state.  With the introduction of  
attribute versioning, which stores the version in an internal attribute  
option in the back-branches, attribute options are much more common.  
  
The breakage is easy enough to work around, so do that.  
  
This will only be applied to release branches, as this is clearly a bug  
in TimescaleDB.  
  
Security: CVE-2026-6460  
Backpatch-through: 14-19  

commit   : 825e1bd41df633995098818d11b0189f79139a8e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    

The previously added attribute versioning checks prevent cases of  
deforming a datum tuple with an incompatible tuple descriptor for the  
same type.  However, we have a number of cases where we deform a datum  
tuple with a descriptor for a different relation. The additional checks  
introduces here add verification for such cases, by checking that the  
tuple descriptors are compatible.  
  
The following cases are now checked during deforming:  
  
- Deforming a versioned tuple with a RECORDOID tupledesc  
  
  This can happen with triggers and EvalPlanQual rechecks of function  
  scans.  
  
- Deforming a versioned tuple with a tupledesc for another relation  
  
  This happens a bunch for partitioned tables.  
  
Additionally, when changing the type of a tuple, the old and new types  
are compared for compatibility. This currently happens in:  
  
- heap_copy_tuple_as_datum() and via that in places like  
  ExecEvalConvertRowtype(), ExecFetchSlotHeapTupleDatum(), ...  
  
- plpgsql's coerce_function_result_tuple()  
  
In a perfect world these extra checks would not be needed. But...  
  
It is perhaps worth noting that this knowingly emits error messages in  
an untranslatable way. That was considered acceptable for now, these  
error checks should not normally be hit.  
  
Note that these checks do add nontrivial overhead. This is ameliorated  
by the fact that the common ways to reach the checks are part of already  
expensive operations (like trigger invocations during DML into a  
partitioned table), which are expensive enough to make the added  
overhead comparatively small.  
  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 434594e74cdfdcb97560f12163ae6090a2f0e408    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    

Some of these were originally written with AI contributions, but they  
have been heavily rewritten since.  
  
The most important thing this tests is pg_upgrade's handling of  
attribute versions, including verification of composite columns staying  
properly readable across upgrades.  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : c23382f0a81195537fceeae974ed0fd0b1bdfe88    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    

Using a tuple descriptor that does not match the "shape" of a composite  
datum can lead to crashes, spurious errors and can be used for exploits.  
While postgres has code that prevents such mismatches, there are a  
number of weaknesses in those protections that are nontrivial to fix,  
particularly in the back-branches.  
  
This commit introduces a new safety layer to prevent the worst of the  
negative consequences. From now on, composite datums are marked as such  
and named composite datums are versioned, allowing detection of  
mismatches between a tuple descriptor and the composite during  
deforming. In case of mismatches, errors are raised.  
  
For details about how this works, see  
src/backend/catalog/README.attver.md.  
  
Note that, over time, we should prevent most of the things that the  
safety layer detects at a higher level.  
  
This fixes a number of security relevant composite type confusions.  
  
This is a significant piece of infrastructure grafted onto the existing  
code, in a back-patchable way.  There unfortunately still are some  
compatibility issues due to this commit:  
  
- To get the full protection, extensions need to be rebuilt, due to  
  DatumGetHeapTupleHeader() not being a macro anymore (but an  
  out-of-line function). That also means that some extensions built  
  against a minor version with this change will fail with a linker  
  failure when loaded in an earlier minor version.  
  
  Extensions that have not been recompiled can observe  
  HeapTupleHeaderGetTypMod() returning parts of the version instead of  
  -1.  
  
- Upgrading to a minor version with this fix, performing DDL,  
  downgrading and then upgrading again can cause errors for composite  
  datums formed while downgraded; DDL while downgraded can additionally  
  break the version invariants.  
  
- Code looking at pg_attribute.attoptions will see the new pg_attver  
  key, which could lead to external applications setting this new key  
  via DDL.  
  
  To reduce the impact of that, ALTER COLUMN ... SET (pg_attver = ...)  
  is ignored.  
  
- Dumps of a server with this change, made by a pg_dump without it,  
  contain ALTER COLUMN ... SET (pg_attver = ...), which servers without  
  this change reject.  As pg_upgrade uses the target's pg_dump,  
  upgrading from a minor version with this change to a minor version of  
  a later major version without it fails.  
  
- Use of TupleDescCopy() is forbidden with tupledescs for named  
  composites. The new TupleDescCopySize()/TupleDescCopySized() can copy  
  any descriptor, and verify that the destination is large enough.  
  
- Code that forms datums and then modifies fields in t_choice.t_datum  
  without removing HEAP_IS_DATUM can trigger spurious errors. To reduce  
  the impact of that, the version check skips some known cases of such  
  modifications (see list below for the known effects on extensions).  
  
- DatumGetHeapTupleHeader() will be slower when pre-upgrade tuples are  
  passed, due to copying those datums before modifying them.  
  
- Tuples returned by heap_form_tuple() are now marked as datum tuples  
  and, for named composites, version-checked when deformed. Code that  
  writes such tuples to its own storage needs to clear the marking (via  
  HeapTupleHeaderClearDatum()).  
  
- heap_modify_tuple() used to copy t_ctid, which is not possible  
  anymore, due to that containing the datum version. No callers could be  
  found that need the copy.  
  
At least some of the above should be mentioned in the release notes.  
  
Investigation via github codesearch, a dump of all the extensions on  
pgxn, extensions from various distributions, etc, suggests the following  
effects on extensions:  
  
- PostGIS does some quite broken things on the upgrade from < 3.6 to  
  3.6, including corrupting the catalog. This is more noticeable with  
  these changes. In particular WARNINGs will be emitted and pg_upgrade  
  will fail, until PostGIS is fixed.  
  
  See https://trac.osgeo.org/postgis/ticket/6142  
  
- PL/R (trigger arguments), pg_variables (stored records) and pljs copy  
  tuples and set the composite datum header fields by hand, which leads  
  to spurious errors when the result is read.  They should use  
  heap_copy_tuple_as_datum() instead.  
  
- ddlx fails for columns with an explicitly set attribute option, as it  
  expects at most one option per column.  pgcontext refuses to convert  
  versioned columns, as it rejects columns with any attribute options.  
  
- firebird_fdw spuriously errors out in some cases, due to overwriting  
  the xmax (but not xmin). Other FDWs clear out xmin, which this commit  
  uses as a signal that the version information is not usable, but  
  there's no easy way to detect this in the firebird_fdw case. The fix  
  would be a one-liner.  
  
- storage_engine's rowcompress table AM stores composite datum-style  
  tuples, which will raise errors on read if the table schema is  
  subsequently changed. The fix is trivial.  
  
- pgrx-based extensions will not be protected, even after recompiling,  
  due to pgrx copying postgres code like heap_getattr(). pgrx will need  
  to update that copied code.  
  
- pg_strom's arrow FDW bypasses core functionality for more than 100  
  columns and inserts attributes itself. That does not set the attribute  
  versions correctly and thus will trigger spurious errors if composites  
  of that FDW are used.  
  
- timescaledb has a bug causing crashes during chunk creation as part of  
  DDL commands if attribute options are present. With this change every  
  new / altered attribute has an attribute option.  
  
  A later commit will work around these crashes.  
  
- Citus' distributed aggregation path theoretically can hit the new  
  error in TupleDescCopy(). However, it looks like Citus' planner does  
  not ever generate such plans - but the ERROR can be reached by a user  
  issuing a query with calls to the relevant internal Citus functions.  
  
  The fix again is trivial, should it be needed (use  
  CreateTupleDescCopy() instead of open-coding it).  
  
The new composite_type_mismatch developer option allows superusers to  
turn the version mismatch error into a warning, or to disable the check.  
Both settings are unsafe.  
  
With this infrastructure in place, additional checks can be  
performed (e.g. in heap_datum_check(), heap_datum_update_type()), at the  
cost of some complexity and runtime overhead.  A subsequent commit adds  
those.  
  
Reported-by: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Reported-by: Andres Freund <andres@anarazel.de>  
Reported-by: Andrew Gierth <andrew@tao11.riddles.org.uk>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reported-by: Francesco Verardi <frevadiscor89@gmail.com>  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Reported-by: Tomer Fichman <tomer@irregular.com>  
Reported-by: OpenAI Security Research Team  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Mehmet Ince @mdisec <mehmet@mehmetince.net>  
Reported-by: Bryan Green <dbryan.green@gmail.com>  
Reported-by: Sumedh Pathak <sumedhpathak@microsoft.com>  
Reported-by: Nicholas Carlini <npc@anthropic.com>  
Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru>  
Reported-by: Yuxiao Guo <dllggyx@outlook.com>  
Reported-by: Nikhil Sontakke <nikhil@planetscale.com>  
Reported-by: Stephan Lipp <Stephan@Adalogics.com>  
Reported-by: Daniel Bakker <daniel@jackds.nl>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com> (parts)  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 3964f037d2008420286aa799b5021d3286723f29    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:58 -0800    

Only make_expanded_record_from_datum() deferred tuple descriptor lookup,  
and it has no direct/indirect users in core nor in known open source  
extensions (checked via pgxn and github).  The other ERH constructors  
already acquire a descriptor eagerly.  
  
The main reason for this change is that subsequent commits are  
simplified by it.  
  
This also allows implementing the datum constructor using  
make_expanded_record_from_typeid(), removing a good bit of duplicated  
code.  
  
This preserves ABI compatibility, to allow for backpatching.  
  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 17a138be4763c82d42e1ff3b3fe55a57e06e58e7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Otherwise we can assign tuples not matching the target tupledescriptor,  
e.g. because one of the tuple descriptors has been acquired before/after  
some DDL.  
  
It may seem tempting to just not enter the surrounding "if" if the  
er_tupdesc_id doesn't match (in fact both Heikki and I (Andres) were  
previously tempted), but the fieldwise-assignment path differs  
behaviorally, due to not copying the ctid along. As the tupdesc_id can  
increment due to invalidation processing, that would lead to  
unpredictable behavior.  Tests were added in previous commits that would  
show that behavior.  
  
Note that there are some cases where this will cause failures that are  
not required for correctness, when assigning a variable of a changed  
type to a previously used variable. It'd add more complexity to make  
that work; for a bugfix this seems good enough.  
  
As also noted in a comment, this perhaps should be done in the expanded  
record layer. But that'd require a few more changes and would make it  
harder to emit a somewhat understandable error message.  
  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : d9373e99251775927b9865c07bc1fe3adfe11b0e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Most of these show the problem by displaying 'FIXME' in test output in  
case of problems, for more details about that aspect see  
rowtypes_alter.sql.  
  
A large percentage of these tests were converted from a larger set of  
tests that were not mergeable in their former shape.  
  
Author: Andres Freund <andres@anarazel.de>  
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> (in different form)  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 5ce00ae09d4b892addcc151bdbe5fcecc56088dd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

An upcoming fix touches related code. It turns out there were a number  
of cases there were not or only incidentally tested. In particular, we  
didn't leave tables with combinations of dropped columns to be tested by  
002_pg_upgrade.pl  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 237847ddc91270e7e10b10ed9b6ba6ae3e8bcc10    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

make_expanded_record_from_datum() / DatumGetExpandedRecord() /  
PG_GETARG_EXPANDED_RECORD() were unused. I could not find any extensions  
using it either.  
  
It seemed too likely that one of the subsequent fixes in this series  
would break them, therefore this adds some tests (written with AI help).  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : fe781009460beb4fc18a14c6c0f589c0eaecff84    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Test a trigger on a partition table where a columns NOT NULLness differs  
between parent and child.  
  
Development versions of an upcoming fix broke those cases without  
breaking any extant tests.  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : bd5d3e2dfc52d95b8c744723b7ea78692f5c06d9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Test EPQ handling in presence of dropped columns and resjunk elements in  
the targetlist. Development versions of an upcoming fix broke those  
cases without breaking any extant tests.  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 646a2ae1b3e64d99cf249b612debf1698fd38957    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

We previously were lacking coverage for important assignment related  
codepaths that will be touched in an upcoming fix:  
  
- Assignment between record variables preserve ctid/tableoid only when  
  the source tuple can be copied verbatim; where a conversion is needed  
  they are silently dropped.  
  
- A record variable's declared type is re-resolved by name  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 16aa33802a3acb9d8d4aafa28c85bc312092d41e    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

This isn't closing any specific security bug, but attacks are perhaps  
conceivable due to various forms of type confusion or data corruption.  
Tighten that up a bit.  More is undoubtely possible.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Security: CVE-2026-120139  
Backpatch-through: 14  

commit   : 74bb8aa8c1284283b145ad94b7ef70cec3917263    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Set-returning functions in the target list with indeterminate RECORD  
return types incorrectly used the same tuple descriptor to read and  
return tuples from the tuplestore across invocations.  
  
These types of SRFs resolve their rowtype from the passed in record  
argument and it can differ from invocation to invocation. Reading tuples  
with the wrong shape of tuple descriptor can lead to incorrect results,  
crashes, and security issues. It was reported as a way to read arbitrary  
out-of-line values via json_populate_recordset().  
  
To fix this, drop and recreate the slot and its tuple descriptor per SRF  
invocation for materialized SRFs in the target list with dynamic RECORD  
return types.  
  
Only the target-list path is affected: table functions in FROM validate  
every result against the query-supplied descriptor, and value-per-call  
SRFs never retain a slot.  
  
Co-authored-by: Melanie Plageman <melanieplageman@gmail.com>  
Co-authored-by: Robert Haas <rhaas@postgresql.org>  
Security: CVE-2026-120141  
Backpatch-through: 14  

commit   : 98ec97f673d9489014988222f543c9107e3da724    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Commit 3d14e171e9e2236139e8976f3309a588bcc8683b (v16) made giving an  
object to another role depend on the ability to SET ROLE to that role.  
However, a role granted "INHERIT TRUE, SET FALSE" could bypass that, via  
REASSIGN OWNED.  A role granted "INHERIT FALSE, SET TRUE" saw the  
inverse problem: REASSIGN OWNED failed spuriously, while ALTER ... OWNER  
succeeded.  
  
For avoidance of doubt, fixing this doesn't change the limitations of  
SET FALSE.  If a role owns nothing, SET FALSE grantees can't make that  
role own its first object.  For many kinds of objects, once a role owns  
one, "INHERIT TRUE, SET FALSE" prevents nothing compared to "INHERIT  
TRUE, SET TRUE".  
  
REASSIGN OWNED also bypassed the CREATEDB privilege check in ALTER  
DATABASE ... OWNER TO.  Fix by duplicating the check.  This affects all  
supported versions.  This sort of omission remains easy to miss under  
the present design, so refactoring would be prudent.  
  
Document the way REASSIGN OWNED still differs from ALTER ... OWNER TO:  
the new owner's CREATE privilege on the schema of a relation or type is  
not checked.  
  
Back-patch to v14 (all supported versions).  In v15 and v14, REASSIGN  
OWNED's privs checks is stricter than the membership checks in ALTER  
... OWNER TO.  Leave that alone, rather than aligning the commands.  Do  
fix the CREATEDB omission.  
  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Backpatch-through: 14  
Security: CVE-2026-120146  

commit   : bccc9f389df407b0ec2e48d93d04695b1aef3d56    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

The query environment needed for portals over transition tables for  
triggers lasts only as long as the SPI connection, so the portals must  
be closed.  If not closed within the function, SPI_finish()  
force-closes them.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Backpatch-through: 14  
Security: CVE-2026-120143  

commit   : 8bbd75721f16b0015ef3af1d4bb7c6a78f2bdbbe    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

The WHERE condition of an automatically updatable view restricts the  
rows that an UPDATE, DELETE, or MERGE through the view can affect to  
those that are visible through it.  INSERT ... ON CONFLICT DO UPDATE  
through such a view did not follow this rule.  The conflicting row is  
found through the arbiter index rather than by scanning the view, and  
the view's WHERE condition was never applied to it.  DO UPDATE therefore  
updated the row whether or not the view showed it, and evaluated its SET  
expressions, its WHERE clause, and RETURNING against it; ON CONFLICT DO  
SELECT read it the same way.  This odd set of behaviors was documented,  
but it created a security issue, described further down.  
  
Fix by having rewriteTargetView() emit the view's WHERE quals as a  
WithCheckOption of new kind WCO_VIEW_CONFLICT_CHECK, which  
ExecOnConflictUpdate() and ExecOnConflictSelect() check against the  
conflicting row, innermost view first and before the ON CONFLICT WHERE  
clause is evaluated.  Using a new WCO kind for this is perhaps a little  
unorthodox, but doing so provides exactly what is needed here: it raises  
an error when a conflicting row doesn't satisfy the view's quals.  This  
makes sense because ON CONFLICT DO UPDATE guarantees that each row  
proposed for insertion is either inserted or updated, neither of which  
is feasible here.  The arbiter index belongs to the base relation, so  
the conflicting row makes insertion the wrong thing to do.  The view's  
WHERE condition puts the conflicting row beyond the reach of an update  
through the view, but it doesn't make sense to act as if there's no row  
to update, because when that happens we're supposed to take the  
insertion path instead (that's what upsert promises).  This situation is  
fundamentally irreconcilable, so throwing an error is all we can do.  
  
This fixes a security bug.  A user whose privileges on a view allow an  
upsert through it, but who holds none on its base relation, can modify  
every row that the view hides, one at a time, by guessing their keys, as  
if the view had no WHERE condition.  The same user can read those rows,  
through the conflict action's WHERE clause, its SET expressions, and  
RETURNING.  This historical behavior is hard to defend in general, and  
impossible to defend in cases where the target view happens to be a  
security barrier view.  
  
The problem dates to commit 168d5805e, which added ON CONFLICT and  
documented its original behavior with updatable views.  ON CONFLICT DO  
SELECT was added to Postgres 19 by commit 88327092f, and it inherited  
that behavior.  
  
An upsert through a view that relied on reaching rows the view hides now  
fails.  This should be called out as an incompatibility in the release  
notes for the next set of minor releases.  
  
Reported-by: Qing Xu <emyiqing@gmail.com>  
Reported-by: Carl Andersen <carl@spearbit.com>  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reported-by: shihao zhong <zhong950419@gmail.com>  
Author: Peter Geoghegan <pg@bowt.ie>  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Security: CVE-2026-16237  
Backpatch-through: 14  

commit   : 249fa011fb7b567a0820ec17001f817d9c82da7f    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

In-memory tuple sizes were being calculated in 64-bit-sized variables  
and later assigned to 32-bit variables, potentially leading to integer  
wraparound, which could then be used to overwrite server memory with  
attacker-controlled contents.  Repair by using overflow-aware addition  
and, for additions done in loops, checking that the result complies with  
the 1GB palloc limit at each step.  
  
Reported-by: Hillai Ben Sasson <hillai.bensasson@wiz.io>  
Reported-by: Jayden Sarveshkumar <jayden@verialabs.com>  
Reported-by: Mehmet Ince <mehmet@mehmetince.net>  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Tatsuo Ishii <ishii@postgresql.org>  
Security: CVE-2026-120139  
Backpatch-through: 14  

commit   : 046a36e03300b0f239dfb76801d3119568772c5d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

fmgr_sql_validator() rejected unsafe pseudo-type input parameters, but  
neglected to apply the same rule to output parameters.  An SQL function  
could therefore declare an output column of type "any".  This created  
problems for tupledesc_match(), which checks an SQL function's result  
rows against its declared output columns using IsBinaryCoercible().  
IsBinaryCoercible accepts every type for "any", so rows of an arbitrary  
row type could be read using a tuple descriptor that does not match  
their physical layout.  This could be abused to disclose server memory  
contents, and to perform arbitrary code execution.  
  
To fix, teach fmgr_sql_validator() to apply its pseudo-type check to  
parameters of every mode (not just for input parameters).  
  
Note that the treatment of record is somewhat arbitrary: record and  
record[] remain allowed as output column types, while record remains  
disallowed as an input parameter type.  Allowing record in either  
position is likely safe, but a back-patched security fix is not the  
place to change existing behavior either way.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Stephan Lipp <Stephan@Adalogics.com>  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Security: CVE-2026-18447  
Backpatch-through: 14  

commit   : 3754d3689a8dcdd9fca256c2799f40e69b099151    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

exec_cast_value() can reach code that will change the rowtype of a  
RECORD variable, but the RECFIELD case in exec_assign_value() doesn't  
account for that and assumes the record field type and column number  
that it previously looked up are still good.  Recheck that data  
if the tuple type ID changed; since that condition never holds in  
normal usage, this is a cheap enough safety check.  
  
Reported-by: Claude and Ada Logics  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-120151  

commit   : 7c822f3430abec4a41bc59b452bc8b8eb9c8c579    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

build_dummy_expanded_header() sets up the expanded record's dummy  
child to have eoh_context equal to the parent's er_short_term_cxt.  
If some operation on the dummy record causes creation of a short-term  
context belonging to the dummy record itself, that will be a child  
of the parent's er_short_term_cxt, which means it will get deleted  
when we reset the parent's er_short_term_cxt at the end of the callers  
of build_dummy_expanded_header().  So the next time through, we'll try  
to use a dangling context pointer, which often will now be pointing  
at some other unrelated context.  That at least risks a crash, and  
it's reported to be exploitable for arbitrary code execution.  
To fix, just clear the potentially-dangling pointer in the next  
usage cycle.  
  
Reported-by: Claude and Ada Logics  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-120150  

commit   : 6925c6816e953570e559ccbcf3b9d0022bcccd03    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Connection options passed to dblink(), dblink_connect[_u](), and  
dblink_exec() didn't flow through the same validation path as options  
which were set via foreign server definitions. Additionally, connection  
options added to subscriptions didn't go through any validation except  
for the password check. This allowed the sslkeylogfile parameter and  
all oauth_* parameters, both introduced in PG18, to be set by relatively  
unprivileged users.  
  
Add libpqsrv sanitization functions which block unsafe and unknown  
connection options. These are called before libpqsrv_connect() and its  
variants. (Extensions which use those functions are encouraged to do the  
same.) walrcv_connect() makes an exception to this rule for  
primary_conninfo, which is still allowed to contain any parameters.  
  
To reduce the size of the patchset, the implementation has the following  
drawbacks, which we hope to improve after release:  
  
- The superuser is also restricted.  
- The sanitization functions are not invoked when administering foreign  
  server options, or when modifying subscriptions without connecting, to  
  avoid interfering with pg_upgrade and dump/restore. The restrictions  
  will be applied later, at connection time, which may be a surprise.  
  
Backpatch all the way down. Though the new options aren't present in  
older libpqs, running an older server with a newer libpq is common. The  
tests for the newer options unfortunately cannot be easily backpatched  
past PG18.  
  
Reported-by: Andrey Krasichkov <buglloc@yandex-team.ru>  
Reported-by: b.altawil <b.altawil@proton.me>  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Suggested-by: Noah Misch <noah@leadboat.com> (sslkeylogfile part)  
Reviewed-by: Noah Misch <noah@leadboat.com> (sslkeylogfile part)  
Reviewed-by: Andres Freund <andres@anarazel.de> (PG14/15 backpatch)  
Backpatch-through: 14  
Security: CVE-2026-14661  

commit   : 48be6f9e82a6ac81056cd7a96d0077e0697acbc5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

ExecOnConflictUpdate() and ExecOnConflictSelect() evaluated the  
user-supplied ON CONFLICT WHERE clause before checking the pre-existing  
conflicting row against the RLS policy USING quals collected as  
WCO_RLS_CONFLICT_CHECK.  A user could therefore have that clause read a  
row that no policy allowed them to see.  
  
Fix by performing the check immediately after the conflicting row is  
locked and found visible, before the WHERE clause is evaluated.  A row  
that fails the check now raises an error whatever the WHERE clause would  
have returned, so the two outcomes are no longer distinguishable.  
  
This moves the USING quals of the UPDATE policies ahead of the WHERE  
clause as well, not just those of the SELECT policies.  Only the latter  
is a security issue, since a row that nothing but an UPDATE policy hides  
can be read with a plain SELECT anyway.  No order is consistent with  
every other command: a plain UPDATE evaluates both kinds of USING qual  
ahead of the user's quals, whereas MERGE evaluates a WHEN MATCHED ... AND  
condition ahead of the UPDATE policies' USING quals, since it cannot  
know whether it is going to update until then.  ON CONFLICT DO UPDATE  
now behaves like UPDATE.  
  
This dates to 168d5805e, which added WCO_RLS_CONFLICT_CHECK along with  
ON CONFLICT itself.  ON CONFLICT DO SELECT was added in 19 by 88327092f,  
so the back branches only need the ExecOnConflictUpdate() part of the  
fix.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reported-by: Only see myself <1950233439@qq.com>  
Reported-by: Nicholas Carlini <npc@anthropic.com>  
Reported-by: Joao Detomini <joao.detomini@enterprisedb.com>  
Reported-by: Josef Šimánek <josef.simanek@gmail.com>  
Reported-by: Qing Xu <emyiqing@gmail.com>  
Author: Peter Geoghegan <pg@bowt.ie>  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Security: CVE-2026-120154  
Backpatch-through: 14  

commit   : b94b7254f31538bc84684723ae2cdf27e1877589    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Because check_composite_type_dependency() didn't hold a lock while  
inspecting the pg_proc entry, it was possible that the dependency was  
deemed harmless, but concurrently, another backend added a DEFAULT  
expression to the function that should've been rejected.  To fix, hold  
an AccessShareLock on the pg_proc object while we inspect it, and on  
the other side of the story, hold an AccessExclusiveLock on the  
pg_proc object when modifying it.  
  
Note that we don't lock functions or other objects except relations  
when using them in queries, so the AccessExclusiveLock doesn't prevent  
concurrent queries using the function.  
  
This also adds locking to other objects (constraints, types) inspected  
in check_composite_type_dependency(), although that is just pro forma,  
because there is no DDL to replace the expression of an existing CHECK  
constraint, and altering a rowtype already holds a lock that conflicts  
with an ALTER DOMAIN SET DEFAULT expression on a domain over the same  
rowtype.  
  
Relations don't have this problem, because there is no DDL command to  
alter an existing table's PARTITION BY expression, nor an existing  
index's expressions or quals.  The OF type can be altered, but AFAICS  
we have sufficient locking in place for that.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : b7b16664ae129a09fc8960dc7e8d906bbe3cc1fb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

On ALTER TYPE ... ALTER ATTRIBUTE, acquire AccessExclusiveLock on the  
rowtype, and all dependent types (arrays, domains, etc. over the  
target type).  This ensures that a concurrent backend doesn't add a  
dependency to the type that we would miss in our dependency checks.  
We were already holding the lock on the corresponding relation, and  
that conflicted with many operations, but not all operations that use  
a type also lock its relation.  
  
Note that we don't lock types (or other objects except relations) when  
using them in queries, so the AccessExclusiveLock doesn't prevent  
concurrent queries from using the type.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : e00986934cd0669ee3324b1cb518d5d781084c49    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

ALTER TABLE/TYPE checks if the type is being used in a column and  
forbids it, because that would require rewriting the data in the  
affected table.  But the check missed cases where the type was  
concurrently used in a CREATE TABLE or ALTER TABLE ADD COLUMN that  
hasn't committed yet.  
  
Commit 2fbb21170e fixed a similar race condition for dropping the  
column type altogether, but it wasn't sufficient to fix the problem  
with altering the type, because altering a composite type doesn't  
currently lock the type.  It does lock the *relation* corresponding to  
the type (i.e. pg_type.typrelid), but CREATE TABLE did not hold onto  
that lock, even though it acquires it momentarily.  To fix, don't  
release the lock.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : bed004f15fbcb087b21a11ec097a215cdc66b7ff    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

With this, we can remove find_missing_composite_type_dependencies() in  
'master', but I'll do that in a separate commit.  This doesn't help  
with existing missing dependencies, so we need to keep  
find_missing_composite_type_dependencies() in backbranches.  It's  
still better to record them going forward, though, even in  
backbranches.  
  
For all reporters and public discussions, see previous commits.  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : ece162bd78ea50be060174c5d07304c77ab2eabb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

If an expression that's stored in a catalog references a rowtype in a  
way that would break ALTERing its attribute, we record a dependency on  
the type, and find_composite_type_dependencies() prevents ALTERing it.  
However, we have failed to record the dependency in some cases, namely  
if the expression itself doesn't depend on the type in an incompatible  
way, but produces a *result* of the given datatype which is stored.  
That problem arises from index expressions, PARTITION BY expressions,  
and from expression statistics.  
  
To fix, scan the pg_index, pg_partitioned_table and pg_statistic_ext  
catalogs for those cases as a separate sub-step of  
find_composite_type_dependencies().  In the future, after we have  
added the missing dependency creation and backfilled any existing  
missing dependencies, we can remove this code.  That means, in a new  
major version.  
  
For all reporters and public discussions, see previous commits.  
  
Co-authored-by: Nathan Bossart <nathan@postgresql.org>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : d054d0f6e44282440a236518f2836d8554656187    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:57 -0800    

Because the foreign table's statistics could have datums in the old  
format.  
  
For all reporters and public discussions, see previous commits.  
  
Co-authored-by: Nikhil Sontakke <nikhil@planetscale.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 0cba228497024010a9659da7a70c4780f3b05f65    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Similar to previous commits, if a relation depends on a composite  
type, we need to inspect it more carefully.  We already checked tables  
using the composite type in columns, but the dependency might also  
exist because a partitioned table's PARTITION BY expression uses the  
type, or an expression in an expression or partial index.  
  
For all reporters and public discussions, see previous commits.  
  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : e9e6af6ba819fde50580aab7b57ff3419063dd69    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Similar to previous commits, also look more closely at a type  
depending on a composite type.  If it's a domain, its DEFAULT  
expression might contain a Const that would need to be rewritten if  
the composite type was ALTERed.  
  
For all reporters and public discussions, see previous commits.  
  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 4a4fffe3566964414bc9fdf7e3a607a5a7f4b42d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Similar to previous commit, we also need to look more closely at a  
dependency from a constraint to a composite type.  The constraint's  
DEFAULT might contain a Const or other expression that would need to  
be rewritten, if the composite type was ALTERed.  
  
For all reporters and public discussions, see previous commits.  
  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : e90dffb9e03d665ebc8325ca27eb690644139c41    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

A function that uses a composite type as its return or argument type  
doesn't prevent altering the composite type.  However, if it's used in  
an argument DEFAULT expression, or in the new-style SQL function body,  
we must not allow it, because e.g. any Consts in those expressions  
would become invalid and we don't have the machinery to rewrite them.  
If there's a pg_depend entry on a function, look more closely where  
the dependency comes from, and throw an error if it's from those  
expressions.  
  
For all reporters and public discussion, see previous commit.  
  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 032544a3934331f36c923f303d8152a81f13a630    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Previously, we'd allow changing the column type of a table or  
composite type (ALTER COLUMN / ATTRIBUTE ... TYPE ...) even if there  
are objects depending on the row type.  We only made some checks on  
dependencies from relation objects, and assumed that dependencies from  
other kinds of object were OK.  This commit flips the logic around to  
forbid if there are any dependencies, except for relations and a few  
other cases that are known to be OK.  
  
This commit is mostly refactoring, but some cases that were previously  
broken, like expressions in views, are now forbidden.  Some of the  
dependencies that we continue to allow are known to be broken too --  
subsequent commits will tighten them up.  
  
The attributions and discussion links are for the whole wider issue  
covered by all the related commits, not just the variants fixed by  
this one commit.  
  
Reported-by: Andrew Gierth <andrew@tao11.riddles.org.uk>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reported-by: Francesco Verardi <frevadiscor89@gmail.com>  
Reported-by: Hcamael <baiyjrh@gmail.com>  
Reported-by: Tomer Fichman <tomer@irregular.com>  
Reported-by: OpenAI Security Research Team  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Mehmet Ince @mdisec <mehmet@mehmetince.net>  
Reported-by: Bryan Green <dbryan.green@gmail.com>  
Reported-by: Sumedh Pathak <sumedhpathak@microsoft.com>  
Reported-by: Nicholas Carlini <npc@anthropic.com>  
Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru>  
Reported-by: Yuxiao Guo <dllggyx@outlook.com>  
Reported-by: Nikhil Sontakke <nikhil@planetscale.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://www.postgresql.org/message-id/CA%2BUBoq0F2ua2fQEAU3-6w0oxOgFc9BgEN4gRcchiUUZ%2BWouVrQ%40mail.gmail.com  
Discussion: https://www.postgresql.org/message-id/CA%2BbCEdDvsVApd%2BAADX%3D5uyj6Q5C3r5aruWNzOFaYqaFqLwE_5g%40mail.gmail.com  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 4428c073af2fcbed9f17670a3e2a9549d809fe0e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

When recursing, keep track of visited types in a hash table.  This is  
currently just an insignificant performance optimization, but it will  
come handy in the upcoming patches where we can use the hash table to  
do expensive catalog scans only once.  The upcoming patches will be  
backpatched which is why this is backpatched too.  
  
Add a test for the case that a type ultimately depends on the same  
composite type via two different paths.  That's the case where the  
hash table lets us avoid some work.  It isn't very likely to be  
broken, but let's have coverage for it for the sake of completeness.  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 2f5acf4fdac45167ac628fef092453a30503cab3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

To make it a little easier to see what the upcoming commits change,  
move some of the logic from find_composite_type_dependencies() into  
subroutines.  This is pure refactoring, there is no change in  
user-visible behavior.  
  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : 3ee30c1dc9e1fdd256c631265654b07b33ff63b2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

There are a bunch of bugs in find_composite_type_dependencies(), which  
will be fixed by subsequent commits.  Usually we include tests in each  
commit that fixes a bug, but there are so many variants of these that  
it feels easier to add all the tests in one commit first, to show the  
big picture.  This commit memorizes the incorrect results in the  
expected output, marked with FIXME comments to point out that they are  
broken.  The next commits will fix the issues, adjust the expected  
output for the correct behavior, and remove the FIXMEs.  
  
Backpatch-through: 14  
Security: CVE-2026-6460  

commit   : 22762f03aca1db7086625fae63cb487e6c37550d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Those commands rewrite the table, but they don't affect other tables  
or Consts using the rowtype.  
  
The reason to do this now is that the next commits will tighten up the  
dependency checking to reject more cases.  After those commits, we  
would also unnecessarily reject SET LOGGED/UNLOGGED in more cases, so  
it seems nice to eliminate the unnecessary checks first.  That's also  
why this is backpatched.  
  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Security: CVE-2026-6460  
Backpatch-through: 14  

commit   : b90297426cb20de11dc4a582cc896463840db5fe    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Previously, a dblink query that returned rows kept using its  
connection after handing each row to the declared column type's input  
function. That input function can run user-defined code (e.g., a  
domain type with a CHECK constraint), so SQL can re-enter dblink while  
an outer call is still reading results, and close the connection that  
call is reading from. The close freed the connection object while the  
outer call held a pointer to it, so the next libpq call read and wrote  
freed memory.  
  
dblink never had a rule about reentrancy. Calls that issued a new  
query failed on their own, but by accident rather than by design:  
libpq rejects a new query while one is in progress. It doesn't reject  
reading a result, so a reentrant dblink_get_result() consumed a row  
out of the outer query's single-row stream.  
  
Fix this by marking a connection while a dblink call is materializing  
a result from it, and refusing every other dblink call on that  
connection until it's done.  
  
Backpatch to all supported branches.  
  
Reported-by: 안지용 <jfdg1y76@gmail.com>  
Reviewed-by: Jacob Champion <champion.p@gmail.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Backpatch-through: 14  
Security: CVE-2026-120147  

commit   : 60c7b4d04d4651c54c0f019ecfa1b45801513900    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

The subscriber relied on the publisher refusing to add a system  
catalog to a publication, and checked only the relation kind it was  
about to apply into. However, the relation is named by the publisher,  
and a publisher that speaks the logical replication protocol doesn't  
have to be a PostgreSQL server. A malicious one can name a system  
catalog, and the apply worker will write into it.  
  
The danger is limited to subscriptions owned by a superuser. Changes  
are applied as the table owner, or as the subscription owner when  
run_as_owner is set, and a non-superuser can never hold write  
privileges on a system catalog, so a subscription owned by a  
non-superuser stops at the privilege check.  
  
We can't depend on the publisher for this, so check the target  
relation on the subscriber too. A relation that the server maintains  
for its own use, such as a system catalog, must never be written by an  
apply worker, and neither must a temporary relation. We don't reject  
unlogged relations the way the publisher does; replicating into one is  
fine. The check runs when a worker opens the target relation to apply  
changes, and also when getting the relation list, so that such a  
relation is never recorded in pg_subscription_rel in the first place.  
  
The test attaches a callback of its own to the injection point, which  
needs a form of injection_points_attach() that v18 and older don't  
have, so it is applied to v19 and later.  
  
Reported-by: qian zhang <ttwzlt@gmail.com>  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 14  
Security: CVE-2026-120145  

commit   : 033886653976a2f5055b5441ef8b7a933f7803d2    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Previously, CREATE STATISTICS accepted an expression of a pseudo-type.  
So the statistics were built on a value whose row type is identified  
only by a typmod assigned locally in the backend that ran ANALYZE.  
Therefore, other sessions could read the statistics as the wrong data  
type, which can crash the server or return wrong results.  
  
Reject such expressions at CREATE STATISTICS time, including a type  
that contains a pseudo-type, such as a composite type with an anyarray  
column. An expression whose collation can't be determined is now  
rejected too, but ANALYZE fails on such statistics anyway.  
  
Since a statistics expression has no column name, teach the column type  
check to report an error without one.  
  
A statistics object built this way on an older minor release can still  
exist on v18 and older, so in those branches also error out when such  
statistics are used by the planner, their contents are read, or ANALYZE  
builds them. Those objects should be dropped.  
  
Backpatch to 14, where statistics on expressions were introduced.  
  
Reported-by: Mehmet D. INCE <mehmet@mehmetince.net>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Backpatch-through: 14  
Security: CVE-2026-120148  

commit   : 7d1f31c7354f760f2dfa73800ceebc4a3fbed75f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

pg_dump tar format contains an undocumented restore.sql archive member  
that the user can edit according to its embedded comments and then run  
with psql.  Commit 71ea0d6795438f95f4ee6e35867058c44b270d51 added  
\restrict and \unrestrict to fix CVE-2025-8714.  That restore.sql always  
used "(null)" as the restriction key, so the key did not provide its  
intended protection.  Also, there was an initial \unrestrict before any  
restrict, yielding a spurious error.  Given the lack of reports about  
that spurious error in over a year, restore.sql may see negligible use.  
  
This defers fixing restore.sql from "pg_dump --format=tar --inserts",  
because that relies on "\i" commands.  That case is not subject to  
attack, but it fails to restore table data.  We should eventually fix  
"pg_dump --format=tar --inserts" restore.sql or remove restore.sql.  
Given this combination with --inserts has been broken to that degree,  
again for over a year, the combination must see little use indeed.  
  
Back-patch to v14 (all supported versions).  
  
Reported-by: Pavel Kopylov <pkopylov@cloudlinux.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> (non-test)  
Reviewed-by: Jacob Champion <champion.p@gmail.com> (test)  
Reviewed-by: Andres Freund <andres@anarazel.de> (test)  
Bug: #19718  
Discussion: https://postgr.es/m/19718-7e945d0ff9b5a589@postgresql.org  
Backpatch-through: 14  
Security: CVE-2026-116330  

commit   : bc146a3d5bf8269c85a2fbac17512cb598ec8de1    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Commit cd5f2a3570 rejected schema and owner names containing  
quotes, backslashes, and dollar signs, but names containing  
newlines, carriage returns, comment delimiters, or the substitution  
tokens themselves can still achieve SQL injection.  To fix, reject  
those names, too.  
  
Reported-by: Anthropic OSS program  
Reported-by: Sven Klemm <sven@tigerdata.com>  
Reported-by: Aaron Chen <chenyoulong20g@ict.ac.cn>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Greg Burd <greg@burd.me>  
Security: CVE-2026-120153  
Backpatch-through: 14  

commit   : be83a07a54833a77eef09fe130d90e1b35606e7b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Foreign data wrappers are expected to return the number of  
successfully inserted tuples via ExecForeignBatchInsert's numSlots  
parameter.  Both the executor and COPY FROM use that number as the  
length of the slot array.  If the FDW reports more rows than we  
sent, the backend proceeds to read past the end of the array.  
(postgres_fdw is acutely affected: if the remote table has an  
INSERT rule, the reported count may be higher.)  To fix, clamp the  
reported count to the number of rows that were sent.  
  
This is a stopgap.  Clamping keeps statements that happen to  
succeed today succeeding, at the cost of misreporting the number  
of rows.  A better solution will likely involve reworking the API,  
but that is left as a future exercise.  
  
Reported-by: Sumedh Pathak <sumedhpathak@microsoft.com>  
Reported-by: Sven Klemm <sven@tigerdata.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Jacob Champion <champion.p@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Security: CVE-2026-120149  
Backpatch-through: 14  

commit   : ac809c8b11fb98e287d6c8e50001698c862f0f14    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Commit 62aba76568 taught security-restricted operations to refuse  
temporary table creation, since the calling session might not  
expect untrusted objects to appear at the front of its search  
path, but the same hazard exists for types.  This oversight  
allowed code running within such an operation to create domains,  
enum types, and range types in the session's temporary schema,  
potentially leading to privilege escalations.  To fix, refuse to  
create these types in a temporary schema within a  
security-restricted operation, as we already do for tables.  
  
The checks live in the command paths rather than in TypeCreate(),  
which also creates the rowtypes of the transient relations that  
REFRESH MATERIALIZED VIEW CONCURRENTLY and rewrites of temporary  
tables legitimately place in pg_temp within a security-restricted  
operation.  Composite types are already covered by the existing  
check in DefineRelation(), and creating base or shell types  
requires superuser.  Other object kinds are left alone, since  
unqualified names never resolve to them in pg_temp.  
  
Reported-by: Anthropic OSS program  
Author: Anthropic OSS program  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Security: CVE-2026-116316  
Backpatch-through: 14  

commit   : 265d71b28720c8649a9f02516ddb14ba97689df4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

pg_restore trusts the contents of the archives it reads, so a  
maliciously crafted archive can cause out-of-bounds reads and  
writes, or make pg_restore read files outside the archive  
directory.  This commit fixes the following issues:  
  
* Dependency IDs read from the table of contents are used as array  
  subscripts without validation.  To fix, reject any that is not a  
  positive integer.  
  
* _getObjectDescription() and IssueACLPerBlob() can read past the  
  end of a string when an entry's DROP statement or large object  
  ACL has an unexpected form.  To fix, check for the expected  
  prefix before moving past it.  
  
* A crafted archive can cause the dump ID index to be built before  
  the table of contents has been read, in which case it is too  
  small for every later lookup.  To fix, have the tar format reject  
  archives whose table of contents is not the first member.  
  
* The directory format opens the files named in the archive  
  without inspecting them.  To fix, reject names that contain a  
  directory separator and anything that isn't a regular file.  
  
* A tar member length that does not fit in a pgoff_t can cause a  
  buffer overrun on 32-bit systems.  To fix, reject such lengths.  
  
* In the back-branches, buildTocEntryArrays() sizes the dump ID  
  index arrays with unchecked multiplication, which could overflow  
  size_t on 32-bit systems.  To fix, use pg_malloc0_array().  
  
A corrupt archive can still crash pg_restore in other ways, but  
hardening against that didn't seem appropriate for a security fix,  
and therefore it is left as a future exercise.  
  
Reported-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reported-by: Yonghwa Lee <underdog@theori.io>  
Reported-by: OpenSec <security@opensec.in>  
Reported-by: Ben Dixon <uk.bendixon@gmail.com>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Author: Yonghwa Lee <underdog@theori.io>  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Security: CVE-2026-116314  
Backpatch-through: 14  

commit   : 1f2dd21c100f5763cea22affea3eb365bf1c02c6    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

DROP OWNED BY removes the given roles from any row-level security  
policies that apply to them, but it does not check that the current  
user owns the table.  This allows a role to remove itself from  
restrictive policies on tables it does not own.  To fix, leave such  
policies unchanged and issue a warning, as is already done for  
privileges that the current user cannot revoke.  
  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reported-by: Anthropic OSS program  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Co-authored-by: Anthropic OSS program  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Sami Imseih <samimseih.pg@gmail.com>  
Security: CVE-2026-116311  
Backpatch-through: 14  

commit   : 4fb06bd938b40bf2f2ae484d98e911b865f83a4c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

dintdict_lexize() does not check for zero-length tokens before  
inspecting its input, so it can read past the end of the token.  In  
some cases, the returned lexeme can even contain data from well  
beyond it.  To fix, return NULL for a zero-length token, as  
dict_ispell, dict_synonym, and dict_xsyn already do.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Reported-by: Anthropic OSS program  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Co-authored-by: Anthropic OSS program  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tatsuo Ishii <ishii@postgresql.org>  
Security: CVE-2026-116308  
Backpatch-through: 14  

commit   : 0fdf86e95d97826770e54f70a68d73c3212a8620    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

When a foreign key's referencing column must be cast to the type of  
the referenced column, the comparison that decides whether an  
UPDATE of the referencing table changed the key executes the cast  
function without first checking for EXECUTE privileges.  To fix,  
check privileges and invoke the function execution hook before  
calling the cast function.  Note that this check is made as the  
user issuing the UPDATE, since the comparison happens before any  
switch to the referenced table's owner.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Security: CVE-2026-116303  
Backpatch-through: 14  

commit   : 879c760d818956c03b999ef205a461c149911762    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

When converting a value to json or jsonb, to_json() and its many  
friends execute the cast function without first checking for  
EXECUTE privileges.  To fix, check privileges and invoke the  
object access hook before calling the cast function.  This  
covers to_json(), to_jsonb(), row_to_json(), array_to_json(), the  
json[b]_build_*() and *_agg() functions, the SQL/JSON constructors  
(v16 and later), and COPY TO with FORMAT json (v19 and later).  
  
Reported-by: Filip Janus <fjanus@redhat.com>  
Reported-by: Anthropic OSS program  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Co-authored-by: Anthropic OSS program  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Security: CVE-2026-116303  
Backpatch-through: 14  

commit   : c65fee830f938e08a6f78034078e0253d65cd596    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:56 -0800    

Between CreatePortal() and PortalStart(), a portal can run user-defined  
code due to planning and executor startup, like SQL functions.  A  
function attempting to close a portal would free it, without its creator  
knowing about it.  This could lead to use-after-free issues when trying  
to use portals that have already been closed.  
  
With this change, PortalDrop() now refuses to act on portals marked as  
PORTAL_NEW or PORTAL_DEFINED.  CLOSE ALL skips them, as it does for  
active portals.  Note that AtAbort_Portals() (for transaction aborts)  
and AtSubAbort_Portals() (for subtransaction aborts) now puts such  
portals in a failed state so as they can be cleaned up during error  
cleanup.  
  
Two sets of tests are added:  
- Portal manipulations during planning and executor startup.  
- Portals and Bind messages, relying on injection points to check  
various transaction cases with portals marked as either PORTAL_NEW or  
PORTAL_DEFINED, where the on-error cleanup of portals marked as failed  
matters.  
  
Reported-by: Tomas Vondra <tomas@vondra.me>  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116332  

commit   : b2f9e083f94d98b81506e6f196d0312ceabd7d1c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Historical behavior was bizarre.  'CREATE EXTENSION tcn SCHEMA "$user"'  
set extnamespace='$user'::regnamespace, but the extension's object  
landed in the schema named after the bootstrap superuser if such a  
schema existed, else in pg_temp.  Many extension scripts failed, since  
pg_temp is searched for only a subset of object types.  In other  
scenarios, a trusted-extension script located the wrong object and  
executed arbitrary SQL of a non-superuser's choice.  The prior commit's  
locking additions could not cover this.  Back-patch to v14 (all  
supported versions).  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Backpatch-through: 14  
Security: CVE-2026-6467  

commit   : 2c8b00bbfcd889f8b3619246bb277f873a63e376    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Commands that run extension SQL scripts intentionally depart from a  
standard, "Remove from search_path any schemas that permit untrusted  
users to create objects."  While CVE-2020-14350 blocked most attacks,  
one remained via ALTER SCHEMA extschema RENAME.  A user with  
database-level CREATE privilege could execute arbitrary code as the  
bootstrap superuser.  Block that attack by having ALTER SCHEMA RENAME,  
CREATE EXTENSION, and ALTER EXTENSION UPDATE lock the schema.  This  
makes schema rename locking more like that for object types  
AlterObjectRename_internal() covers.  
  
Also, make extension-mutating commands take self-exclusive locks.  Make  
relevant commands take the same lock on each dependency extension.  This  
doesn't stop a known attack against a specific extension, but  
overlapping extension mutations are fragile and not useful.  
  
Back-patch to v14 (all supported versions).  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Backpatch-through: 14  
Security: CVE-2026-6467  

commit   : 3a70ff73c88ceb3e04477e94a3a3182a6ed1227f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

ReindexRelationConcurrently() keeps track of the OIDs of the relations  
it processes across all its phases, relying on session locks to protect  
them.  A function called from an index predicate or expression could  
drop one of the indexes being processed by a REINDEX CONCURRENTLY,  
causing a crash during the swap phase due to a relation gone missing.  
  
The relations being reindexed, on which are taken the session locks, are  
now pinned during the build and validation phases so as no manipulation  
of their definition can happen in the session running a REINDEX  
CONCURRENTLY.  
  
Reported-by: Florent Saudel <fsaudel@protonmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 14  
Security: CVE-2026-116336  

commit   : 332a8169289ad5e5f6e60d893a68f63e3b8bb50d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

The commutator or negator of an operator must surely return the same  
data type as the operator itself (always boolean for a negator, but  
for a commutator it could be any type).  CREATE/ALTER OPERATOR  
failed to enforce this, providing a route for evildoers to reach  
type-confusion problems.  
  
Another ancient oversight in this feature is that if the first CREATE  
OPERATOR names a commutator or negator, but no corresponding clause  
appears in the CREATE OPERATOR that fills in the shell operator, we  
failed to preserve the shell operator's back-link, resulting in  
inconsistent catalog state.  That has to be considered part of the  
security problem, since it prevents checking whether the two operators  
have matching result types.  However, fixing it means that an operator  
created without any COMMUTATOR or NEGATOR clause at all can acquire a  
commutator/negator, if it overwrites a shell operator that links to  
such a sibling object.  That creates a new security problem: an  
attacker could set up a trojan-horse operator that names a  
commutator/negator operator that doesn't exist yet, but that the  
attacker expects to be created later.  Then the attacker has the  
potential to inject his own code into uses of that victim operator.  
The object_ownercheck() test in OperatorCreate() doesn't prevent  
that if the second operator is created by a superuser.  To fix this,  
we change that test to insist on exact equality of creating user.  
(This tightening could potentially break innocent use-cases, except  
that it's hard to foresee innocent cases where the two operators  
wouldn't be created by the same role.  The logic does not prevent  
either operator from being reassigned to a new owner later.)  
  
In v16 and earlier, this fix incorporates portions of commit  
2b5154bea.  Before that, there were yet other scenarios for creating  
inconsistent commutator/negator links, potentially allowing type  
confusion.  I also adopted some of the cosmetic refactoring done in  
that commit, just to make pg_operator.c look less different across  
branches.  
  
In master, this deletes OperatorUpd() in favor of an expanded function  
UpdateOperatorLinks().  In the back branches, OperatorUpd() is kept to  
preserve ABI compatibility.  I doubt there are any external callers,  
but as a one-line wrapper it's cheap enough to not worry about.  
  
Reported-by: Stephan Lipp <Stephan@Adalogics.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116335  

commit   : 11ed90979368c83289458e5f01795cc4e7667e0a    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Previously, spi_freeplan() released a prepared query's plan, and the  
memory context holding it, without checking whether the query was  
still running. Executing a prepared query can re-enter plperl, and the  
re-entered code could free the query being run. That memory context  
also holds state the running execution still needs, so freeing it  
midway left that execution using freed memory and crashed the backend.  
plperl is trusted, so any role able to create a function can reach  
this.  
  
Fix this by counting the executions in progress for each prepared  
query and refusing spi_freeplan() while that count is above zero. A  
count rather than a flag is needed because the same query can be  
running more than once at a time.  
  
Backpatch to all supported branches, where spi_freeplan() has always  
freed the plan unconditionally.  
  
Reported-by: Zheng Yu <zheng@depthfirst.com>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Backpatch-through: 14  
Security: CVE-2026-116307  

commit   : 6ccaa399e40f0340caa4dd03360b731192bc96c2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

When ExecInsert() returns, after a partition-routed insertion, it can  
leave the 'mtstate->mt_transition_capture->tcs_original_insert_tuple'  
field pointing to the original slot.  If ExecARInsertTriggers() or  
ExecARUpdateTriggers() is called later for a different tuple, it will  
add the stale 'tcs_original_insert_tuple' to the trigger transition  
table, instead of the new tuple.  
  
ExecCrossPartitionUpdate() recognized this problem and reset the field  
after calling ExecInsert(), but ExecMergeNotMatched() didn't get the  
memo, so a MERGE that did an INSERT followed by an UPDATE action would  
use the wrong tuple for the trigger transition table on the UPDATE.  
  
There is another near miss in ExecBatchInsert(): it also calls  
ExecARInsertTriggers() with the incorrect tuple already set in  
'tcs_original_insert_tuple', but because we don't currently support  
transition tables with foreign tables, you get an error before that  
causes any harm.  Similarly, batching in CopyFrom() is not supported  
with statement triggers.  
  
The way the TransitionCaptureState->tcs_original_insert_tuple field is  
set and reset is error prone, as this bug shows.  Its purpose is to  
smuggle the original tuple to ExecARInsertTriggers() and  
ExecARUpdateTriggers() functions -- it always corresponds to new tuple  
that's passed as the 'slot' or 'newslot' argument.  That's a pretty  
cavalier way of passing an argument, and prone to mistakes.  In  
'master', make it a normal argument to those functions instead and  
remove 'tcs_original_insert_tuple' field altogether.  In hindsight, we  
should've done that in commit 6973533650c0 already, which removed the  
only other field in the struct that had to be set correctly for the  
new tuple on each call.  In stable branches, to avoid breaking ABI  
compatibility, just fix the immediate issue by setting the  
'tcs_original_insert_tuple' field closer to the ExecAR*Triggers()  
calls that need it, and resetting it immediately afterwards.  
  
In the passing, remove a stale comment in ExecInsert() that talked  
about the "active tuple conversion map".  That was removed in commit  
6973533650c0.  
  
Add a regression test; the existing MERGE transition-table test uses a  
non-partitioned target and does not reach this path.  
  
Reported-by: Jacek Bylina <jacek@enveritas.org>  
Reported-by: Timothy Ball <timball@enveritas.org>  
Reported-by: Claude and Ada Logics  
Co-authored-by: Jacek Bylina <jacek@enveritas.org>  
Co-authored-by: Jacob Robertson <jacob@enveritas.org>  
Co-authored-by: Nigel Gott <nigel@enveritas.org>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Backpatch-through: 15  
Security: CVE-2026-116312  

commit   : 49521f66da8dd7240a0abb793857be82e11a1ffd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Previously, the following sequence of events was possible: (1) new  
anonymous-record typmod gets entered into shared_typmod_table;  
(2) another process resolves the typmod and stores a pointer to the  
associated TupleDesc; (3) the first process realizes that the  
TupleDesc duplicates one that already has some other typmod assigned  
to it and frees the TupleDesc; (4) later, the other process  
accesses the now-freed storage, interprets it as a TupleDesc, and  
uses it to deform a tuple.  
  
It is likely that an attacker can control the new contents of the  
freed memory to a sufficient degree to achieve arbitrary code  
execution; hence, this is a security vulnerability.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Security: CVE-2026-116304  
Backpatch-through: 14  

commit   : d35f66916418ee6d50c198314d40c7fd1b8d1a87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

A sort-operator option only makes sense for an aggregate that behaves  
like MIN or MAX.  We can't really verify whether an aggregate does,  
but for our purposes the most important expectation is that the  
aggregate returns the same type as its input.  Without this, the  
planner's conversion to a MinMaxAggPath plan risks type violations.  
Since such aggregate definitions might already exist in the wild,  
check this during planning and don't generate MinMaxAggPath if the  
types don't match.  
  
Reported-by: Zheng Yu <zheng@depthfirst.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14-19  
Security: CVE-2026-116331  

commit   : 357a99a4d4d13aa5b8d50252dc12d0dac1a3e702    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

The composite type may be modified during execution, e.g. between  
deforming and forming a value, but the executor code ignored that and  
could have deformed/formed the tuple with a mismatching descriptor. The  
consequences could be severe, including reading/writing memory, etc.  
  
Fixed by remembering the descriptor in ExecInitExprRec(), and using it  
when deforming and forming tuples later, instead of looking up a new  
descriptor. This is the same approach already used for RowExpr.  
  
This means attributes added after initializing the descriptor will be  
treated as NULL, and dropped attributes will be removed from the tuple.  
  
Technically, this is an ABI break. It modifies the ExprEvalStep, which  
is part of the ABI. The meaning of one pointer (replacing rowcache with  
tupdesc) changes, and ncolumns gets removed. Neither changes the layout  
or size of the struct, and so should be backwards compatible. It could  
have a bigger impact on custom JIT providers, but we've not found any.  
  
Reported-by: OpenAI Codex Security  
Reported-by: Bronson Yen <bronson@calif.io>  
Reported-by: Mehmet D. INCE <mehmet@mehmetince.net>  
Author: Tomas Vondra <tomas@vondra.me>  
Co-Authored-by: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Security: CVE-2026-116306  
Backpatch-through: 14  

commit   : 9d322a971e99a4971467f5c0187cc13496cccff8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

If an allocation larger than 1 GB is made from a generation memory  
context, and the allocation is later freed, don't try to reuse the  
block for smaller allocations later.  The problem is that the standard  
layout for a MemoryChunk cannot represent cannot represent an offset  
larger than 1 GB (MEMORYCHUNK_MAX_BLOCKOFFSET) from the beginning of  
the block, so if MemoryChunk is carved from the very end of the larger  
block, the offset stored in the memory chunk overflows.  That leads to  
memory corruption.  
  
Backpatch to version 15, where the reuse of blocks was introduced,  
although the segfault is only reproducable on version 16 onwards.  
Version 15 used a custom GenerationChunk struct which didn't have the  
overflow risk that the MemoryChunk struct used in later versions has.  
  
Reported-by: Jayden Sarveshkumar <jayden@verialabs.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: v15  
Security: CVE-2026-116328  

commit   : b33b48031652cd832bc6d842aa03e87480ba45a2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

A CaseTestExpr or internal Param represents the value of an expression  
somewhere else in the query.  If that expression contains a Var then  
there is potential for information leakage.  Therefore, teach  
contain_leaked_vars() to reject such cases.  
  
In principle we could try to find the referenced expression and  
perform a more accurate analysis, but that seems not worth the  
substantial work required, because in most real-world cases  
there'd be a Var there anyway.  
  
Reported-by: Only see myself <1950233439@qq.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116327  

commit   : e9f1793720125e47cc7a2c5884a59966ad11d1c6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

PL/Perl decides whether Perl threw an error by testing SvTRUE(ERRSV).  
If the thrown value is an object whose class overloads "bool", that  
runs user-supplied Perl code.  There is no eval{} in scope at some of  
these tests, so if that code throws in turn, Perl writes the message  
to stderr and exits the backend, not the behavior we want.  
  
To fix, don't ask Perl at all in the case that matters.  Any reference  
is true regardless of what its class claims, so a thrown object is an  
error by definition, while overloading cannot apply to a non-reference.  
Add errsv_is_true() to encapsulate that and replace tests of ERRSV  
with that.  
  
Also, consider the possibility that trying to stringify ERRSV throws  
an error, which can also be arranged with a hostile object definition.  
That risks an infinite loop in PG_PERL_TRY, so install code to prevent  
repeating such a loop.  
  
Lastly, stringify ERRSV outside our ereport() calls not inside.  If we  
do it inside then a thrown Perl error temporarily leaks an errordata[]  
slot for the unfinished ereport.  While it's not clear that this makes  
it possible to overrun ERRORDATA_STACK_SIZE, it seems best to avoid  
the leak.  
  
Reported-by: Dwij Mehta <dwijimehta@gmail.com>  
Author: Andrew Dunstan <andrew@dunslane.net>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116326  

commit   : f2f1fd38f663663fcce2122f7bc57e884a6ddadc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Commit ebdefb93b arranged to run plperl_return_next_internal()  
in a temporary memory context that got reset at the end of each  
call, so as not to accumulate lots of leaked memory in a PL/Perl  
function that returns many rows.  But this arrangement is unsafe  
because re-entrant calls of return_next are possible, as shown  
by the new regression test.  In that case the inner call's reset  
destroys data the outer call still needs, leading to crashes.  
Instead, just create and delete a temp context for each call.  
That works correctly in the nested case, and in the normal case  
it's not really much slower than the old way thanks to the context  
recycling logic in aset.c (which long postdates ebdefb93b, but is  
in every still-supported branch).  
  
Reported-by: Anthropic OSS program  
Author: Anthropic OSS program  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116319  

commit   : b9ad255648fc96a3c4c8d9a64bb751949249abb6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Previously we assumed that the object would stick around while we  
examined it, but there are a few ways that the last refcount could get  
dropped meanwhile, allowing the object to be recycled and creating a  
use-after-free hazard.  To prevent that, we must acquire our own  
refcount and release it when we're done.  The tricky part is to ensure  
that the refcount gets released if an error is thrown partway through.  
A TRY/FINALLY block would work, but that answer would be expensive  
and notationally invasive.  The method used here is to push a  
refcount-carrying RV onto Perl's temporaries stack so that temporaries  
cleanup will release the reference.  A simple benchmark suggests that  
that adds just a couple percent of overhead, which seems acceptable.  
  
The first draft of this patch was created by Anthropic's OSS program.  
  
Reported-by: Anthropic OSS program  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Co-authored-by: Anthropic OSS program  
Backpatch-through: 14  
Security: CVE-2026-116320  

commit   : 7db7244ee9d11e4f95aa4dccea664895beae806a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

An error thrown from a tied array, hash, or scalar may occur while  
PL/Perl is trying to return a function value, in which case we are  
outside the call_sv() execution loop that would normally handle  
trapping of Perl errors.  That is problematic: if Perl doesn't think  
it is inside an eval-like context, it will bleat on stderr and then  
exit(); while if it does think that, it will longjmp out to some outer  
level of Perl execution, which wreaks havoc.  We need to keep Perl's  
jmp_buf stack in sync with Postgres', so that we never have a situation  
where one of those stack pointers points above the function level the  
other stack was just used to jump out to.  
  
The core idea of this fix is to replace PG_TRY blocks within PL/Perl  
with "PG_PERL_TRY" blocks, which have fundamentally the same semantics  
as PG_TRY, but establish new jmp_buf levels within both stacks and pop  
both correctly at exit.  If a Perl error is caught using Perl's stack,  
we'll convert it to a Postgres error using logic similar to what  
PL/Perl uses for the purpose elsewhere.  
  
This simple core idea has some complications though.  One big one  
is that since PG_PERL_TRY adjusts the state of the current Perl  
interpreter, we must make sure that we don't switch interpreters  
partway through the block.  Which the old code did freely.  
To fix that without adding more TRY blocks than necessary, refactor  
the contract between plperl_call_handler and its sub-handlers  
(plperl_func_handler et al) so that we look up the target function and  
switch to the associated interpreter before we enter the sub-handler.  
  
I also spent a deal of effort on tightening the error-condition  
guarantees for select_perl_context and plperl_init_interp, as per the  
changes to their header comments.  As they stood, it was really hard  
to say anything about what state would be left behind after a failure  
during Perl interpreter creation, which cascaded into not being able  
to promise anything about what would happen in their callers.  
  
Within PG_PERL_TRY, there are more problems.  Aside from just pushing  
a new jmp_buf stack level (handled by JMPENV_PUSH/JMPENV_POP), we must  
see to it that if control does reach Perl_die then it will choose to  
longjmp() rather than summarily exit().  At least in Perl 5.40, there  
are two gating tests: PL_in_eval must be nonzero (preferably with the  
EVAL_INEVAL bit set), and S_dopoptoeval must find a CXt_EVAL context  
on the PERL_CONTEXT stack.  We could hack PL_in_eval directly, but  
there's no direct way to manipulate the context stack.  The solution  
used here is to execute OP_ENTERTRY and then (if a longjmp didn't  
happen) OP_LEAVETRY.  That requires manually saving/restoring PL_op,  
as well as ERRSV, but otherwise seems to work fairly well.  
  
Another interesting bit is that if possible, we create only one jmp_buf  
struct and link it into both error stacks.  It'd be cleaner to keep  
the two mechanisms entirely separate, but that would require two  
sigsetjmp calls in close proximity, which turns out to break clang's  
optimizer quite thoroughly.  We do get the small benefit of saving the  
cycles that would go into a second sigsetjmp call.  A complication is  
that we need to be able to figure out whether a caught longjmp was  
triggered by Perl or Postgres.  We do that by adding some state in  
elog.c so that we can tell whether the topmost error data is complete  
or not.  If it isn't, then the error was thrown by Perl.  (An example  
where this distinction matters is that the sv2cstr calls used in  
plperl.c's own ereports could throw Perl errors, at a point where we  
are still filling in a Postgres error.)  Ideally this state would be  
carried by a new flag in ErrorData, but to avoid an ABI break in  
stable branches, hide it inside elog.c for now.  
  
However, we can't use that trick on MinGW-64, because there we use  
gcc's __builtin_setjmp() while Perl uses MinGW's plain setjmp().  
So in that case, resort to managing the jmp_buf stacks separately.  
  
Reported-by: Ngoc Trần <anbas1342@gmail.com>  
Reported-by: Anthropic OSS program  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116326  

commit   : 8b3a668b111b9a20955692efd1eca70373dc7679    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Up to now, if you passed a "tied" object to a PL/Perl operation,  
it would most likely get treated as "undef", since we failed to  
perform get magic on values we're passed.  Tied hashes worked  
partially, in that you could read out their keys, but the values  
always read as undef.  
  
To fix, use hv_iterval() not HeVAL() to fetch values from perl  
hashes, and be careful to apply plperl_materialize_sv() before  
testing SvOK() or SvROK() on any perl SV.  
  
Add regression test cases exercising some typical usage scenarios  
for tied objects.  
  
This is a back-patch of commit ccab6d36d.  The original intent was  
for that to be master-only on the grounds that it wasn't worth  
the risk to back-patch.  However, we now realize that there are  
several security issues around tied Perl objects, some of which  
are reachable even without this fix.  Having to test different  
behaviors in master and back branches doesn't seem like a good  
plan, so as a first step do this to make the branches more alike.  
  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us  
Backpatch-through: 14-19  
Security: CVE-2026-116326  

commit   : c0ac961cef29411fe60c5f0b576d0b7b2fdbc7c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

When pltcl invokes a SQL datatype input function, it was passing a  
string that is owned by the Tcl interpreter.  This is hazardous  
since the input function could re-entrantly call the same Tcl  
interpreter (for example, via a pltcl function in a domain check  
constraint), and that call could modify or free the string we're  
depending on.  Avoid the hazard by ensuring that we've pstrdup'd  
whatever Tcl returned.  
  
In all of these call sites, there's no great need to worry about  
pfree'ing the extra string immediately, since we're either inside a  
short-lived subtransaction or about to return from the pltcl function.  
So I didn't complicate the code by doing that.  
  
Reported-by: Anthropic OSS program  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116323  

commit   : 6ca1c604cb92e05a912fc8b72963dd7cc8346d1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

Although type "name" is of length NAMEDATALEN, we must not allow the  
last byte to become nonzero.  Otherwise, operations that treat it as  
a C string will read off the end, resulting in crashes or disclosure  
of server memory.  array_set_element() failed to enforce this.  
  
Another bad outcome of element assignment could be to construct an  
invalidly-encoded multibyte character.  Check that too while we're  
at it.  
  
Ideally we'd extend array_set_element()'s API to pass the array type  
OID, but that's infeasible in released branches, and it seems not  
worth the trouble even in master given the tiny usage of fixed-length  
array types.  Instead just test for elmlen == 1 && arraytyplen ==  
NAMEDATALEN to decide whether it's a name.  
  
Reported-by: Anthropic OSS program  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 14  
Security: CVE-2026-116321  

commit   : 44a414c992ce86a4e89d005381d8cc82353e91ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

get_docrep() assumed there could be no more QueryItems per group  
than there are lexemes in the input tsvector.  That's true with valid  
tsvector input, which will never show duplicate positions for any  
lexeme.  But with duplicate positions it's possible to overrun the  
allocated space.  Guard against that by dropping items if there are  
more than we expect (it doesn't seem worth working harder than that).  
  
The submitted test case that reached this constructed an invalid  
tsvector by dint of starting with one, namely a tsvector containing  
a zero position, which tsvectorrecv() failed to prevent before  
10cc5aa96.  It's not clear whether the problem is reachable without  
that.  
  
Reported-by: Anthropic OSS program  
Author: Anthropic OSS program  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116317  

commit   : 3efcadec9bf5cef345983a780407169db52bb9ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

tsvector_delete_by_indices() sized its output as VARSIZE(input) on the  
assumption that the result can never be larger, but that only holds  
when the input's lexeme data area is laid out in WordEntry order, like  
the output's will be.  With a different ordering, additional pad bytes  
could be needed for alignment of position data.  ts_type.h explicitly  
says that a different lexeme data ordering is legal, and  
tsvectorrecv() for one can produce other orderings.  To fix, use the  
same solution as tsvector_concat(): allocate one extra byte per  
output lexeme.  That's probably considerably more than enough, but  
it's not worth working harder.  
  
Reported-by: Anthropic OSS program  
Author: Anthropic OSS program  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Security: CVE-2026-116315  

commit   : 7138dcbef9d336b70d2a668859e70c10b8e36c2c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

get_perl_array_ref() used sv_isa(sv, "PostgreSQL::InServer::ARRAY") to  
recognize PL/Perl's own array wrapper objects, then cast SvRV(sv) to  
HV * and looked up the "array" key.  But sv_isa() only reports which  
package a reference was blessed into, and blessing is an unprivileged  
Perl operation that constrains nothing about what is blessed.  A  
function in trusted plperl could therefore return  
  
	my $x = "hi"; return bless \$x, 'PostgreSQL::InServer::ARRAY';  
  
whereupon hv_fetch_string() would read a hash bucket array out of the  
body of a plain scalar and dereference it.  Since plperl is trusted,  
any role with CREATE on a database can reach this.  
  
Fix, per a suggestion from Tom Lane, by requiring SvTYPE(SvRV(sv)) to  
be SVt_PVHV before consulting sv_isa().  A reference blessed into that  
package but pointing at anything else now falls through to the caller's  
existing handling for other references, which looks through the  
reference; the example above fails with "malformed array literal".  Add  
a regression test next to the existing forged-object case.  
  
It's not clear if this is exploitable, but out of an abundance of  
caution we treat it as if it is.  
  
Reported-by: Zheng Yu <zheng@depthfirst.com>  
Backpatch-through: 14  
Security: CVE-2026-116309  

commit   : 0f9f20c36a9aae40a34f5650a166213ba5545562    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:55 -0800    

appendPQExpBuffer() was accidentally used instead of  
appendBinaryPQExpBuffer() in pg_basebackup.  The former would  
interpret the string to be appended as a format string, which could  
lead to misbehavior.  (The string contents are related to backup  
manifest contents.  Those do not normally contain any data that could  
look like a format placeholders.  In order for this to misbehave,  
files with unusual names would have to exist in the data directory.)  
  
- The hunk in ReceiveBackupManifestInMemoryChunk() is from commit  
  0d8c9c1210c, 2020, PG13.  This is only reachable against a pre-PG15  
  server, because of the next item.  
  
- The hunk in ReceiveArchiveStreamChunk() is from commit cc333f32336,  
  2022, PG15.  
  
Security: CVE-2026-16240  
Backpatch-through: 14  

commit   : f2770328b79aadafef4cbe97dcce5d2d6e7e1504    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:25:21 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:25:21 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 41982d7b270a0a4205266d757e94bfc630a47a8f  

commit   : fa3f3dde3c24c2b2d5966ffc72a6dc00287dd492    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Nov 2026 16:41:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Nov 2026 16:41:09 -0500    

commit   : 21a53865fb5a199fc7f234a9f9fce5608a39e581    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 6 Nov 2026 20:18:18 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 6 Nov 2026 20:18:18 +1300    

An aggregate's ORDER BY can list the same sort key more than once with  
different sort operators, and transformDistinctClause() copies such  
items into the DISTINCT list.  So an aggregate with a single input can  
have several sort keys and several DISTINCT columns.  
  
nodeAgg.c and execExpr.c mistakenly only checked the number of inputs  
when deciding if a Datum sort was possible.  That check must also  
consider the number of sort keys.  
  
Fix by using the Datum sort only for a single input with a single sort  
key.  
  
Also for v16+, fix crash in pre-sorted aggregate code where the uniqslot  
was only created when the number of inputs for a DISTINCT aggregate was  
above 1.  The uniqslot is required when there are multiple DISTINCT  
columns, and an ORDER BY clause may cause more than one of these to exist  
when there's only a single input column.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAJTYsWXMuo5QZSy_az+86mty2XdbDw_7uB3C4FjWpFACvD_rzg@mail.gmail.com  
Backpatch-through: 14  

commit   : 557df4b2ce18efda1b31a89e68f669330e0b93df    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:47 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:47 -0800    

Describe the effects of removing the builtin plugins from  
output_plugin_libraries. It may not be obvious to DBAs why they might  
want to keep those in the allowlist, since it wasn't previously possible  
to pick and choose plugins without modifying the Postgres installation  
itself.  
  
Reported-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAOYmi%2Bmt5bcV6B0DZR-t1tfpX8wjk8Aj%2BftEd%3DxXuH5qege2%2BQ%40mail.gmail.com  
Backpatch-through: 14  

commit   : d0571ca1609e4cb6c9d31c7137b67e4002641fa6    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:46 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:46 -0800    

I omitted explicit syntax validation of output_plugin_libraries in  
226e49cbed. [ALTER SYSTEM] SET does this implicitly due to the parser  
grammar, but a DBA could still accidentally put a bad value into  
postgresql.conf, and a superuser could do the same with connection  
options or set_config(). Logical replication would then fail later on.  
  
This is an annoying papercut for a security option to have, so reject  
these cases immediately in a check_hook.  
  
Tests by Hayato Kuroda.  
  
Co-authored-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/CAOYmi%2BkBsG5rNRb1j2VjgTKg8HY90e7vSvZPLeouiAc6nXP9XA%40mail.gmail.com  
Backpatch-through: 14  

commit   : 10686da4eddb5f37ecb1a3467c1c411cd1c84003    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 5 Nov 2026 13:00:43 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 5 Nov 2026 13:00:43 +0100    

The numrange_subdiff() function was calculating the difference simply by  
calling numeric_sub and numeric_float8, but those functions are not  
overflow-safe. It's possible to insert valid numeric ranges for which  
the difference overflows either numeric or float8.  
  
The overflow may affect various operations on numrange columns. It may  
cause failures during ANALYZE on the table, inserts into GiST indexes,  
selectivity estimation, and possibly other operations.  
  
Fixed by handling overflows in numrange_subdiff() - extreme differences  
are treated as infinity.  
  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: shihao zhong <zhong950419@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CALdSSPgBvXz-VSF0p-5k%3D_uFfN38cWrERmm_AC4K67N6MWQhmg%40mail.gmail.com  

commit   : 861a9c4026e6c99fbb589d20fe0b9304ef99433c    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:15:37 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:15:37 +0900    

For INSERT ... VALUES with more than one row, transformInsertStmt()  
calls transformInsertRow() once for each VALUES row and once more for  
the final targetlist, and each call transformed the same raw  
indirection from the target column list.  That doesn't work for  
sublinks, because transformSubLink() replaces the raw subselect with  
its analyzed Query, so the second pass failed with "unexpected  
non-SELECT command in SubLink".  Other nodes that are transformed in  
place, such as NullTest, failed with "unrecognized node type".  
  
Fix by giving each transformation its own copy of the indirection.  
  
Claude found this issue when reviewing another bug.  
  
Discussion: https://postgr.es/m/CA+HiwqHCZLZV_20nz3fQX+1=vyFLDMbG0_3wY=QujNKZWts0nw@mail.gmail.com  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Shihao Zhong <zhong950419@gmail.com>  
Backpatch-through: 14  

commit   : 6e860511622a8f6894ae9294280b584cd98e3fdb    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 5 Nov 2026 10:21:17 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 5 Nov 2026 10:21:17 +1300    

91e9e89dc (v15) changed nodeSort.c to allow the slightly more efficient  
Datum sort method to be used when the Sort node was only outputting a  
single column.  That commit mistakenly failed to consider additional  
sort keys.  
  
This wasn't trivial to hit as adding more sort keys on another column  
would add a resjunk target entry, so Datum sort wouldn't be used.  Hitting  
this required all sort keys to be on the only output column, and then you  
might think that subsequent sort keys *could* be ignored in that case, but  
the collation for subsequent keys might differ from the first, and if the  
first sort key had a nondeterministic collation, ignoring subsequent keys  
isn't correct.  
  
Ordinary ORDER BY queries were not affected by this as repeating the same  
column in the ORDER BY clause with different collations would lead to  
additional redundant target entries and would have failed the one-column  
requirement to enable the Datum sort optimization.  The only known case  
where problems could occur was sorting for the presorted aggregate  
optimization added in 1349d2790 (v16).  
  
A query such as the following would trigger this issue if the "x" column  
was defined with a nondeterministic collation as the presorted input  
would arrive at the aggregate only presorted by 'x' (using its  
nondeterministic collation), rather than 'x, x COLLATE "C"':  
  
SELECT count(DISTINCT x COLLATE "C") FROM t GROUP BY x;  
  
This could lead to COUNT(DISTINCT) returning a count higher than the actual  
number of distinct values according to the "C" collation.  
  
Fix this by only using the Datum sort optimization when there's 1 output  
column and 1 sort key, rather than just checking for 1 output column.  
  
Reported-by: Nidal FAKIH <nidal.fakih@soptimal.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/c6790a7b-7c10-4baf-9c8f-b404420c63f9@soptimal.com  
Backpatch-through: 15  

commit   : 2c48710934728bc65e418bcc9ebdc88f490416ff    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 4 Nov 2026 19:45:44 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 4 Nov 2026 19:45:44 +0000    

At transaction level SERIALIZABLE, commit fb60892f403 made  
check_exclusion_or_unique_constraint() read the conflicting tuple  
again using estate->es_snapshot when violationOK is true and  
conflictTid is non-NULL, to ensure that INSERT ... ON CONFLICT takes  
an SIREAD lock. This can only happen from ExecCheckIndexConstraints(),  
but not all callers of ExecCheckIndexConstraints() initialize  
estate->es_snapshot, and the re-fetch crashes if it's invalid.  
  
In core Postgres, this only affects the logical replication apply  
worker which, starting from v18, uses ExecCheckIndexConstraints() to  
log conflicts while applying changes, without initializing es_snapshot  
in the EState that it builds. However, there is also extension code  
that does the same, so the problem affects all versions that  
fb60892f403 was applied to.  
  
Fix by skipping the re-fetch in check_exclusion_or_unique_constraint()  
if the snapshot is invalid.  
  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CAN4CZFPz4ysPyo1ahD-5n0iyKxmuo2Wvn%3DPgEZTyW63_Tu7Eaw%40mail.gmail.com  
Backpatch-through: 14  

commit   : b68d0a85c682e0402f87fa38d89d52e3539b8b27    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Nov 2026 18:30:06 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Nov 2026 18:30:06 +0900    

We call ExecAppendAsyncEventWait with as_syncdone=true, which forces it  
to wait until at least one event occurs, ensuring it never polls.  
  
Oversight in commit f57df2068.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Discussion: https://postgr.es/m/CAPmGK1648ovA1i_4X%2BvO%3DCi%2BkSpvvG0H9jcb2m4inybXtSyw6A%40mail.gmail.com  
Backpatch-through: 14  

commit   : 3cb89e214b428bca09eb8de9afd1401d392e2977    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:51:59 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:51:59 +0900    

Currently, ri_FetchPreparedPlan() immediately frees a cached SPI plan  
if SPI_plan_is_valid() returns false, without tracking whether the  
plan might be in use.  That can cause _SPI_execute_plan() to read  
freed memory.  This happens, for example, when an RI check's or  
action's query runs some user-defined code such as a cast function or  
BEFORE ROW trigger function which may perform its own DML using its  
own query that is not restricted from firing its own triggers, some  
of which may be RI triggers for the same constraint as the outer RI  
check and hence use the same cached plan.  If an invalidation arrives  
that marks the cached plans referenced by the outer check's SPI plan  
invalid between the outer check having called _SPI_execute_plan() and  
the inner check's ri_FetchPreparedPlan(), the latter will free the  
SPI plan as mentioned above.  
  
Lucas Jeffrey reported an instance of this bug involving a  
self-referencing ON DELETE CASCADE foreign key.  The RI action's  
DELETE fires a BEFORE DELETE trigger on the rows it deletes, which  
invalidates the action's plan with GRANT and REVOKE on the table and  
then runs a DELETE of its own, and the RI action fired by that DELETE  
is the inner check described above.  Separately, Tom Lane reported  
that buildfarm member trilobite, which runs with CLOBBER_CACHE_ALWAYS,  
hit this in the regression tests on master after a change there made  
more FK checks go through SPI.  
  
Fix by keeping a stack of the plans that every ri_PerformCheck() call  
in progress is executing, pushed before SPI_execute_snapshot() and  
popped whether it returns or throws an error, the latter using  
PG_FINALLY().  ri_FetchPreparedPlan() now frees an invalid plan on the  
spot when it is not on that stack, as before, since nothing can be  
executing it.  Otherwise it only detaches the plan from its hash entry  
and queues it on a list.  Whenever a check finishes, the queued plans  
that are no longer on the stack are freed.  So a plan is held only  
while a check is actually executing it, however many invalidations  
happen meanwhile.  A new AtEOXact_RI() frees whatever is left.  
  
Add the test from Lucas's original patch, which reproduces the crash  
on an ordinary cassert build, and a test that raises errors from  
inside a check's query, some of them inside subtransactions that are  
then rolled back, to check that the stack stays exact.  
  
Author: Lucas Jeffrey <lucas.jeffrey@anachronics.com>  
Co-authored-by: Trakshan Mishra <trakshanmishra477@gmail.com>  
Co-authored-by: Amit Langote <amitlangote09@gmail.com>  
Reported-by: Lucas Jeffrey <lucas.jeffrey@anachronics.com>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/3043944.1792163844@sss.pgh.pa.us  
Discussion: https://postgr.es/m/CAGHzy7S0XfXdK3amd5c4QhpS1o9dySVzPr+-d9ohaE4iV_vNog@mail.gmail.com  
Backpatch-through: 14  

commit   : 2117bdccfffe2e809f396cb14a4812bb66f6ec6d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Nov 2026 11:18:49 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Nov 2026 11:18:49 +0900    

Commit 911e7020770, which added configurable signature lengths,  
introduced an error in how gist_trgm_ops index entries are combined.  
Some entries could lose the flag identifying their format, causing  
later inserts to treat them as empty and lose information about  
existing entries.  As a result, queries using these indexes could  
miss matching rows.  
  
Fix this by preserving the format flag when combining index entries,  
so that subsequent inserts correctly retain the information they  
represent.  
  
This fix does not repair existing indexes.  Users should REINDEX all  
existing gist_trgm_ops indexes after upgrading to a release containing  
this fix.  
  
Backpatch to all supported versions.  
  
Author: Nate Clark <natec425@gmail.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19720-b3e83f5e99c485c5@postgresql.org  
Backpatch-through: 14  

commit   : 8b04cc817f7255ba8a9ad306678bf0dde900a1cc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Nov 2026 11:16:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Nov 2026 11:16:44 +0900    

Commit 3f1ce97346 introduced a circular buffer for decoded WAL records,  
with separate allocations for records that do not fit in the buffer.  
However, XLogReaderFree() did not release separately allocated  
records remaining in the decode queue. In particular, the last record  
returned by XLogReadRecord() remains queued until released, so freeing  
the reader could leak that record.  
  
For many callers, the leaked memory is reclaimed when the containing  
memory context is reset or deleted. However, it can accumulate in  
long-lived contexts. For example, when checkpointing prepared  
transactions, XlogReadTwoPhaseData() creates a WAL reader, reads the  
PREPARE record, and frees the reader. Large PREPARE records can  
therefore leave allocations in checkpointer_context, which is not  
reset during normal operation. These allocations accumulate until  
an error resets the context or the checkpointer exits.  
  
Fix this by calling ResetDecoder() in XLogReaderFree() to release all  
separately allocated records in the queue. Do this before freeing the  
decode buffer, since the queue can also contain records stored in that  
buffer.  
  
Backpatch to v15, where the circular WAL decoding buffer was  
introduced.  
  
Author: Tomás Senart <ts@perfloop.ai>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAEEBa3Uai8TGPd6P5SX_fzbu3KHMwSvu9WuqA8JPSPQ1RJR8fQ@mail.gmail.com  
Backpatch-through: 15  

commit   : 2da9b7f9b22dbcc64bffeab3612fc9f3ca063db9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 4 Nov 2026 13:43:17 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 4 Nov 2026 13:43:17 +1300    

When building Memoize cache keys from a parameterized path's join clauses,  
paraminfo_get_equal_hashops() used the outer side expression of each  
clause verbatim, which meant the cache was hashed and probed using that  
expression's collation rather than the input collation of the join  
condition.  
  
If the expression's collation is nondeterministic and the clause compares  
using a different collation, values that the clause can distinguish, such  
as 'abc' and 'ABC' under a case-insensitive collation, could be treated as  
equal by the cache.  This could cause a lookup to return the cached  
results for another value, giving wrong query results.  
  
Here we fix this by relabeling the cache key expression with the join  
clause's input collation, so that cache lookups match values the same way  
as the join clause does.  
  
Author: shihao zhong <zhong950419@gmail.com>  
Reviewed-by: Manu <manuelreyesbravo@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAGRkXqTBsBegZ8rNMYjwkeu1V5wRQ06zR6jTVickqP_3E7mb8g@mail.gmail.com  
Backpatch-through: 14  

commit   : c859616f14b54d00320b11f51721a2b6b5009adc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 15:05:01 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 15:05:01 +0900    

Several documented function signatures used parameter names that  
differed from the registered SQL names, causing named-argument calls  
using the documented names to fail. Update the signatures and  
corresponding descriptions to use the SQL-visible names, without  
affecting existing calls.  
  
Backpatch to all supported versions, except for the changes to  
pg_logical_emit_message and pg_input_error_info, which are  
backpatched through v17 and v16, respectively.  
  
Reported-by: Mi cro <micro6947@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19D9D4CB-8C31-493E-982A-1E17042D68C5%40gmail.com  
Backpatch-through: 14  

commit   : f556e297d164981ab91d65c06200bc182cb804c3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 14:58:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 14:58:56 +0900    

The sequence catalog column of information_schema.routine_sequence_usage  
is named sequence_catalog in the view definition, but the documentation  
previously called it schema_catalog.  Correct the documented column name  
to match the view.  
  
Backpatch to all supported versions.  
  
Reported-by: Mi cro <micro6947@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/179342977864.1246.4971529844925475150@wrigleys.postgresql.org  
Backpatch-through: 14  

commit   : 3ec98353523b98c47a0b901ea43b25e7fe55eb17    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:51:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:51:05 +0900    

Commit 3f1ce97346 introduced a circular WAL decoding buffer,  
allowing records to be decoded before they are consumed. However,  
decoding error messages continued to report the location of the last  
record consumed instead of the record that failed decoding. With  
recovery prefetching, the reported location could be many records  
behind the failing record, making WAL problems harder to diagnose.  
  
Fix this by reporting the location of the record being decoded.  
Errors now identify the failing record even with recovery prefetching,  
making it easier to investigate malformed WAL during recovery or with  
tools such as pg_waldump and pg_walinspect.  
  
Backpatch to v15, where the WAL decoding buffer was introduced.  
  
Author: Rahul Yadav <rahul@rhyadav.dev>  
Reviewed-by: Surya Poondla <suryapoondla4@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/P2qIkq4--F-9@rhyadav.dev  
Backpatch-through: 15  

commit   : 025dac1c92cfa1158e54ccd7fea74f3bb7133b24    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 3 Nov 2026 09:50:13 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 3 Nov 2026 09:50:13 +0900    

Commit 708eb5158 made each PARAM_EXEC Param buried inside a larger  
Memoize cache key expression a cache key by itself, and, in master  
only, commit f8da64e6d extended that to the Params in the memoized  
relation's base quals, targetlist and join clauses.  Both meant to  
catch Params supplied by an outer query level, but they took every  
PARAM_EXEC Param they found, including the output Params of initPlans  
and SubPlans.  
  
When an initPlan's output Param is made a cache key, it is evaluated  
on every cache probe, which runs the initPlan even where the query  
doesn't need it, such as in a CASE arm that is never taken, and can  
raise an error the query shouldn't raise.  A SubPlan's output Params  
have a value only while the SubPlan evaluates its testexpr, so making  
a cache key of one fails with "plan should not reference subplan's  
variable".  
  
To fix, make cache keys only of the Params listed in some outer query  
level's plan_params, as those hold values supplied by outer levels and  
are always safe to evaluate.  Any other Param is left to purge the  
cache when it changes.  
  
Back-patch to all supported branches.  
  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwHdaau1KooFbY10=MDhKtFVgpmPrDiwNpEe6bWu7wpQYA@mail.gmail.com  
Backpatch-through: 14  

commit   : 8681aef6fd2028185c19daad0d529e0b250589b7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Nov 2026 01:39:20 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Nov 2026 01:39:20 +0200    

A checkpoint starting between the CREATE_ID record and the SLRU update  
could lose the multixact after a crash.  
  
Author: shihao zhong <zhong950419@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAGRkXqSuiJ_X4+Z6rsD42pcuACnD9PhoQ-Os+mUJNmJarBWkNg@mail.gmail.com  
Backpatch-through: 14  

commit   : 6a770f537fcebc0fb7276c676223abdca96dd5e1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 2 Nov 2026 21:49:28 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 2 Nov 2026 21:49:28 +0100    

The distance function for tid values maps item pointers to float8 as  
  
  (block * MaxHeapTuplesPerPage + offset)  
  
but the multiplication was done in uint32 arithmetic, so for high block  
values (above 14759338, ~112GB) the result wrapped around. The distance  
would then be very inaccurate (possibly negative), resulting in a less  
efficient index.  
  
Fix by doing the arithmetics in double.  
  
It's also possible the (user-supplied) item pointers have offsets  
greater than MaxHeapTuplesPerPage, confusing the mapping to double  
value. This commit does not try to address that, it's not clear what  
would be a better mapping.  
  
Author: Tomas Vondra <tomas@vondra.me>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CALdSSPgBvXz-VSF0p-5k%3D_uFfN38cWrERmm_AC4K67N6MWQhmg%40mail.gmail.com  

commit   : b8d5b9a0115f531f1a4627a2e4f97ea04ae906b9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 2 Nov 2026 20:09:59 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 2 Nov 2026 20:09:59 +0100    

When calculating the distance between numeric values, the code could  
overflow in two ways. A subtraction of two finite values may still  
overflow, or the result may not fit into float8.  
  
The distances don't need to be perfectly accurate, although it may make  
the index less efficient. And for most minmax-multi opclasses it works  
like that, but for numeric the functions may error-out. That prevents  
summarization, either when creating an index or later during vacuum.  
  
Fix by using numeric_sub_safe() and numeric_float8_no_overflow(), and  
returning infinity when either of those fails. The older releases need  
to use numeric_sub_opt_error(), but the principle is the same.  
  
Also, handle NaN values the same as for float4/float8. When both values  
are NaN, return distance 0. When one value is NaN, return infinity.  
  
While at it, free the detoasted copies of arguments, and the calculated  
numeric distance. For small values it does not matter, but for extreme  
numeric values it may make a difference.  
  
Reported by Kirill Reshke, with a patch fixing the issue. Various  
improvements and backpatching by me.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Author: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: shihao zhong <zhong950419@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CALdSSPgBvXz-VSF0p-5k%3D_uFfN38cWrERmm_AC4K67N6MWQhmg%40mail.gmail.com  

commit   : a3d1ac49561b49e640767b65537110d5087d4017    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 2 Nov 2026 10:13:52 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 2 Nov 2026 10:13:52 -0600    

ExecForceStoreHeapTuple() clears the slot before storing the tuple,  
which invalidates the slot's TID, but it only sets the TID again  
for slots of type TTSOpsHeapTuple.  Besides producing wrong query  
results, this can lead to data corruption if an affected tuple is  
locked (e.g., via SELECT ... FOR UPDATE).  To fix, set the slot's  
TID for the other kinds of slots, too.  
  
Oversight in commit b8d71745ea.  
  
Author: Virender Singla <virender.cse@gmail.com>  
Co-authored-by: Greg Burd <greg@burd.me>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Tested-by: Shihao Zhong <zhong950419@gmail.com>  
Discussion: https://postgr.es/m/CAM6Zo8wZOLnCWRO_tuuXVX9J4N4JN6GsEnk8WJtT0%3D_0zy-1dw%40mail.gmail.com  
Discussion: https://postgr.es/m/0498c10f-839b-4f68-9994-c29b454e55a4%40app.fastmail.com  
Backpatch-through: 14  

commit   : 06428115017157753b145b890c779043012a9ffa    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 15:42:37 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 15:42:37 +0900    

Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/179087936257.78721.1170374394656748858@mail.gmail.com  
Backpatch-through: 14-18  

commit   : a39ec399e37b1254fcc058d82f5b35cc23951790    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 15:18:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 15:18:17 +0900    

ROLLBACK PREPARED flushes its abort record and then updates pg_xact.  
Nothing prevented a checkpoint from setting its redo pointer between  
these two steps.  A crash before the removal of the 2PC state file would  
then cause recovery to begin after the abort record and would restore  
the transaction as prepared, even though its rollback has been  
aknowledged.  Standbys could for example replay the abort record, and a  
follow-up COMMIT PREPARED on a primary could make them flip a  
transaction from aborted to committed.  
  
Losing an abort is harmless for a regular transaction, but not for a  
prepared transaction whose 2PC state file is still on disk.  This issue  
is fixed by setting DELAY_CHKPT_START (delayChkpt in v14) around the  
abort record and the pg_xact update, as done for COMMIT PREPARED.  
  
This issue exists since the introduction of 2PC, since d0a89683a3a4.  
  
Author: Shihao Zhong <zhong950419@gmail.com>  
Discussion: https://postgr.es/m/CAGRkXqRhpq=fd8Qf_-Ki1OW7b1iL+o3YuHiHQhLw5RUJy2JGXQ@mail.gmail.com  
Backpatch-through: 14  

commit   : f5b8f05ee960ae5e534a56b8b7e4164a06db92ff    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 14:40:19 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 14:40:19 +0900    

The same SubPlan can appear more than once in a plan tree.  For  
example, when an equivalence class has a constant member containing a  
SubPlan, each derived "member = constant" clause references that  
SubPlan; a hash join's hash keys and its hash clauses can both contain  
it; and extract_restriction_or_clauses() can copy it into a new  
restriction clause while leaving it in the original join clause.  Each  
reference gets its own SubPlanState, with its own hash tables, but  
they all share the subplan's PlanState.  
  
A hashed SubPlan whose subquery references outer query levels must  
rebuild its hash tables whenever those parameters change.  
ExecHashSubPlan() detected that by checking chgParam of the subplan's  
PlanState.  But buildSubPlanHash() rescans that PlanState, which  
clears its chgParam, so after one SubPlanState had rebuilt its hash  
tables, the others no longer saw the change and kept probing hash  
tables built for previous parameter values, producing wrong query  
results.  
  
To fix, give each SubPlanState its own flag to mark its hash tables as  
stale.  ExecReScan() sets it, alongside propagating chgParam to the  
node's subplans, ExecHashSubPlan() checks it instead of the subplan's  
chgParam, and buildSubPlanHash() clears it.  The new field fits into  
existing padding in SubPlanState, so this does not change the struct's  
size or the offsets of its other fields.  
  
Reported-by: Samuel Olaoye <dapsalmy@gmail.com>  
Author: Rahul Yadav <rahul@rhyadav.dev>  
Reviewed-by: Alexandra Wang <alexandra.wang.oss@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: shihao zhong <zhong950419@gmail.com>  
Discussion: https://postgr.es/m/179087936257.78721.1170374394656748858@mail.gmail.com  
Backpatch-through: 14  

commit   : a7a2cab5744741ccfd8124394be1ba31ab005f64    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 10:32:52 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 10:32:52 +0900    

ExecReScanMemoize() purges the whole cache only when a Param changes  
which is not part of the cache key; a change to a cache-key Param is  
assumed to be handled by looking up a different cache entry.  To that  
end, create_memoize_plan() put every Param appearing in the cache key  
expressions into keyparamids.  That assumption holds only when the  
cache key values determine the Param's value.  
  
It fails for an upper-level Param which is buried inside a larger  
cache-key expression and also appears elsewhere in the subplan.  With  
a cache key of "t2.hundred + t0.ten" and a filter "t1.twenty =  
t0.ten", different (t2.hundred, t0.ten) pairs produce the same  
cache-key value while the filter selects different rows, so one cache  
entry wrongly serves both.  Since t0.ten was included in keyparamids,  
the cache was never purged when it changed.  
  
Also, pull_paramids() collected PARAM_EXTERN Params too, whose numbers  
are unrelated to those of PARAM_EXEC Params.  An external Param in a  
cache key could therefore keep a change to an unrelated executor Param  
from purging the cache.  
  
To fix, put into keyparamids only the Params whose values the cache  
keys determine.  These are the nestloop Params which replace the outer  
rel's Vars in the cache keys, as the inner scan can only reference the  
outer rel through the cache keys, and, in binary mode only, a Param  
which is a cache key by itself.  In logical mode the hash equality  
operator may not distinguish values that affect the results  
differently.  Any other Param now purges the cache when it changes.  
Also make pull_paramids() collect PARAM_EXEC Params only.  
  
Purging alone would empty the cache on every rescan of the enclosing  
plan whenever a buried Param changes, even when the Param is used  
nowhere else and the old code was correct and kept its cache entries  
across rescans.  So also make each buried Param a cache key by itself,  
which puts Memoize into binary mode, so that cache entries survive  
across rescans with the same Param value.  A buried Param whose type  
can't be hashed is left to the purging, rather than giving up on  
Memoize.  
  
Back-patch to all supported branches.  
  
Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Yilin Zhang <jiezhilove@126.com>  
Discussion: https://postgr.es/m/CA+COZaAHZT7T2G2F0-drdQB+StWJxOzqeDxp=ESp+YUiy-kOaQ@mail.gmail.com  
Backpatch-through: 14  

commit   : c6cb792e8197df05883d9fcd8725d1a2491ed06e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 08:12:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 08:12:50 +0900    

The replication protocol allows options without values, but pgoutput  
dereferenced a NULL DefElem argument for parameters proto_version and  
publication_names.  A replication client was able to crash a WAL sender.  
  
This issue is fixed by reading both options with defGetString(), which  
is able to report a missing parameter cleanly.  
  
Reported-by: Brar Piening <brar@gmx.de>  
Author: Zhijie Hou <houzhijie22@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Discussion: https://postgr.es/m/19795-6d7d506133b7f062@postgresql.org  
Backpatch-through: 14  

commit   : bb0615c890e2b64d6959ac5c61bf47d206c5d70f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 31 Oct 2026 13:24:50 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 31 Oct 2026 13:24:50 +0200    

pg_identify_object() looks up the object's schema name without a lock  
on the schema, so a concurrent DROP SCHEMA can make get_namespace_name()  
return NULL, which was then passed to quote_identifier().  Report the  
schema as NULL instead, as is already done for objects that have gone  
away.  
  
Similarly, schema_to_xml() and the related SQL/XML functions look up  
the schema name without a lock on the schema, and a concurrent DROP  
SCHEMA can make get_namespace_name() return NULL, which was then  
dereferenced.  Report that the schema does not exist, or skip it when  
mapping all schemas of the database.  
  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CA+fm-RPD0m9QL8W+804SGBBxn5iFz5wn=kncaP9SkM-s4PUANw@mail.gmail.com  
Backpatch-through: 14  

commit   : a1d165d63cc8f3574882e75f8a0924544dcbe7ed    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 31 Oct 2026 11:24:22 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 31 Oct 2026 11:24:22 +0200    

posix_fadvise() returns an error code directly instead of setting  
errno. However, pg_flush_data() uses %m and errcode_for_file_access()  
to report errors without setting errno, potentially reporting an  
unrelated error. Fix this by assigning the returned error code to  
errno before reporting the error.  
  
FilePrefetch() is documented to return an errno error code on failure,  
but it returns -1 when FileAccess() fails. Fix this by returning errno  
instead.  
  
The first bug one only affects a warning, and the second doesn't have  
any effect because the only existing caller ignores the return value.  
So these are pretty harmless bugs, but let's be tidy.  
  
Author: Chao Li <lic@highgo.com>  
Discussion: https://www.postgresql.org/message-id/F1916C7A-F152-4AF3-87A9-40492D8B3670@gmail.com  
Backpatch-through: 14  

commit   : a3657b7d47ce342a780d1f30d56f72e259f69c17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Oct 2026 14:35:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Oct 2026 14:35:24 -0400    

Cuba will not fall back on 2026-11-01; they will stay on DST this  
winter (but apparently plan to revert to normal next year).  
  
Historical corrections for Brazil.  

commit   : 756cbe36c63d24a9404f7698829c75f34f741e46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Oct 2026 11:03:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Oct 2026 11:03:13 -0400    

Previously, strtoint() set errno to ERANGE on overflow but returned  
the result of casting the long value to int. When the value is outside  
the range of int, this produces an implementation-defined result that  
cannot reliably indicate the direction of overflow.  POSIX requires  
strtol() to return exactly LONG_MAX or LONG_MIN on overflow, which  
permits safe sign-testing or range-testing.  By analogy, make  
strtoint() return INT_MAX or INT_MIN on overflow.  
  
Back-patch, since future bug fixes may expect this behavior.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/A33EE17C-D014-4980-B3DD-AC51588A06EC@gmail.com  
Backpatch-through: 14  

commit   : b2ca62b1c069616302b5f9b4d1eb92cd628ea111    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:54 +0900    

When evaluating expressions (through make_build_data()) and building  
stats data for expressions (through build_expr_data()), both routines  
forgot that examine_expression() could return a NULL result, depending  
on the data generated by the typanalyze function assigned to a type.  
This would crash the server.  
  
This commit includes some tests added to test_custom_types that are able  
to reproduce all these issues with two fancy typanalyze callbacks:  
- False result with a valid stats target, for the expression evaluation.  
- False result with a valid stats target on second call, for the stats  
data build.  
  
No typanalyze callback in core have the idea to do that, and I doubt  
that anything out there has the idea to do that.  If they do, this  
switches the expression stats to fail gracefully instead of crashing,  
based on the combinations that are assumed as supported by the core  
code.  
  
This is a continuation of 3b7a6fa15720.  
  
Reported-by: Yuelin Wang <1217816127@qq.com>  
Author: Shihao Zhong <zhong950419@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/19763-14da3f96c02f07e8@postgresql.org  
Backpatch-through: 14  

commit   : 0496d85f9f086de109b06427ef72d22029312227    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 30 Oct 2026 12:31:39 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 30 Oct 2026 12:31:39 +0700    

When the centroid lies outside the query box, spg_quad_inner_consistent()  
keeps only the quadrants that contain a corner of the box.  It meant to  
test all four corners, but the last step set x back to low.x instead of  
y to low.y, so it tested (low.x, high.y) twice and never (high.x, low.y).  
  
With exact comparisons the missing corner would not matter: a box that  
does not contain the centroid lies on one side of it on at least one  
axis, so (high.x, low.y) shares a quadrant with another corner, but  
getQuadrant() compares with FPeq(), which tiebreaks to the lowest  
numbered quadrant.  
  
When a box edge lies within EPSILON of the centroid, the corner on that  
edge counts as being on the centroid's line, and (high.x, low.y) may be  
the only corner in its quadrant.  That quadrant was then skipped.  Fix  
the missing corner test.  
  
Discussion: https://postgr.es/m/CANWCAZZZpkwrX0kC4Jo6KM27J6dyBdCDir-PbjEYAS06r%3D4-ag%40mail.gmail.com  
Backpatch-through: 14  

commit   : d4a81ec05ee1bc197c780092e8cc2b41ff7fcbd9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 30 Oct 2026 15:27:09 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 30 Oct 2026 15:27:09 +1300    

The loop above from where the Assert is removed handles assigning the same  
attnum to any duplicate expressions, so asserting there are no duplicate  
attnums just after purposefully making duplicate ones isn't the correct  
thing to do.  
  
The Assert was added by a4d75c86bf, so backpatch to v14  
  
Author: BHUVAN CHILUKUTI <c.bhuvan@iitg.ac.in>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/PN0P287MB0903563C70D8E5B81912E855A7602@PN0P287MB0903.INDP287.PROD.OUTLOOK.COM  
Backpatch-through: 14  

commit   : 22cc38fd7a9be157ed61a5c821fd39e4b4dcfdf7    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Oct 2026 16:21:55 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Oct 2026 16:21:55 +1300    

It's not valid for a RelOptInfo to have a non-empty partial_pathlist  
when its consider_parallel is true.  In set_append_rel_pathlist() when  
we see the parent rel doesn't have consider_parallel set, we set that  
property to false for the child.  It is possible that the child already  
has some partial paths at that point, so we need to nullify that list as  
well as set the consider_parallel flag to false.  
  
For the reported problem case, the partial paths had been created during  
set_subquery_pathlist().  These not being empty was causing an Assert  
failure on cassert builds.  I think this could only have gone on to  
result in some wasted planner effort in non-cassert builds, but cannot  
confirm if anything worse could have happened.  
  
Bug: #19803  
Reported-by: Gowtham Reddy <gowthamdoma18@gmail.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Tested-by: Gowtham Reddy <gowthamdoma18@gmail.com>  
Discussion: https://postgr.es/m/19803-1fcc1df108c54ab6@postgresql.org  
Backpatch-through: 14  

commit   : 4b87b605bbe656fd0648dfce56ba7b7db700de8e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Oct 2026 09:44:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Oct 2026 09:44:23 +0900    

As reported by buildfarm members thorntail and billbug, both running  
SPARC, 4a92c8c29bd0 is making the base backup code unstable on such  
platforms.  
  
The only suspicion I have at this stage is a stack frame issue, pointing  
to something unrelated to 4a92c8c29bd0, that the addition of an array  
worth a size of PG_CONTROL_FILE_SIZE within perform_base_backup() is  
able to trigger.  
  
thorntail complained with a SIGBUS, pointing at misaligned access, with  
a sporadic failure.  billbug complained with a SIGSEGV (siglongjmp issue  
with PG_ENSURE_ERROR_CLEANUP perhaps?) in a more stable fashion.  
  
The code is changed to use a palloc0() instead, which should cool down  
the problem with the stack, hopefully.  Unfortunately, I could not test  
this hypothesis directly, lacking an environment able to do so.  
  
Discussion: https://postgr.es/m/auGYf3jXtzLrr4gA@paquier.xyz  
Backpatch-through: 15  

commit   : cb51daa27d875e5aaad5792112a251280527416f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Oct 2026 14:23:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Oct 2026 14:23:26 +0900    

RelationReloadIndexInfo() re-reads the mutable pg_index fields  
(indisready, indisvalid, indislive, etc.) only for indexes that are  
not system relations.  The TOAST index of a user table lives in  
pg_toast and counts as one, but REINDEX CONCURRENTLY changes these  
fields on it like on any other index.  
  
A backend that had the TOAST indexes open when the invalidation  
arrived kept indisready = false for the new index, and did not insert  
its chunks there.  Once the old index is dropped, reading such a value  
fails with "missing chunk number 0 for toast value N in pg_toast_X".  
The chunks remain in the TOAST table, only the index references were  
gone, so a rebuild of the TOAST index would fix this issue.  
  
This issue is fixed by re-reading the pg_index row for TOAST indexes,  
filling in their relcache fields.  This is the same as for an index on a  
user table.  Previouly, IsSystemRelation() was used, meaning the  
pg_index data was not re-read for a TOAST relation or a relation with a  
pinned OID (created by initdb).  This check is meant for indexes whose  
values never change, so IsCatalogRelation() is fine, implying that only  
indexes created by initdb should be skipped (REINDEX CONCURRENTLY does  
not work on catalogs).  
  
This code is as old as 8ec943856a4, and was only used for CREATE INDEX  
CONCURRENTLY.  5dc92b844e68, that has introduced REINDEX CONCURRENTLY,  
has made possible to reach the problem with TOAST indexes due to these  
getting concurrently built, validated and then swapped.  
  
A test is added, able to reproduce the issue.  It forces an insert  
before a swap, with a second session that maintains the TOAST indexes  
open while the new index becomes ready.  This has been slightly  
simplified by me compared to what the author has sent.  
  
Oversight in 5dc92b844e68.  
  
Reported-by: Saicharanreddy Chinthareddy <saicharh@amazon.com>  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CALj2ACUAv=7wjOV3pRFhQP4WHME_JazuhoCr01i4_F2XA=JKog@mail.gmail.com  
Backpatch-through: 14