PostgreSQL 14.25 commit log

commit   : 9adcf5f8847e0f485a390b1d3ea40688068d71bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 15:16:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 15:16:32 -0500    

commit   : 1a6533506b3e6639fe6e48ee881b31aa76bfca54    
  
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   : cc4434f15965bc2a996e401ef00eba97007cd825    
  
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   : 37218773e20476fc2bce92074bc54055c0eefed3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : cb85ce77f19f6cebd3669e08cdf1654a3613bc80    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : a4ba2720b3cb7e6a68848eb649c1ff3a91e852d4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 1d74a4aaf73bddde0785a1e14df55c5a8b00f558    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 7209daf6166e44ed97f56a3c8d9b84c90831facf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 97e0a9c4e6924e916f2036da07207af39b98b53d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : e7f11a2953ef644f79186e8d99c4b30ce6d79c17    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : e8f50a4126b86ba41b3f7334a4f7720ebb21d4cb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 510561c3fb4446b023cce8954e18a68cbee42cf9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 8e5da6768ab0efbabbf09dfa82f2c6a5dc861cdf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : f7dcd99b9c4b22d886d265f538935a43909bb4cc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : bdef8fa63cf71b9aff899672960d5ca8ef3e4cda    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 376324afd66c5d9bec7e9c360e98ba65695ea4cc    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:21:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:02 -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   : 9bb8b360f47ffc374a23787d1c96258fa4ab4830    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : b83eab069fcad3dea3e7529660319007993e7135    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 84a4e2c18f20e1562dca42c00802b85bb1d57eb9    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 4167810cfe62d5ed4cf70a576a2eed87e2f246a8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 9fe1c78135f44c3c16c18d4aee305ec83fbc0c56    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : ded6c00d3e26fff99fe747911bda2a0d4f28d163    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : c4a0b7919b3b81abb59f365d6a4dcff1feaa4c52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : f4ca5327ad2a51bdfba50e72892867f0c1dd86f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 8bead7abd0d19a5a836ec181e22b4540d571cac4    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 661a0951bdc219913524ed9015514518e67d0e30    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : f5782736cd26091ccb125f0d1a830c20e84e1c51    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 17a225d95a3e6e31ed561b7b895fb81a43619187    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : ea00db41ce6b690d5ca8c220094b4a77fb4864b4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : f32e9d5b49cd7baffc0b8be1dc924110d034411f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 1762f2e7cdbfa9ea9bd51e16678f9ee0e331620d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : f3cef207b9d1293a964610108964eb99c322ba68    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 8513bfaa286b0b168d24171ca2cd1a5121439791    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 6b093b4610b23f4e9b6cc70f1c2f231f3c5a63d5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : b1ff3ce04676707c8513d1237988b03c597747b3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 0a10508be03d6527aaa094155b5e9df7e56d0786    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 9d0efd64bff02bbf8d12959045e6cd1d55108fbf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : e0765b6d5b87b805962944ed547b42f5073b953b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 6c24b35e78c5e5507f7467e4bf997d8b0c9b8465    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 8587d949fcdf3b5503c15c68c458d3c8058e5176    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 6be4e665dffdf344bc5acb41f89009eccc0d09e9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:21:01 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:01 -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   : 887f6fee58f46c93bec66d0f449a579e314552ae    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : d2ea7772e46b164817c8c5ede6816f35fc2ba8c1    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : f2b6da9a664ff9af8c2b4e1a095fa0a5963a5362    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 9d2cda9f3fc8f474334d5d741129ccf223e74ed3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : f233bee1edb790737c6bf4ed073b98c1a821426c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 56c7f155fa531846a024e11ccb0d9c83fb985fe9    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 44ebef3b5ddda43bf7e706c8d071b9ee50c11737    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 179c2c37e06eb3999f2b57bb8e00ef6d82bedc2c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 368f52460f41b1574b75fcfd9a06c281eaecb1c8    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : fd0864aa0d5073d0960a5862935dd5711814074c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 98090a0ff08cdc928d393b77ae8186ec34510596    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : d275f6accdb80dd2afa0fc7eb8eaf1eb585120e9    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 69b973c656bbe6742cd8177310f1ba4dae5d9501    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : b049106516df15009a0e6348385f8833e0a2bf58    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 73c65779702a6fb836c3b01e9f396c1dc5936ecd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 122d1f8be0b16a8c0c7959be37b94c75c1d924ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 7282f7dfe14457396aaf0ff65e08e56672c249d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : c148f9509ed5583cb17687d50859c80a462d8932    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 7923562448197e5a2f9cacf65d64a044d112947c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 0eba29495584b72ce9d3ee8b754b48d964b7222c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : e8f2492727f2e4e668d6887d2af6c88870ae8067    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : eca4935d29a9f8b44a4b4faf8a7e86dd60f48b94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : a389439963d8f75a28f6f84ac7afa9db81b6094d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 556614e0428afda5da5dc33c75fc275b9c401d8a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : bd76c497e9624a774c9e30d610dff246ee46901b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 8ab0f897d41a9c6024497b088a1bafc5c94c50f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : 68abacacac0c61c727a24622cec73a1b52ff53ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:21:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:21:00 -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   : b2b0f9507ab4f5da6eb0ef254620444819d8fdad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:59 -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   : 4d27101361b2ba53be51272fb71ac7a14936106d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:59 -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   : 530a034aa2cfa2785a4301398fc3fb50526b794b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:59 -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   : d681b9f6a53b7b34798aeb069e038456a90c9ebe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:59 -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   : c032c0fbdc0cd9254d04ea83cbd8b07aa485ed95    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:59 -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   : 50f650b91b83a7cf0ee764b6e3ac8faed129e541    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 06:20:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:59 -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.  
  
