PostgreSQL 17.12 commit log

commit   : 702b3dc86d35bcc08c8e23cffa3c4d9fe9d32c85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 15:11:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 15:11:08 -0500    

commit   : 18c4a9c5f66a1fdf02be21751b931338a04d5790    
  
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   : 3643ce4253f32925cae26651eeeb0cb972af81b8    
  
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   : 5f8d39154b401aaade47971f32c8ef9a4881228c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : d0b52be9b1191423d8b601fb1c7c1dee96c9c038    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : 9f6302533e7fcfc3dd5444620dffbdf2102948ec    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : bcbcbd5a23c6740a55d024a5e24c003fc1f2891a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : deebcc772b5b27bfaa2d20608ca77a1439fc252c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : db59ee006aa461afcc007eb4a70aa5bb5c8b73dd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : 3b2c73d0ec03996cdf6047dc407468d976221978    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : f397e0ae3428fc4d5c6dcbf243130e8ce0435c7a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : d3d599625d0312a834d403e209f0500d7475c40d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:49 -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   : 05283881a75e2a19919e1fb0fa54748585de0d4d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 98e9001cf417e8970122c4581c2e8b462285e02b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : d5cf40e02cef7a4c195b0814cfd9481404446700    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : a17bc8b3cac07360fd2331fa3a907394617caa68    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 55c00bffe79616f66153e3bc9c04f6297a8eecd9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 0b8d1768f2def0800b651aee63447aea79b1493d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 695d72c57eb1074e324463308ea8e4bd0dee7fec    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : a14aacebeb426e1d91b5813cb1a502305ee0a9e0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : bef80ad61bfd90710b261c58f9c48203d0ce7961    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 5e99fab61471a6967730f067852cce4a178c18bc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 3a3eb761619cfd24fb3817628ccec699f2cc9187    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : f4d200615f24a20f1507adf127aad4d944e24f9c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 354d5c71b1257da60f3186367c0b4c6f1d9cb692    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : ea9b427faa3aedff241548b9164ccd496857021a    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 9c677791d3f7b60e78d5fc3d45e34ce1367eee86    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 5da4d4b1b4c613f080a4ade4bdaeef2eb7859578    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 83ec4accdcec1dccb3b7ecab7567af8938834145    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 800e673510f666e5b04ccab96c233cc8b438b46b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : d4f8c3e15eff25dde290cfd828dec943e6e9bb6e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : b019147c91546d732df09d1f8fbe852871a0c2ea    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : f234ae72be7f115fc825985805e88951d2086d3b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:48 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:48 -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   : 23a1d88253c136a985e8e969037b28ced41a6b16    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : b65b69f2c16e2be76278184e7615b3273cfbbeaa    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 7e1aeaad34fbede9c23cc9c6dd2f92d4864af514    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 1e3b37da9f225d911227e55f7553c682298083b8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 7d089b28c5e0744e14f5cd5f9c5a0f2f00a994a4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : fbee8e90f7d45f83fb639139e49774b42fc0ec59    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 11658b4df7f1cf47a580fc683256b974dcc66f1e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 3e8bb75c864196e4dcb65d494884e1d4be1f197d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : bfcb6625eaae6956cd8cb9c06745ea342c253ac5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 33f4232cbe0a20381ed55c1ce850cbdfb7fa1d89    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 46c7529fa636d40c66cf6e99ffeea243181e6cdc    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 9532d4c94e90e69f2b9b69d5aa5440509d60cd75    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 7f51d62e115503bfc1a9997089aece2935d99185    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 4d3c1372455c7c493ccbee98dbb07eb334d21c46    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 438b435f0810ea550f1650cc7b26177c87b543b7    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 4cd18df09917c856b79615dfa23aa4cd5ee7c23d    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : e0bd77667310243f2c6eb60deb3a170fb30d766e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 3f082dcc7b53d40a44752b72268ab1f2413bf011    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : a6dc99b284296ec48190883e737e1a1ebaefddbe    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : 21c732aadf80b20721314cb59a838f9634ab2195    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:47 -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   : b24a45486cdd1458c0d948c71bf0f2432bded9b6    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 445e10c5041aa098bed835a3f0812763a4ad50e1    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 9520dbea70842cbf357e611c110c38c3427d8692    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 36f42216eb6135c3de6a12607d49f516c5d0dfad    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 5c751533737eb08c97d6816e43039324e34bad42    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 79f9793fc44c75d3096ef67677a729ad21a89c2c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 23e7e2bde0c80df73fc5604a4f9e0f9f2a34ac65    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 22f838a6d5eabb8ca50e0afbb3a09543298733c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 2009539be115a1be8f8c57fac69cba9d95fac7d6    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : a5a82b4d27b0294eb0033f09959d8587120a4ea3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : a4d40a6ae9f0c0d68a26ea625d50f9a22e0cfc41    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : dd2cd3803920a923d63380e91f8e0c17725d190c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 02ca67429a264b3b16bf28532404eec4853a579f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : f34ccffddbe59d313d214d2a584147e735e00219    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 2680b0781ac853736be8c93f85c6f581ef5d805f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 606c23540b9039380d8ef940657bd44bc54eff1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 6e5524cdad1064d660a9d349649dcb4f6c9d3cc4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : eab8001348eed01401e06b4aa4876817dff005ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : d1883981a146996edbf26cb8a5f49a70c1e92e69    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 62a19e1588d617dd03137525e94b63b1edd9c64f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 217eb08b45c5e90d3f084a4de42590da229541a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 9d15ca06332471d25e863e6a844879da9742faa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 5788eaee3f2efd9cd6f01b27dfb49d96d9f2dd0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 7f8424ece5d078becf0c018ef33e3866218de023    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : cacc71935952b1e47d852a9e9be3a548fc5ac40e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : 3094cdb7d97384eb18587908f10583462a997a44    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 9 Nov 2026 06:20:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:46 -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   : dcc32e7d92b7558f2c4e2dfaffbed5ec8ceb51c4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Nov 2026 06:20:45 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:45 -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   : 04986ad59d6167d3ed884a2045b99fca8a9733a8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 06:20:45 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2026 06:20:45 -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   : f3f9bf05b30e221aa6d8cb741adf670a1962d5f5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:20:29 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2026 12:20:29 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 5ad37e2a22a02d3174730415001146bd511a842a  

