PostgreSQL 18.6 commit log

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

commit   : aed4c42bce80dda767277cf983baec4678c55daf    
  
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   : 412297476510be7a769e27e38f619110e4011904    
  
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   : edcc027ee19c57ebd7ec6d153c9c28344628e6fe    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : 30d81a0bae6ea5945aedbf4a17e822eb3cc9b3db    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : 5f0add5cf1c6e1c8eda2120598878ec3796cc34a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : cfdd09589b9f19fbc78c244e7868f1af46c460b8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : d835dc88d8d60816f2261128326673b11d52f0c1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : edcd260d9e31de73d0f3db572a9e3ce66d9fcf9e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : 391884d5c9117528b7466f5b4dd3a702b3034c60    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : 8b1a2a8ac21ac7ac735baa1361e86fd9ad24a2d0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : da2cb60900a5a6777aac7979769e917174f350c0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : 7c32010cacb1e4e5ec95a6982da9a0ff48329ebe    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:44 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:44 -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   : dcb2ff56dafe67b6b79007641c3b65e41dd92a6c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 7bc2d46d11fd9697519db93884546777c4e7e6ba    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : f1b226dee1cbbc74b5df45185a5e94a547a38e4a    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 4fb349500a20105ef476c524efea95e7b1c03a66    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : ea228688e252b5d8767cc1bded8e327abb0f3abf    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 983bcb768a9ae0fe16ef491b53176bf3e2d06866    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : a244ef271563a5fd751e94e1654958b803883637    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 317b7bcab012778c9fdab1d87b5315aba5e37364    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : ff961cbbf3af286665209b8039df3565ade198ae    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 6b1ca1333b346926515e62ae361781028b222f7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 2d91c1c78aea39285c85fae29c5737a4106eeaf0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 35d851811f9f2ebb8d88baa27964bce8fb98ef40    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    

equalRowTypes compared the name, type, typmod, and collation of  
corresponding attributes.  That's sufficient when neither attribute has  
been dropped, since their physical storage attributes (attlen and  
attalign) are derived from their type.  But a dropped attribute has its  
atttypid set to InvalidOid while keeping the attlen and attalign of the  
type that the column used to have.  Two row types that merely had  
dropped attributes in the same positions could therefore be considered  
equal, even when the dropped attributes' widths or alignments differed.  
  
That was a problem for typcache.c's record type cache, which relies on  
equalRowTypes to decide whether a tuple descriptor matches one that was  
already assigned a record typmod.  A tuple built using one tuple  
descriptor could be assigned the typmod of a physically incompatible  
descriptor, allowing it to be deformed using that descriptor.  That  
could be abused to make the server disclose memory contents, and to  
achieve arbitrary code execution.  
  
To fix, make equalRowTypes also compare the attlen and attalign of  
corresponding dropped attributes.  
  
Oversight in commit 20e58105, which introduced equalRowTypes.  
equalTupleDescs already compared attlen and attalign, but equalRowTypes  
missed that precedent.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Security: CVE-2026-120142  
Backpatch-through: 17  

commit   : 780809ba636cb1b83c39c9d6265ffec72c5653b3    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : a748ed909271ac58f09e3df0915adf487170a6ae    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : ff6d9deca78688b211b88329d9ac484df726b441    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : fdbb7ffbb555b714d299e0d88c22b360e9034321    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 26ff7cbd370e568734abe54b65a253058f979c55    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 5db4823d00709ad99d8fc18bc1055ad2305a6b08    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : e72f4e91cefd09ccdc4d9f3d26b40049dd293c6d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 67d89bb2202df376e680e6c43d15b82dbaf92044    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : d48d28c4b68717cf2c968345444a004af7d7bee5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : 05fc87f95346caedca5a9e7ee59293a77f0e60c0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : bb66a4e8264a56f58977b6cc1f57d34aac1cb3c0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:43 -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   : bcc6924935f8bd228e1f9b8714c1a050e3b50dc8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 1bb9942e205c9021b714f07de30b9662666d72de    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 9ddd897b30d32ba4c328cbdccd3486296df4f0b1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 9ef1cd650a6bcfa2ea5f64aa23b3a079a6d6cca3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 692f4b3c49562435b058ebfe12e08ebee5617cd3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : afaff70f0fbe5025169c213a696dbe5468747fa1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : b8fbeeb7600778d05bbbe1e7ee81e4491b2116e6    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 921b93f250f65c730c2d21b71d7535074f79663e    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : cc2d1a4c981bd83f2ba54c540c9e2bb9832dbb18    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 74a999de18d442a3fecf752dceff2144110e75c4    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 2950cc7897a2c10f080f308dbef3b80665c6fd71    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    