Security: CVE-2026-16240  
Backpatch-through: 14  

commit   : fe8c2faefb4ab04554f1be66ce07b00d3df3f5a2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:27:42 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:27:42 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 162b79cb56f05460add42f50e1765be097007c5e  

commit   : 38ccfd8c955b3249fbbbdfaaef1c478d411dcc63    
  
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   : f72e4686e213d86e5e34a474019e500e3f0fcc63    
  
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   : 7e5d06901fc98809f1f8c835d90682f93a545f6f    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:54 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:54 -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   : 0c8611c6e7e614ba6cc224a6b819ef2862e46c71    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:52 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:52 -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   : 52f418f1f8acbbe44c3ff267ece6082ee61fff9f    
  
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   : 9e77656a91f4df3f584329aba9fdfc5ca6704d28    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 16:21:42 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 16:21:42 +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   : 83efe9602ecdad32ffe766ba0deab02b5fb0da93    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 4 Nov 2026 19:45:45 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 4 Nov 2026 19:45:45 +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   : 48955703b9e6958a7bf8e2cb7af1a56265ba1017    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Nov 2026 18:30:07 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Nov 2026 18:30:07 +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   : bc2125742cb0ccacad71d4883da9369669846017    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:52:31 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:52:31 +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   : 42c6d2bc3f2e28be83bf9fda0bc4ac4f5a597963    
  
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   : e22cec1bdb3c4a326152c161d58077c33755a093    
  
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   : 62a615e0b08c79437f3c6375f8b4b1e9db4b7c2f    
  
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   : ea7b9f7095f001b23acbd5ca7aecfedab789db45    
  
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   : 63e261b0bb37a4fc4f7d2425c64ac6cf7efc54ac    
  
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   : 67fa8cb33cd94c6d6e17dc64b3748e9d70bb145c    
  
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   : c48577385d15245691dbbff3bf25f1a1b58fe70e    
  
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   : 174b605f0e3a3e6a01a137ea401733b699937cad    
  
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   : 4e9a5dc1f57c7b1e64601825a497b94b1f36359c    
  
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   : 56fb8ee6ed72c9e0637325d25588f872c147e211    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 15:43:17 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 15:43:17 +0900    

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