commit   : 74194d895e22da2a292598ea321c83b17505da95    
  
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   : e6b2f7c2b41d6261dac15825dede55e94ca35614    
  
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   : b2b1910d9ab30bdb30b10c09e8c7813c74216b88    
  
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   : 03550d3cfb941af2cc5312d8b8efcf90b8d8dbec    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 6 Nov 2026 16:18:29 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 6 Nov 2026 16:18:29 +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   : 2a3ac15548c6318a33e954b9858284bc05e62bc8    
  
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   : 134dc506ee9bb4698f203236b0e35cb371380eda    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 10:45:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 10:45:11 +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   : 5b80ddaf69027052e19f8cd73e499fb6f8a0cb03    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:22 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:22 -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   : 7c78c8cff4df94df1bc1a053ccc105d2868b6a92    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:21 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 5 Nov 2026 16:54:21 -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   : 61b06d2ba61d04398585d6d06b1ee5f4cd53c3b5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 09:18:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Nov 2026 09:18:42 +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   : dfd98ce58eae35ae264ccd3ca210a3d574ac5927    
  
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   : 0733c72198c9d49b239703a01d9fb5ecba7d04fb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Nov 2026 18:07:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Nov 2026 18:07:48 +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   : 31af62f380c658301061f484e94151f1ef71b013    
  
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   : 775e03191fa663b523363e6fa1eb7c3f1d565350    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:38:02 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:38:02 +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   : f116737684c28526e90f262098027fb7ddb518cd    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:16:20 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 5 Nov 2026 08:16:20 +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   : 9171fca990e668a0fb50008232722e835878cdd1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 5 Nov 2026 10:21:17 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 5 Nov 2026 10:21:17 +1300    

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

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

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

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

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

commit   : f3ea7cb465a765146133046ef02f5cea3341c6b4    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:50:52 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Wed, 4 Nov 2026 14:50:52 +0900    

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

commit   : edbb2813746de72e0a7ae20bd7ebe5b37fb78b23    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 4 Nov 2026 15:56:46 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 4 Nov 2026 15:56:46 +1300    

12933dc60 (originally 66c0185a3) added setop_pathkeys for providing  
presorted inputs for set operation from child queries when that query  
doesn't have any other pathkey requirements.  
  
add_foreign_ordered_paths() assumed that if the query had an ORDER BY  
that the query_pathkeys would be equal to sort_pathkeys.  That's not  
true when query_pathkeys is set to setop_pathkeys, which can happen  
for set-op child queries with an ORDER BY when all the sort_pathkeys are  
redundant pathkeys. (See standard_qp_callback()).  
  
Here we relax the Assert to allow for sort_pathkeys to be empty.  In  
this case it is technically ok to mark pushdown_safe as true so that  
postgresGetForeignUpperPaths() allows add_foreign_final_paths() to  
generate paths with the LIMIT clause pushed down.  We don't adjust that  
here as that could cause plan changes in the backbranches.  Let's just  
fix things enough so the Assert doesn't fail and do a proper fix in  
master.  
  
Backpatch to 17 where the setop_pathkeys field was added.  
  
Reported-by: Robins Tharakan <tharakan@gmail.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Robins Tharakan <tharakan@gmail.com>  
Discussion: https://postgr.es/m/CAEP4nAwnSefmi4w+89XbHQ0f-0OixCYUJo9kVcbXSYL8L4rEPg@mail.gmail.com  
Backpatch-through: 17  

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

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

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

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

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

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

commit   : b6090b039be788f4258662f3a427a58238277f56    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 15:03:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 15:03:52 +0900    

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

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

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

commit   : ecb43083fe34ebd2b00263c90dcf1ffc63b4c2a4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 13:03:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 13:03:38 +0900    

After a failover, an incremental backup could accept a prior backup  
whose WAL range extends beyond the point where the new primary left the  
old timeline. Combining these backups could retain pages from the  
abandoned history, producing a corrupt backup that might still recover  
and start successfully.  
  
The validation checked the end of the prior backup's final WAL range  
against the new backup's start LSN, but not against the timeline's  
switch point. This allowed an incompatible prior backup to pass  
validation once the new primary had advanced far enough.  
  
Reject incremental backups if the prior backup's final WAL range  
extends beyond the timeline's switch point.  
  
Backpatch to v17, where incremental backup was introduced.  
  
Author: Sai Pranav <rajasaipranav0@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAPHduZC9pWm_vjznmhZNFsDZKLimqc6dKXOozLUKZVPs19zbZg@mail.gmail.com  
Backpatch-through: 17  

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

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

commit   : 6d34d5500e9dad93f2514295cc350fced1ec843e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:46:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Nov 2026 10:46:41 +0900    

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

commit   : db7e885d093f96ffdf70bbb5dae92fa2fa13a031    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 3 Nov 2026 09:49:37 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 3 Nov 2026 09:49:37 +0900    

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

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