Commit b85a9d046efdd27775cbe7db9e92aad96aab4ada added this mechanism  
as a response to bugs reported when the same feature was previously  
committed as c14d4acb81348a34497b53a19dce2924cc4f6551. Unfortunately,  
it turns out to have multiple bugs. AtEOSubXact_TypeCache() cleared  
the entire list, instead of only the entries added at or below  
the current subtransaction level. Both AtEOXact_TypeCache() and  
AtEOSubXact_TypeCache() perform allocations in the abort path,  
which risks a second error before we've finished recovering from  
the first. Also, because in_progress_list was used to defer adding  
entries to RelIdToTypeIdCacheHash, it introduced a risk of missing  
invalidations that occurred after lookup_type_cache() performed  
the pg_type lookup and before the RelIdToTypeIdCacheHash update.  
Some of these problems are security vulnerabilities.  
  
Removing in_progress_list fixes all of these problems, but risks  
reintroducing the problems that in_progress_list was meant to fix.  
Specifically, we have to make sure that an invalidation processed  
while lookup_type_cache() is executing can't remove the associated  
RelIdToTypeIdCacheHash entry before the TypeCacheEntry is even  
returned to the caller. This commit solves that problem by never  
removing entries from that hash table under any circumstances.  
Instead, we now tolerate stale hash table entries, and check  
whether any given entry is still valid before relying on it. See  
the comments for further details.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Security: CVE-2026-120144  
Backpatch-through: 18  

commit   : 17e57d06cd3a3966143502626a2f5c7534f8309c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : d3c9f8c61cce1827579fda3324aecdcc3b1e5ba2    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 1dfde5b374b0b3554f3370913391b8d22ff81d29    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    

The backends participating in a parallel btree scan with array  
keys (e.g., "= ANY (...)" quals) hand their positions in the arrays  
back and forth through shared memory, on the assumption that they  
all built the same arrays.  Nothing verifies that, so a function  
mislabeled as PARALLEL SAFE or STABLE can leave the backends with  
different arrays, after which a backend might read past the end of  
its own array or, if the backends don't even agree on how many  
arrays there are, read the saved positions from the wrong place.  
To fix, save the number of arrays along with the positions, refuse  
to restore anything when it doesn't match, and reject a saved  
element number that isn't in range for our own array.  v17 saves  
only element numbers, so it just needs the range check.  
  
Reported-by: Claude and Ada Logics  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Security: CVE-2026-116333  
Backpatch-through: 17  

commit   : 1e0a55a0fb26e13a6f0b1da87dea06957780b9e4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 9e4cde7927da3603a2b6ca0d4e75d50b28888252    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    

When a child table's column is inherited from its parent but the  
child has its own not-null constraint on it, pg_dump emits that  
constraint as a standalone table constraint in the child's CREATE  
TABLE, and it prints the constraint name unquoted.  A name needing  
quotes therefore produces broken SQL (or, for a mixed-case name, a  
constraint restored under the wrong name), and a name chosen by  
the table's owner can inject arbitrary commands into the dump,  
which are then run with the privileges of whoever restores it.  
  
To fix, pass the name through fmtId().  Since fmtId() hands back  
a pointer into a single shared buffer, the constraint name and  
the column name can't be formatted in one appendPQExpBuffer()  
call, so the CONSTRAINT clause is printed separately.  
  
Reported-by: Anthropic OSS program  
Reported-by: Sarath Kumar <sarath@iitmpravartak.net>  
Reported-by: Nikolay Samokhvalov <nik@postgres.ai>  
Author: Anthropic OSS program  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Sami Imseih <samimseih.pg@gmail.com>  
Security: CVE-2026-116318  
Backpatch-through: 18  