commit   : ea1b698f2ecd9a9b1a31452f6412649352c0dbb2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 15:18:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 15:18:21 +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   : 40a5aa4a792d7f975940ed0d443438070256efb6    
  
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   : de7d7d4df80acceca1195d549bd2887d5bc8ab26    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 10:33:24 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 10:33:24 +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   : 35848657c67df5bef80f98e0d7091c23ce1e187a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 08:12:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 08:12:53 +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   : 275ad2006df5750e0c7c836f9d48ce2743389d7a    
  
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   : 9b24be3d94154856e019bb6ebdd8645f38bb2a68    
  
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   : e383197f2346c654812d86ee25d48e5ec9c6bc4b    
  
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   : c2d5c09a6b5cdb056954b80e297599fffd3f6c56    
  
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   : 6ffd2f91b7400780f146d349dfa31ef3e603c5bb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:58 +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   : 9e3077ff473e17852ad3690c45d8b86198f52986    
  
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   : 2a99622bfc01a61e883be573a12d1b52b8f38bcf    
  
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   : b0fa692801d1a0f8d8480bc21d57992a41ee2fd5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Oct 2026 16:22:17 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Oct 2026 16:22:17 +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   : 9a56e080f164332698ce640966ba6281acd68373    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Oct 2026 14:23:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Oct 2026 14:23:31 +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  

commit   : a44a4f1b6d11e1cb6061e70e112f688bf0a5dc85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Oct 2026 17:24:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Oct 2026 17:24:02 -0400    

ruleutils.c's looks_like_function() assumed that all COERCE_SQL_SYNTAX  
cases produce output that looks like a function call (or at least  
like one of the syntaxes the func_expr_windowless production accepts).  
But AT TIME ZONE, AT LOCAL, OVERLAPS and IS xxx NORMALIZED print as  
other sorts of a_expr, so those cases would produce invalid SQL syntax  
when used in a FROM clause.  Extend the logic to detect which specific  
functions are safe or unsafe.  
  
Author: Henson Choi <assam258@gmail.com>  
Reviewed-by: Prashant Chinnam <crprashant@hotmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAAAe_zC68s-DwVX1o7C1HVcRk+Z+RTS6Vw19auZFfz=KaX8tZA@mail.gmail.com  
Backpatch-through: 14  

commit   : f291e3336d28f3f82ce0bb6503653ebe84ca7a50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Oct 2026 14:03:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Oct 2026 14:03:24 -0400    

When validating a PL/pgSQL function with polymorphic arguments or  
result type, we substitute a plausible concrete type for each  
polymorphic type.  anycompatiblemultirange was missed in both places  
that do this, when multiranges were added.  As a result, CREATE  
FUNCTION with an anycompatiblemultirange argument failed with  
"PL/pgSQL functions cannot accept type anycompatiblemultirange" when  
check_function_bodies is on.  
  
Also, a function returning anycompatiblemultirange was compiled by  
the validator with an int4 result type, and since the function cache  
key doesn't include the result type, a later call in the same session  
with int4range arguments reused that entry and failed trying to cast  
the multirange result to integer.  
  
Map anycompatiblemultirange to int4multirange, as is done for  
anymultirange, to fix both issues.  
  
Author: Jeevan Chalke <jeevan.chalke@enterprisedb.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAM2+6=VEXCo7tPaxX+9_zN8SJ9DiPp2NTj_sPGN+Tb0wWTBp=w@mail.gmail.com  
Backpatch-through: 14  

commit   : 3651d7c58bc1d6d4f2ed398f96961524c3ba035e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 26 Oct 2026 09:50:58 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 26 Oct 2026 09:50:58 -0400    

The second phase of a multi-level nbtree page deletion operation marks a  
"top parent" internal page fully deleted, and updates the to-be-deleted  
subtree's half-dead page.  The leaf page needs to have its top parent  
link updated in preparation for marking the next top parent page (the  
subtree page one level down) fully deleted.  The second phase reads the  
leaf page's sibling links and releases its lock on the leaf, relocking  
it only after it has examined the target page.  This created a small  
window where stale information could be WAL logged.  
  
It was just about possible for a concurrent split of the half-dead  
page's left sibling page to update the half-dead page's left sibling  
link.  _bt_unlink_halfdead_page neglected to re-copy the leaf page's  
sibling links when it reacquired a lock on that page.  The atomic action  
that the WAL record represents doesn't really need to change any of its  
sibling links, so this shouldn't have been a problem.  However, since we  
use REGBUF_WILL_INIT for the half-dead leaf page's buffer, using a stale  
value led to corrupted half-dead leaf pages on standbys.  This bug has  
been shown to cause wal_consistency_checking failures.  
  
