PostgreSQL 16.16 commit log

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

commit   : b72e2acba126f06ba0a36436af0fafce2bd4e19d    
  
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   : 8d0db22582bf7f636fa43b258501ec776e127f64    
  
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   : 5968dfa6733081e126d094f3e878eafca0e8a8c2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 0453c553952116c6b8ac5f155f616a13eef0980e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 788915adfeb7b79bf85340d070443df0057e48a6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 0c8ffa1ad2f44be4b058a3ec96d9cb0c71f2593f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 813d92afcf44d927f74c29a1ad1688db8b152acd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 7f8be5d19f326a820ec05bbb67354615946c9f8a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : eb64484eb0fa15e410cb2e26c3ca1ffe495171f9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : cfe6111994c964768f35e9774baf063ef91aa02c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 0dcf804f202f54ddf9921e4c765b13b7b5d9a1db    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : dd0278aa37e1179d10f45d15433b0637b949f1d5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 726ef27b8300d1f62d5ab98359e23bc41a93528d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 2ce62526657c191273ddf8bc5e849f4719d9917f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : c152f62ac61803d62fe315edeed573ff90ed6e8a    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 19cff54329fdb9051044be0d98c4ad0167077914    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : dbc8a36d76183b84a374830582b433bfac632aac    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 5b2bd1dc1232937762b75c73ee5aea275857a58a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 629f54970896a84e80574d4aa17c3909e25bc8af    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : aa2d0aefec71eec88dbab334b42a5f83360c1df7    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 4ac399b6eeb826c2c1adae6aa6067ce69159ac64    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : cac94a04012879057070b1793a8110368be914bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : 4614c78a8c3a50a5da064e8db49b5bf20ee69523    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:53 -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   : f7b12b9f7d62f9ab83af0b72383a8684bece33d3    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 9ee0723c03b3e2030445b1cdf0c63f25ba20e7b0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : ecdfe03072fcbab411b2783aa246969537df132b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 3429a10d495543555f120c2548a7d10064911412    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 1c0c8810936de6f41de7f1cf8e11613948839dd6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : cf3fcd7659208dc94886eeb2853accad21f2c3d1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 5024810ad4615281cc63fbd6c184caa09e330465    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 74681445e15ce8ea1423bd874753172e7b391fb8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 4a090c2a776a50a12156176cc477dec7e64f20db    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 62761302baf30dfb8e6149e98581f4ea9d5d3e58    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 7fe0b6c8ef2c81281adfc42adf09cab754ed4247    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : b219eed247d30123ba029382603a5fb697ff3c3f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : e5c581cd4d7482ad1b0e265ab903d0d4b35e9dbd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 148fc82496a5d01143b2092892858c85aabe6161    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 1d1650e5270bea0375692af52fe07e73ce92f025    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 9528f2f31488243da5914c4f61b8911c954f98c6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : c67a4a24b7771464c3b26dfc04aef167e7c4fa51    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : f0aa151863c614c843aac5730a81642732c3564a    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 15b78dc3941a14aa5701fdb5dd21cb3ff7fb3454    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    

Commit 3057465acfbe changed show_all_settings(), used by the  
pg_show_all_settings() SQL function, to collect pointers to all GUC  
entries on its first call and return one row per call from that saved  
array.  When a module is loaded while the scan is still in progress,  
the placeholder entries for that module's prefix are replaced and  
freed, while the saved array keeps pointing at them.  That caused a  
use-after-free.  Depending on what reused the freed chunk, the scan  
returns stale rows or the backend crashes.  
  
Fix this by using the materialize mode for show_all_settings() so that  
the GUC array is consumed before any other expression in the query can  
run and free an entry.  This is also how the sibling function  
show_all_file_settings() already works.  We only have a few hundred  
GUCs in practice, so materializing them all is acceptable.  
  
Backpatch to v16, where that commit first appeared.  On v15 and  
earlier show_all_settings() reads each GUC entry by number on every  
call and never keeps a pointer across calls, so it is not affected.  
  
Reported-by: Stephan Lipp <Stephan@Adalogics.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Backpatch-through: 16  
Security: CVE-2026-120152  

commit   : 71bb0b5877e4bbd43ac0bafbd4f9d360ea7dedf7    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 30f67bdac5a0c8d038157addcdc31b293edf2844    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : 40a81579e13f8351dec8370d64e61d39f27d0688    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:52 -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   : b0e85b99bbfc6c47afbb88d213f72acd9f2a75dd    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : b7c0062c13410858c33f4012a98cd36ecb2d0426    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 0ed462c1fbb86e585257709693e868d8780edf64    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : cc13d5e0cc77938d94530cb02ec78db1eaecac7d    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : d901599291b221bc0ed9a3dba749cfc13a4f4f5b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : dec3a342d0c399edde359542bc2a95ee64ef1dd4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 3409adfbe3d555074a42bbcd91de9eeeac74cb81    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : ab7594cd162076263a902d08f3a063548cb93f2c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 38783780f6d9cf969320e6f6b4b63050df2a378a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 60341198b18142d5b5f9358379229b11457400ab    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 1dc59af896b76a8311204caf04975ca1c09bc884    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 2362bc619bc5c740726a7a3fa0cc252aca2092bb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 85420b358863b4851a5b5f79be38b0d2869c6a20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : b4ebd7240bbdfde6cc80255f8fddbe364bf7a49c    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : e48446c3e2c287d18722b3077e882f477d750652    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    

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