commit   : 448db14518504c789554f2e1be5a1efa6a9b155c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 673ef2341e3f6263f301c8f0b0f5c935bfea773a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : e10d38d4715ecb75b274546f0c5917de2fe14829    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    

vacuumdb runs its catalog query with the session's default  
search_path so that --table arguments resolve as they would in  
psql, but commit edba754f05 added two constructs whose = is not  
schema-qualified: the relkind IN list in the LATERAL and the IS  
DISTINCT FROM tests on attstattarget and stxstattarget.  This  
allows a database owner to shadow the operator with their own and  
execute arbitrary code as the user running vacuumdb.  To fix,  
rewrite the former as OPERATOR(pg_catalog.=) ANY (array[...]) like  
the relkind filter in the WHERE clause, and the latter as an IS  
NULL test with OPERATOR(pg_catalog.<>).  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Reported-by: Anthropic OSS program  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Co-authored-by: Anthropic OSS program  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Security: CVE-2026-116313  
Backpatch-through: 18  

commit   : 7f30f607a2579ea90c0d3ca2739a4a83eb7316ed    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : 8373a421558c05813ae6d428102892de38a934ea    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:42 -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   : d9b15fda5684b4a6feadf23b28fc4aa8812eb65a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 3531f4b343d7cad7c24b17d5e4ed74f1721d2a86    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 8a2982de9f1a6f859d740b52cb97b457a29d009e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : b552d6efb23e13a65906202bafb0e101a2355521    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 68ee5a81610e02be3a5c46063b089b5f5e20f2ec    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 061cc0ee6f017ba6b937c61a50c91a758b9a95a8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 165bbc265631f937b6396df3bfcac7e6520618e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 780900dcfab7652f510ec60059cf8dbb51bfd7f5    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    

The attribute statistics import function locked the target relation  
but did not keep it open while converting its input values.  
Converting a value can run user-defined code, such as a domain's CHECK  
constraint, which can alter the relation in the same transaction.  The  
lock alone does not prevent that.  The import could then store  
statistics that no longer match the column, which can crash the  
backend when the planner later reads them.  
  
Keep the relation open across the conversion, so that such a reentrant  
ALTER TABLE is rejected by CheckTableNotInUse() as it is elsewhere.  
  
Also, the same code can drop the target column itself, which doesn't  
go through that check.  The import would then store a pg_statistic  
row for a column that no longer exists.  That only leaves a stale  
catalog row behind, but it's wrong all the same, so re-check that the  
column still exists before writing, and error out if it doesn't.  The  
column must not go away while we restore its statistics, and raising  
an error also rolls back the drop.  
  
The extended statistics import function, added in v19, has the same  
hazard and is fixed in the same way.  There the same code can also  
drop the statistics object being imported, which would leave a  
pg_statistic_ext_data row with no owner.  A statistics object created  
later with the same OID would pick that row up as its own, so we  
re-check that as well.  Branches before v19 have no such function.  
  
Reported-by: Mehmet D. INCE <mehmet@mehmetince.net>  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Backpatch-through: 18  
Security: CVE-2026-116329  

commit   : 250405afb76579e0691267471c196bb9ea3b3e0d    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : f64f711882f8042a6fe6512b2cc0c949db771242    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 861b5a86952a29607c478118c9c65d95ae9ae4ad    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 2c03c7c48fb6060155fd9d35fdcef40ddf0a28f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 4ccea70a1817fe740bf15e9411947b88d737c61d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 53a34a4defaa42c9d7013fbff491b78f41b5f18b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : aac5e6f5038a4d3b9a6d71b30e57fd9c9436033c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    

get_parallel_tabidx_list() builds an array of regclass values, and  
incorrectly assigned quotes to the query built, leading to incorrect  
queries once the names of the objects included single quotes.  
  
This issue is by embedding each object name inside their own  
appendQualifiedRelation() before being attached to the final catalog  
query.  Some tests are added.  
  
Issue introduced by 47f99a407de2.  
  
Reported-by: Anthropic OSS program  
Author: Anthropic OSS program  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Security: CVE-2026-116325  
Backpatch-through: 17  

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