To fix, re-read btpo_prev (and btpo_next) from the leaf once it has been  
relocked, before the links are logged.  That way we'll reliably WAL log  
the current leafleftsib.  
  
In practice this bug was very hard to hit.  It required a concurrent  
split at just the right/wrong time, with a multi-level page deletion.  
Even then, the resulting corruption on standbys only persisted until the  
half-dead page was marked fully deleted -- which typically happened  
immediately after the corruption was introduced.  
  
Oversight in commit efada2b8e9, which fixed a race condition in nbtree  
page deletion.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-Wznr2Gw5OQE9KMP_Xd92F9mV=gv7qE9Q6taAvfrKqsE5Qg@mail.gmail.com  
Backpatch-through: 14  

commit   : b15c55163b68fc6f590436647fd8a6c9a9eaaf46    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Oct 2026 17:14:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Oct 2026 17:14:57 +0900    

CheckPointTwoPhase() wrote each 2PC file in place, with O_TRUNC.  A  
crash mid-write, or a base backup copying the file at that point left an  
empty or partial file that would make startup fail, most likely on an  
"incorrect size of file" ERROR.  
  
The 2PC files are now written through a temporary file that gets renamed  
at the end, relying on the atomicity of the rename to make startup safe,  
be it after a crash or a base backup.  
  
Author: Shihao Zhong <zhong950419@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: David Steele <david@pgbackrest.org>  
Discussion: https://postgr.es/m/CAGRkXqS_On-pLgcv6xjH8mvGhdcPmfWtythW3r8pYKUG+hsiuQ@mail.gmail.com  
Backpatch-through: 14  

commit   : 278d2a672e65d22d5d191c674cda863623df59d7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Oct 2026 09:55:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Oct 2026 09:55:01 +0900    

HeapTupleSatisfiesVacuumHorizon() did not set HEAP_XMAX_INVALID on a  
tuple inserted, then updated by a subtransaction that rolled back.  
rewriteheap.c relies on this hint to tell if such tuples should be  
treated as updated and would drop them, causing rewrites to lose some  
tuples.  
  
HeapTupleSatisfiesVacuumHorizon() is updated to set the hint  
HEAP_XMAX_INVALID, so as heap AM is able to redirect such a tuple to its  
correct route, and does not lose it.  
  
This issue impacted both CLUSTER (down to v14) and REPACK [USING] (down  
to v19).  
  
Reported-by: Alperen Keles <alpkeles99@gmail.com>  
Author: Shihao Zhong <zhong950419@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Reported-by: Zhijie Hou <houzhijie22@gmail.com>  
Reported-by: Takeshi Ideriha <iderihatakeshi@gmail.com>  
Reported-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/19760-8f9a0eba17bc8c92@postgresql.org  
Backpatch-through: 14  

commit   : 12cd839ec86af7031422d2be28ad5c65f3e1610f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 26 Oct 2026 00:18:48 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 26 Oct 2026 00:18:48 +0100    

Refreshing materialized views with CONCURRENT cannot use WITH NO DATA,  
but the tab completion supported this combination which is rejected by  
the backend.  
  
Author: Sho Ito <i.sho.0628@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAG7L5+7JOn_tjLjS1PJFTARtEybeJ1-aAAftZZ5L25_QZrjP4w@mail.gmail.com  
Backpatch-through: 14  

commit   : cfd97fa13d15f8138a6046173f6bd6dbd6b3c63e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Oct 2026 18:18:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Oct 2026 18:18:30 -0400    

Late-model clang is able to notice, when building posix_sema.c with  
USE_NAMED_POSIX_SEMAPHORES not defined, that the static variable  
nextSemKey is set once and read nowhere.  Rearrange the #ifdef's  
to not declare or set it unless USE_NAMED_POSIX_SEMAPHORES.  As a  
small side benefit, we can skip a stat() call altogether if we're  
not going to need it to initialize this variable, which I think  
clarifies the code a fraction.  
  
Per buildfarm member fritillary.  

commit   : 31fa779823c8520a2165f30fcb25880b07342462    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 25 Oct 2026 10:23:46 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 25 Oct 2026 10:23:46 +0100