commit   : ba00c35762d878f76dbcf7fd8087368cd1cd095b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 63b204d9f9c6d590845cdb18aa4dc69858c21647    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 71c8a6ac45db1f388aaebadd4c9160dc362bef92    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 735b0dc1a73727956e876f8abaaeaaef588416cc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    

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

commit   : fad845598e4e42e6c7ef0025e66b0b80029adfbf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 8d6ca43589a3b724b0669f830783a0718a696bb4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : a78974d347603f635b4d202c06b6e008fd2e8b65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : adbbabe18ad7dda6a521ee3af55fdd39b4b47d6d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : ab70d013ea5600d5db49b6cd9d8e6ee475b48769    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 26a89a81ad2006bcc3da41359f244cdcab06ce8a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : 05114072cc7151dfa2900ebb6f4b8ace563e3d3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:51 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:51 -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   : c673c0a6178ad3e6ff16f4900fcfcf0dd927ba36    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:50 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:50 -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   : 2d7573b0098d035db01a742bb1475d4a7f45ff57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:50 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:50 -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   : 834255ca8580370a96136404845251ddbdaf94a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:50 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:50 -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   : 25baebeb2ccf09d94d1e35abea44c2fa04151aee    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:50 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:50 -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   : 885dfee080743fd1ff70bdbb693475795a23922f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 06:20:50 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:50 -0800    

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

commit   : 0244432c05c1b311a15b98cb3d96a7532efe3974    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:22:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:22:58 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 81a0ede0f481d92e7531a51c4c4fbb175001fd92  

commit   : 209846f1e35038dfc24fa2b0149c813517663ef6    
  
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   : e9c45974adb439fcc6fee6175e11f92619fc5361    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Nov 2026 23:31:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Nov 2026 23:31:41 +0900    

ANALYZE on a file_fdw foreign table failed an assertion when the input  
contained a DEFAULT marker, and could crash in builds without assertions.  
  
This happened because the sampling code passed a NULL ExprContext to  
NextCopyFrom(), which requires one to evaluate column defaults.  Fix  
this by providing an expression context for sampling, allowing defaults  
to be evaluated without assertion failures or crashes.  
  
Backpatch to v16, which introduced DEFAULT marker support.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Ayoub Kazar <ayoub.kazar@data-bene.io>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGwihFV9FmfSbbrMsEr4fti7aHZFkpyMv5-byjfc2EmOw@mail.gmail.com  
Backpatch-through: 16  

commit   : 1d57f6ef755b380eea613234bebda37aa766d6b5    
  
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   : 4c6ff7cb407c0f1586ca6085defd933a706a102d    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:39 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:39 -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   : 079638030a82300fb5d872897d00b522066008a1    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:37 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:37 -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   : 5c78685fc2d7402b12bdb10b0d20af31b5cab964    
  
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   : 2dd680013e75e04e510a48968439ee704c6d456e    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:16:12 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:16:12 +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   : 0500fb3ab2472b14686972959a0bea309e8662a2    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 5 Nov 2026 10:21:17 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 5 Nov 2026 10:21:17 +1300    

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

commit   : b76127a8846b4f3b76c54506512497cc1a8e55b9    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 4 Nov 2026 19:45:43 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 4 Nov 2026 19:45:43 +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   : 7cb230d218cfd635025bec68a33572f89eb13b64    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Nov 2026 18:30:05 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Nov 2026 18:30:05 +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   : e37a8075f9bca6ef4cfe815255342be90d134611    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:51:33 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:51:33 +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   : 8ef710eb30d9848b2b57040dc06d1a762151549f    
  
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   : 4c271dc216065c8e6c99ba3097e831e6ef6cd9e1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Nov 2026 11:16:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Nov 2026 11:16:44 +0900    

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

commit   : 083d60e34ae081a18f57071e45fcad9f07d1d7f6    
  
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   : 614347a3a5859dec4d1294c51805cedd589af5f0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 15:04:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 15:04:15 +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   : 2acf64595bb0b202ccbebb94df0b83f127ef0b40    
  
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   : bcb9d90519a80d62b0759f0ffddd31d1415a231d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:51:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:51:05 +0900    

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

commit   : 2ac618d717a34b984ef34ccb3f9764daa34d086b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:48:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:48:12 +0900    

Physical WAL senders could sleep even when flushed WAL was waiting to  
be sent, delaying replication and synchronous commits until another  
event woke them. In the reported case, commits stalled for about ten  
seconds, until the standby sent its next periodic status report.  
  
Commit bc971f4025c changed WAL sender wakeups to use condition  
variables, which notify only senders already on the waitlist.  
However, XLogSendPhysical() checks the flush position before  
WalSndWait() joins the waitlist. If WAL is flushed between these two  
steps, the wakeup can be missed, leaving the sender asleep despite  
having more WAL to send.  
  