BackendInitialize() collects the startup packet with two facilities able  
to exit() early:  
- StartupPacketTimeoutHandler(), timeout enabled for the startup  
process, via StartupPacketTimeoutHandler()  
- process_startup_packet_die(), for SIGTERM  
  
Both assume that shared memory is never touched, meaning that a hard  
exit() is fine, as no cleanup action need to be taken.  
  
9d9b9d46f3c5 broke this assumption by making the cancel request handling  
happen earlier in the pre-authentication process: SendCancelRequest()  
can acquire the spinlock "pss_mutex" to compare cancel keys.  If SIGALRM  
(authentication_timeout) or SIGTERM is received while "pss_mutex" is  
acquired, the process would exit with a spinlock still held.  The next  
process touching the same proc slot as the one that has exited earlier  
would wait indefinitely for the spin lock, crashing the server on PANIC  
after one minute of wait.  
  
This commit changes the cancel request handling so as a request received  
is stashed instead of immediately processed.  Its processing is delayed  
once it is safe to do so, where the startup timeout and SIGTERM handler  
are cleared.  
  
Reported-by: Anthropic OSS program  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Backpatch-through: 18  
Security: CVE-2026-116322  

commit   : 9a96032e100a9833534dae226d5aad0f693006c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 3ce3d94c0da1a9ad512b743f85228e69883940ec    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 343663966f830427033b51c8703e64e3a2446c4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 5215e9d6a13955c949bfe07b643927b733bd0033    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 8d308caee3a53aae1ebcb2cb64f72cce108239c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : bbe476c747f31e521dbdc395fc6f16db96fc680d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : f01727316219146fd54cc6448c540a5a50550c29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : b3ef92518c57d8db63ac18b4adcf585da90e0673    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 3e97c9a1fa19fb995e57a1a093cb7cee3f6da605    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 9c2cadacd61562ba7835179209c2aa9482f61d48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:41 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:41 -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   : 8d9f203b81483e30ff71daaa57ba0038e0568b77    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:40 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:40 -0800    

Previously, cur_attname and cur_attval were left set when ON_ERROR was  
'ignore' or 'set_null'. As a result, if an error was raised while  
processing the next row, the COPY error context callback could  
dereference a pointer that no longer belonged to it. cur_attval isn't  
a copy of the field value; it points into attribute_buf, which the  
next row resets and, for a longer line, repallocs. The callback  
measures the value with strlen() before applying the display limit, so  
the limit bounds what we print but not what we read. So depending on  
what has reused the allocation, the CONTEXT line reports a value from  
the previous row or bytes belonging to something else entirely.  
  
file_fdw reaches the same code through its soft-error retry loop, so  
on v18 and later, a SELECT or ANALYZE on such a foreign table hits  
this too.  
  
Fix this by making sure to clear both fields before processing the  
next column data.  
  
This also corrects the context reported for a REJECT_LIMIT overrun,  
which is a statement-level error but was picking up the column and  
value left behind by the last skipped row.  
  
Backpatch to v17, where ON_ERROR was introduced.  
  
Reported-by: 안지용 <jfdg1y76@gmail.com>  
Backpatch-through: 17  
Security: CVE-2026-116310  

commit   : 030b28a8d1de21501fdad1e1ff2337a7ddc28a54    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:40 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:40 -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   : af250ef26280d49ef301c9c64b0d4740180c8821    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 06:20:40 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:40 -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   : 2134cfde5cf674a5e77debefdf60a05a07d70c5e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:17:00 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:17:00 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 6cb5a00fa45d31470d756277abff083a5437b486  

commit   : a1635642e81125a5e7b8a2e717b9c4dd2f66896b    
  
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   : 4bcd0d31c6878b370cac8c738a35bb7bc5db22c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 30 Oct 2026 17:29:35 +0900    

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

commit   : 1da6ddbdc32c5bf640429828bc0353ffcb40628e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 6 Nov 2026 19:56:22 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 6 Nov 2026 19:56:22 -0500    

If address sanitizer is enabled, types of global variables are changed  
to a container type, to include space for a red zone after each global  
variable. Unfortunately, that causes mismatches with the generated code,  
which in turn causes crashes when JIT is combined with ASAN.  
  
This does not normally present a problem with autoconf builds, as we do  
not pass CFLAGS on to bitcode generation, so in autoconf builds the  
bitcode generation never sees sanitizer flags.  Somewhat similarly, in  
meson builds, c_args were not passed on to bitcode generation, but that  
was changed with 1039352e1 in 17.  
  
For now, just use #pragma to exclude global variables in llvmjit_types.c  
from address sanitizer.  
  
That might not be the best fix medium term, but we need a short-term  
fix, due to an upcoming fix's tests hitting this issue.  
  
We did not notice this historically as with cirrus-ci address sanitizer  
was tested with autoconf, which does not have this specific issue. The  
GHA based CI was only added after JIT was disabled by default.  
  
For now this is just backpatched to 17, as earlier branches  
a) don't have pg_attribute_no_sanitize_address()  
b) don't currently need it, due to 1039352e1 only being in >= 17  
  
Author: Henson Choi <assam258@gmail.com>  
Discussion: https://postgr.es/m/CAAAe_zA49cHXJ7J4hmeuSa75s+eSgCOnK_9Uvq6wUEJ2Bgvdfg@mail.gmail.com  
Backpatch-through: 17  

commit   : de2793682d98e8fe458f192b1a0e48e9fd623b40    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2026 16:32:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2026 16:32:03 -0500    

It's quite unclear to me why these two examples are overrunning the  
right margin in the v18 docs, when the identical examples are fine in  
other branches.  Nonetheless, the buildfarm (member alabio) is showing  
the same results I see locally, so it's real, and I lack the time  
right now to dig any deeper.  Throw a &zwsp into one example to allow  
a line break, and adjust the sample UUID in the other one so that FOP  
thinks it's a breakable word.  

commit   : c58a86e1d312cc75d6ff6c0f045463139d6db6f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2026 16:17:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2026 16:17:01 -0500    

Improve entry for commits 79b101486 et al. based on comments  
from Peter Geoghegan.  
  
ASCII-ify Ante Krešić's name, because our PDF docs toolchain  
can't cope with "ć".  

commit   : 5e41e193f3f401109522eda1dd90d6e2c873bbd7    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 Nov 2026 21:56:10 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 Nov 2026 21:56:10 +0100    

The bearer token used by OAUTHBEARER authentication is transmitted in  
clear text over the network, which makes it vulnerable to sniffing and  
similar attacks.  This adds a note that SSL connections are recommended  
for OAuth authentication.  
  
Backpatch down to v18 where OAuth was introduced.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Co-authored-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAN4CZFNy23wWKF+78QG3cfunjJpQWFc7eNP7qcYPB6Sg-NhTQQ@mail.gmail.com  
Backpatch-through: 18  

commit   : 32973315d26b40225f592645c7526da7ab228531    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2026 14:42:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2026 14:42:51 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : 813a74bc5a76f13c15da902f5523d0fa755e2c5f    
  
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   : c7656ac9e652534d2ec7603bfe0947eec6c7fc22    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 6 Nov 2026 16:18:36 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 6 Nov 2026 16:18:36 +0900    

transformJsonTable() transforms the context item and the PASSING  
arguments into the JsonExpr stored in TableFunc.docexpr, and copies the  
transformed PASSING arguments into TableFunc.passingvalexprs, but never  
ran assign_expr_collations() over them.  That is needed here because  
assign_query_collations() doesn't look into the range table, which is  
why transformRangeTableFunc() does it for XMLTABLE, as does  
transformJsonTableColumn() for JSON_TABLE's own column expressions.  
  
As a result, expressions in there were left without collations.  A text  
comparison failed with "could not determine which collation to use for  
string comparison", even with an explicit COLLATE clause, and a row  
comparison was left with an empty inputcollids list, which made the  
executor compare zero columns and return the result for equal rows (so  
ROW(1, 2) < ROW(3, 4) yielded false), or trip an assertion in  
ExecInitExprRec() in assert-enabled builds.  
  
Fix by calling assign_expr_collations() on the transformed JsonExpr,  
before the PASSING arguments are copied out of it.  
  
Oversight in commit de3600452b6, so back-patch to 17.  
  