Fix this by rechecking the flush position after joining the waitlist  
and returning to the send loop if more WAL is available. For cascading  
senders, also check for promotion or a timeline change, which require  
the sender to revisit the current timeline even if the flush position  
has not advanced.  
  
Backpatch to v16, where commit bc971f4025c introduced the  
condition-variable wakeup mechanism.  
  
Author: Alex Speller <alex@alexspeller.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/mvx5bs7q.33b99c32-67d8-4373-8611-7a8250fb2fd3@we.are.superhuman.com  
Backpatch-through: 16  

commit   : f1d27a92252b894a44db0d793ffc5976b4a44060    
  
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   : 0d0bde0b061dac60eea8c93246e9ab3c4e0d2034    
  
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   : 7e0d03a91618ff9f7524d238a9dce1085f8fd6e3    
  
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   : 444b85032a2a699816c772191f322b3fd16fe70d    
  
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   : c5c36ae6f4965a1e5cba9347c5292ebf0d7587f8    
  
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   : 1e9c734c26a9cfb735febb8e5d5996d0ae25a753    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 15:41:59 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 15:41:59 +0900    

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

commit   : bb4eabd6a1ad3b351aefd27163c367e042563bec    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 15:18:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 15:18:13 +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   : 06e46b6514a8994d4ebf9e39f57203151d4f0a77    
  
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   : 582db3ee09e9d2128c2510937bbc3c9f763d97bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Nov 2026 20:45:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Nov 2026 20:45:36 -0500    

In xmltotext_with_options(), xmlSaveClose() frees the save context  
unconditionally, but ctxt was only reset to NULL on the error branch.  
When the close succeeded and a later step threw an error -- typically,  
cstring_to_text_with_len() rejecting a result larger than MaxAllocSize  
-- control reached the PG_CATCH block with ctxt still pointing at the  
freed context, so xmlSaveClose() was called a second time on freed  
memory and crashed the backend.  
  
Author: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/bbadb6b2-d226-41a1-ace3-e0eb20648f58@uni-muenster.de  
Backpatch-through: 16  

commit   : b5ad785beb71f2c8581915648826aebc9839f946    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 10:32:00 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 2 Nov 2026 10:32:00 +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   : e8191e13f64b7f9ca4c92f21da5509d40782d30a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 08:12:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2026 08:12:47 +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   : 294685dcc1b791b7d36030e3314f139fd3a7d012    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Jul 2026 10:50:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Jul 2026 10:50:54 -0400    

On Windows, meson adds the build directory of every target in a test's  
'depends:' to that test's PATH.  tmp_install depended on  
installed_targets, which with NLS enabled includes several hundred .mo  
targets, pushing PATH past the Windows length limit.  tmp_install and  
initdb_cache then failed with no output.  
  
Fix by depending on a stamp custom_target that itself depends on  
installed_targets.  Meson doesn't walk a custom_target's dependencies  
when building the test PATH, so this adds at most one entry.  This can  
be removed once we mandate a meson version containing the upstream fix  
(expected in 1.13).  
  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Backpatch-through: 16  
Discussion: https://postgr.es/m/CAD5tBcJXAX8bz5q9ngE4znvVLiXaPO89D0yTFhJgEPrPyT-Erw@mail.gmail.com  

commit   : a2732c98671d86a06f7ec21d469a52a7bf4efdc9    
  
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   : f5e651d617c2367fd7d99924eefcc8dbb8b4beed    
  
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   : 3868ed7b39e663e5b03abca76a1aa1195a428fc6    
  
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   : 72216a24544b893dc105e811f0ec27b3c036575b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Oct 2026 13:56:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Oct 2026 13:56:10 -0400    

pg_GSS_have_cred_cache() always acquires new GSS credentials.  
If we already had some, they were just leaked due to overwriting  
conn->gcred, and that's a nontrivial amount of memory (around 16K  
according to reporter).  Unfortunately, pg_GSS_continue() did this  
each time through, and it is typically called more than once in a  
GSSAPI connection cycle.  So repeated connections using GSS  
authentication could leak substantial amounts of memory.  
  
IMO the source of this problem is really the poorly-designed API  
of pg_GSS_have_cred_cache(): it's unclear that it always gets new  
credentials.  Let's rename it and remove the unnecessary pointer  
parameter to make its behavior clearer.  
  
To add insult to injury, pg_GSS_continue() shouldn't even be  
trying to acquire credentials unless GSS delegation is enabled,  
which it is not by default; so the whole effort is often wasted.  
  
Problems evidently introduced by 6633cfb21, so back-patch to v16.  
  
Bug: #19411  
Reported-by: Matt Carter <Matt.Carter@twosigma.com>  
Diagnosed-by: Matt Carter <Matt.Carter@twosigma.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19411-0440c8897a04b638@postgresql.org  
Backpatch-through: 16  

commit   : c1b622766fd9d285d090ee616869ea4fd59deda5    
  
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   : 0cea8f85ecd001a0488654f3490b9e7d3081b6b8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:50 +0900