Bug: #19768  
Reported-by: Venu Kummari <venu2805k@gmail.com>  
Author: Venu Kummari <venu2805k@gmail.com>  
Discussion: https://postgr.es/m/19768-3633daa830be95db@postgresql.org  
Backpatch-through: 17  

commit   : 744ca40cbe2cac09124cc8b560d01e71e8c1f8b8    
  
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   : 9b71ffa061d77af7302062df22099566fc6e16ae    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 10:45:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 10:45:09 +0900    

This reverts commit 23e2a332dd24.  It looks like it is going to need a  
little bit more work, and v19 RC2 is close by.  
  
Backpatch-through: 17  

commit   : 2a5e2d2867aeb1b4989678481c5de523a22fc1cb    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:53:48 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:53:48 -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   : e2b3549a4103efeb2fb35daef770427fa8264a17    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:53:48 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:53:48 -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   : c88c71a4b52a514cf9e9582c2d657e0fc6d4ce97    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 09:18:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 09:18:40 +0900    

When ON_ERROR handled a soft error, some of the contents set for the  
error context callback could remain set and pointing at areas that could  
be reset, leading to some use-after-frees depending on the input data  
provided through COPY.  
  
These contents are now reset at the beginning of NextCopyFrom(), before  
processing the next tuple.  
  
SET_NULL is affected down to v19, IGNORE down to v17.  
  
Author: Gowdham M <gowdham.m@zohocorp.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Shihao Zhong <zhong950419@gmail.com>  
Discussion: https://postgr.es/m/1a181ff6be8.6d14feb261368.4036709598649280477@zohocorp.com  
Backpatch-through: 17  

commit   : dcf112bd4e4cfe1651fafe169dffdaf076bd0b43    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 Nov 2026 00:49:07 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 Nov 2026 00:49:07 +0100    

Commit 8e54a414570010af included a test for invalidated oauth validator  
with a SKIP stanza for EXEC_BACKEND Windows builds, but failed to handle  
non-Windows EXEC_BACKEND builds.  Since the debug GUC for retrieveing the  
EXEC_BACKEND state is only available since, we add an alternative output  
to capture the failure on EXEC_BACKEND.  Per buildfarm member culicidae.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/C6EE5C79-AC29-4F3D-B0BD-B07E9298051A@yesql.se  

commit   : e83298599633528e749887b17f74fe933c552154    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 5 Nov 2026 21:43:55 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 5 Nov 2026 21:43:55 +0100    

Commit bca67e5a3 added checking for blank validator configuration, this  
completes that work by checking for a quoted empty string as well.  
  
Backpatch down to v18 like bca67e5a3.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAN4CZFP7ZMLB5Q1P4H__2d54om6fO+OEBZpWLpMwhFipobrEEw@mail.gmail.com  
Backpatch-through: 18  

commit   : 8a043da94728821e1dfc6758cd883bafb57bfac7    
  
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   : 8e54a414570010afed0b8b1ed10882afba380166    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 5 Nov 2026 14:14:01 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 5 Nov 2026 14:14:01 +0100    

The validator allowlist is only enforced while parsing pg_hba.conf.  
If changing oauth_validator_libraries makes an existing oauth line  
invalid, the HBA reload fails and the old lines stay in use, so a  
removed validator keeps authenticating users.  In particular, when  
setting the list to the empty string, the server doesn't refuse an  
OAuth connection, as documented.  
  
Backpatch down to v18 where OAuth was introduced.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: shihao zhong <zhong950419@gmail.com>  
Discussion: https://postgr.es/m/CAN4CZFNbWXwC=s4t9Xu1kitLsQvTe-EwpVtFCjixWCHBxRTraQ@mail.gmail.com  
Backpatch-through: 18  

commit   : 41b4b8e8bf1a07ce4fbfa86b8e544299e1a706cf    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Nov 2026 18:06:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Nov 2026 18:06:25 +0900    

An incremental backup taken after VACUUM truncates a table can restore  
stale visibility map bits when both data checksums and wal_log_hints are  
disabled. If the restored table grows again, the stale bits can cause  
VACUUM to skip required freezing and advance relfrozenxid past unfrozen  
tuples, or cause index-only scans to return deleted rows.  
  
Heap truncation clears bits for removed heap pages in the last remaining  
VM page. With both settings disabled, that page is not separately  
WAL-logged. The WAL summarizer records the VM truncation limit but does  
not mark the remaining page as modified, allowing incremental backups  
to reuse its old contents. The truncation record precedes the incremental  
backup's start LSN, so recovery does not replay it to clear those bits.  
  
Fix this by marking the last remaining VM page as modified when  
summarizing a truncation record, so incremental backups include its  
current contents. Do this conservatively even when truncation falls on  
a VM page boundary and the remaining page does not need to change.  
  
Note that existing WAL summaries are not regenerated by this fix.  
Incremental backups taken after updating can therefore still be affected  
if they use summaries generated before the fix. Take a new full backup  
from an uncorrupted server after updating and use it as the basis for  
subsequent incremental backups. This does not repair existing backups  
or corruption already present in a restored database.  
  
Backpatch to PostgreSQL 17, where incremental backup was introduced.  
  
Bug: #19775  
Author: Ke <kehan5800@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Co-authored-by: Shihao Zhong <zhong950419@gmail.com>  
Discussion: https://postgr.es/m/19775-087aebfa1a709b09@postgresql.org  
Discussion: https://postgr.es/m/CAGRkXqSnghF+wbyP-PdfjVLfbejJG3cvZd9hN-gxsvCWj2F64Q@mail.gmail.com  
Backpatch-through: 17  

commit   : 5bfe88cf6a814e24ac9c7332142a75d11a2e5461    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Nov 2026 18:03:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Nov 2026 18:03:44 +0900    

With io_method=io_uring and restart_after_crash enabled, the postmaster  
reinitializes shared memory after a backend crash. It created new  
io_uring instances without releasing its references to the old ones,  
causing resources to accumulate on each crash restart. Eventually,  
creating new instances could fail with "Too many open files" or  
"Cannot allocate memory", preventing the server from restarting.  
  
Fix this by registering an on_shmem_exit() callback to release the  
postmaster's references to the io_uring instances during shared  
memory cleanup, before creating new ones. This prevents resources  
from accumulating across crash restarts.  
  
Backpatch to v18, where io_method=io_uring was introduced.  
  
Reported-by: Lucas DRAESCHER <git@draescher.fr>  
Author: Lucas DRAESCHER <git@draescher.fr>  
Reviewed-by: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: Ilmar Yunusov <tanswis42@gmail.com>  
Reviewed-by: Laetitia Avrot <laetitia.avrot@gmail.com>  
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/zHN8Rb7syWYDBPUhCICxKLr_tQmFLg0T024irxVVb6RSSicZcqcA0eT73z2PQy7JmzzqnUzX0Hi3P2dPKRvmNx_jbAqSCLyqJvWjXEypyAI=@draescher.fr  
Backpatch-through: 18  

commit   : 7150d0fd494166107e6efcc7e786690fd76eff08    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 12:24:43 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 12:24:43 +0900    

Once JSON_VALUE(... RETURNING json/jsonb) returned NULL, every later  
evaluation of the same expression in the same statement also returned  
NULL, even for inputs that had a valid value.  
  
In ExecEvalJsonExprPath(), the JSON_VALUE_OP branch for RETURNING json  
or jsonb converts the matched item to its string form but, unlike the  
sibling branches, never sets *op->resnull to false.  So a NULL result  
from a previous evaluation, whether due to a JSON null item, an empty  
match, or an error handled by NULL ON ERROR, remained in effect.  That  
caused the subsequent coercion via the type's input function, which is  
guarded by that flag, to be skipped, and the valid item to be returned  
as SQL NULL.  The result thus depended on what earlier rows, or earlier  
expressions sharing the same ExprState, had returned.  
  
Fix by setting *op->resnull to false in that branch.  Also add a  
comment noting that ExecGetJsonValueItemString() takes care of that  
in the final branch.  
  
Oversight in commit 6185c9737cf, so back-patch to 17.  
  
Bug: #19695  
Reported-by: Chaitanya Choudhary <chaitanyyachoudhary@gmail.com>  
Author: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Reviewed-by: Manu <manuelreyesbravo@gmail.com>  
Discussion: https://postgr.es/m/19695-2f2c573ef1660737@postgresql.org  
Backpatch-through: 17  

commit   : fbaebf450d444782d25fa5a25b7bf0fb41403abc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 5 Nov 2026 09:38:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 5 Nov 2026 09:38:18 +0530    

ALTER SUBSCRIPTION ... SET (two_phase = true) always moved the  
subscription's two_phase state to pending, even if two_phase was already  
enabled. The publisher's slot still has two_phase enabled in that case,  
and prepared transactions may already exist on the subscriber, so the  
reset broke checks that rely on the enabled state:  
  
1. A later SET (two_phase = false) no longer checked for existing prepared  
transactions and disabled two_phase anyway. When those transactions were  
committed on the publisher, their changes were re-sent as regular  
transactions instead of COMMIT PREPARED, leading to self-deadlocks,  
duplicate data, or orphaned prepared transactions.  
  
2. REFRESH PUBLICATION (and SET/ADD PUBLICATION) with copy_data = true was  
allowed even though the publisher's slot still had two_phase enabled. This  
could stream prepared transactions during the initial sync of newly added  
tables and apply them as empty prepares.  
  
Fix this by leaving the state unchanged when two_phase is already enabled.  
  
This problem was introduced by commit 1462aad2e44, which allowed altering  
the two_phase option of a subscription.  
  
This changes behavior when slot_name is altered together with SET  
(two_phase = true) on an ENABLED subscription. Previously the state was  
reset to PENDING and the apply worker enabled two_phase on the replacement  
slot. Now the state stays ENABLED and the apply worker does not touch the  
replacement slot's two_phase property. This is intentional: resetting the  
state would reintroduce the problems described above, since prepared  
transactions from the old slot may still exist on the subscriber. The  
documentation already requires the replacement slot's two_phase property  
to match the subscription option.  
  
Author: Zhijie Hou <houzhijie22@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/8e85abdf-738b-4578-ac42-4dc8eaa061dd@gmail.com  
Backpatch-through: 18  

commit   : 52033b8871b8ff3c5fe34ffbdef1db38f46586b8    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:37:55 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:37:55 +0900    

ExecInitJsonExpr() emitted JUMP_IF_NULL steps to skip the  
EEOP_JSONEXPR_PATH step when either the context item or the path  
expression was NULL, landing on a CONST step that returned NULL.  
However, ExecEvalJsonExprPath(), which implements EEOP_JSONEXPR_PATH,  
was also the only place where JsonExprState's empty and error flags  
got reset for a new row.  Skipping it left the flags as the previous  
row had set them, and since execution then fell through the  
ON EMPTY / ON ERROR steps that check those flags, a NULL-input row  
returned the previous row's ON EMPTY / ON ERROR expression instead of  
NULL, making the result depend on the order of the input rows.  
  
This could only happen when ExecInitJsonExpr() had emitted the  
ON EMPTY / ON ERROR steps for the NULL-input row to fall through,  
which it does unless the corresponding expression is a NULL constant  
and the RETURNING type is not a domain.  So JSON_VALUE and JSON_QUERY  
with their default NULL ON EMPTY / NULL ON ERROR behaviors were not  
affected, but JSON_EXISTS, whose default is FALSE ON ERROR, was.  
  
Fix by pointing those JUMP_IF_NULL steps at EEOP_JSONEXPR_PATH itself  
and dropping the CONST NULL step.  ExecEvalJsonExprPath() now returns  
NULL for NULL input after resetting the flags, skipping jsonpath  
evaluation and the ON EMPTY / ON ERROR steps as before, but still  
jumping to the coercion steps when RETURNING a domain type so that its  
constraints are checked.  
  
Oversight in commit 6185c9737cf, so back-patch to 17.  
  
Bug: #19621  
Reported-by: Suyang Zhong <syzhong16@gmail.com>  
Author: jian he <jian.universality@gmail.com>  
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Tested-by: Manu <manuelreyesbravo@gmail.com>  
Discussion: https://postgr.es/m/19621-0a480d2dc74e6bd5@postgresql.org  
Backpatch-through: 17  

commit   : fa0806647f5ffeb3c4536e218b8f2f4161ce3477    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:16:26 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:16:26 +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   : bfbb3d84209f60698f327ad54176240d27e5ee2a    
  
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