PostgreSQL 18.0 commit log

commit   : 3d6a828938a5fa0444275d3d2f67b64ec3199eb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Sep 2025 16:11:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Sep 2025 16:11:33 -0400    

commit   : 9bbcec6030a2744d83311370ec92213fbd76e514    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Sep 2025 14:18:56 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Sep 2025 14:18:56 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 9e968777f6022b6347cd08ae6bdc324e49e622ec  

commit   : ec8a75ae8debea768c6ebebdd3fc83d841aac5e7    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 22 Sep 2025 10:20:07 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 22 Sep 2025 10:20:07 +0200    

This reverts commit 987e00fa990fc905fe8fab645a16f7a4be3d9126 due  
to me missing the release freeze.  

commit   : 987e00fa990fc905fe8fab645a16f7a4be3d9126    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 22 Sep 2025 10:12:31 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 22 Sep 2025 10:12:31 +0200    

Remove stray whitespace in xref tag.  
  
This was found due to a regression in xmllint 2.15.0 which flagged  
this as an error, and at the time of this commit no fix for xmllint  
has shipped.  
  
Author: Erik Wienhold <ewie@ewie.name>  
Discussion: https://postgr.es/m/f4c4661b-4e60-4c10-9336-768b7b55c084@ewie.name  
Backpatch-through: 17  

commit   : ed93b291c91fb2fe2e5c57913cc0dbff72fc0f08    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 09:04:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 09:04:20 +0900    

This reverts commit 5f565b0aee90 temporarily on v18.  This branch is in  
a release freeze state until tagged.  Let's re-add this commit once the  
release is out.  The other branches are left untouched.  
  
Discussion: https://postgr.es/m/2775358.1758498584@sss.pgh.pa.us  

commit   : 5f565b0aee90ef94fbfcfce0beadc10c0ccdd463    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 08:03:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Sep 2025 08:03:25 +0900    

The package for the UUID library may be named "uuid" or "ossp-uuid", and  
meson.build has been using a single call of dependency() with multiple  
names, something only supported since meson 0.60.0.  
  
The minimum version of meson supported by Postgres is 0.57.2 on HEAD,  
since f039c2244110, and 0.54 on stable branches down to 16.  
  
Author: Oreo Yang <oreo.yang@hotmail.com>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/OS3P301MB01656E6F91539770682B1E77E711A@OS3P301MB0165.JPNP301.PROD.OUTLOOK.COM  
Backpatch-through: 16  

commit   : b585f25284d24d2e3fe19e81583c2b458b2a3efc    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 19 Sep 2025 15:07:41 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 19 Sep 2025 15:07:41 -0500    

Author: Nathan Bossart <nathandbossart@gmail.com>  
Co-authored-by: "Jonathan S. Katz" <jkatz@postgresql.org>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Erik Rijkers <er@xs4all.nl>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/aLMo7lJKg8bWUs3y%40momjian.us  
Backpatch-through: 18 only  

commit   : 142885d380533b5ad4ecbaae49760dc9e21d5892    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 Sep 2025 14:28:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 Sep 2025 14:28:28 +0200    

Author: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CADkLM%3DfGrtKiQMv6GSoxyghtTxB_6b1FQUB7fhQG00%3DLhuizPg%40mail.gmail.com  

commit   : 6fa2688a9d63c190da0f19eb61a23b72eea110a2    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 19 Sep 2025 23:35:53 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 19 Sep 2025 23:35:53 +1200    

Initially this was to fix the "catched" typo, but I (David) wasn't quite  
clear on what the previous comment meant about being "effective".  I  
expect this means efficiency, so I've reworded the comment to indicate  
that.  
  
While this is only a comment fixup, for the sake of possibly minimizing  
possible future backpatching pain, I've opted to backpatch to 18 since  
this code is new to that version and the release isn't out the door yet.  
  
Author: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAHewXNmSYWPud1sfBvpKbCJeRkWeZYuqatxtV9U9LvAFXBEiBw@mail.gmail.com  
Backpatch-through: 18  

commit   : 9a82a64edcd8615cf16eae64bf1572d4156cb912    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 19 Sep 2025 11:39:06 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 19 Sep 2025 11:39:06 +0900    

Commit bb3ec16e14 moved partition pruning metadata into PlannedStmt.  
At executor startup this metadata is used to initialize the EState  
fields es_part_prune_infos, es_part_prune_states, and  
es_part_prune_results.  EvalPlanQualStart() failed to copy those  
fields into the child EState, causing NULL dereference when Append  
ran partition pruning during a recheck. This can occur with DELETE  
or UPDATE on partitioned tables that use runtime pruning, e.g. with  
generic plans.  
  
Fix by copying all partition pruning state into the EPQ estate.  
  
Add an isolation test that reproduces the crash with concurrent  
UPDATE and DELETE on a partitioned table, where the DELETE session  
hits the crash during its EPQ recheck after the UPDATE commits.  
  
Bug: #19056  
Reported-by: Fei Changhong <feichanghong@qq.com>  
Diagnozed-by: Fei Changhong <feichanghong@qq.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Co-authored-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/19056-a677cef9b54d76a0%40postgresql.org  

commit   : 144de0341bde9cab7a6b629a3d9041be54486d96    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Sep 2025 11:29:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Sep 2025 11:29:36 -0400    

Backpatch-through: 18 only  

commit   : b4879afdf5bf6664a95e9591ff975ff5c0e2985a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Sep 2025 10:20:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Sep 2025 10:20:16 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-Wz=5aGnkPsLH9u1kZED=M8TKvxX2b9XmgdOe+ePO0KxwcQ@mail.gmail.com  
  
Backpatch-through: 18 only  

commit   : 7aecc00b3d66162b7a9554cd922c5316db5cb8a0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 18 Sep 2025 11:09:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 18 Sep 2025 11:09:15 +0900    

Previously, pg_restore did not skip security labels on publications or  
subscriptions even when --no-publications or --no-subscriptions was specified.  
As a result, it could issue SECURITY LABEL commands for objects that were  
never created, causing those commands to fail.  
  
This commit fixes the issue by ensuring that security labels on publications  
and subscriptions are also skipped when the corresponding options are used.  
  
Backpatch to all supported versions.  
  
Author: Jian He <jian.universality@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 13  

commit   : 4eab456494e3fc20dc0a10dac0466d344c9fbfaf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Sep 2025 16:32:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Sep 2025 16:32:57 -0400    

If an aggregate function call contains a sub-select that has  
an RTE referencing a CTE outside the aggregate, we must treat  
that reference like a Var referencing the CTE's query level  
for purposes of determining the aggregate's level.  Otherwise  
we might reach the nonsensical conclusion that the aggregate  
should be evaluated at some query level higher than the CTE,  
ending in a planner error or a broken plan tree that causes  
executor failures.  
  
Bug: #19055  
Reported-by: BugForge <dllggyx@outlook.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19055-6970cfa8556a394d@postgresql.org  
Backpatch-through: 13  

commit   : 6e8286f9a15325b6354a682a9106b4035dba0f17    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Sep 2025 10:16:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Sep 2025 10:16:10 +0900    

The pending entry was not used when incrementing its data, directly  
manipulating the shared memory pointer, without even locking it.  This  
could mean losing statistics under concurrent activity.  The flush  
callback was a no-op.  
  
This code serves as a base template for extensions for the custom  
cumulative statistics, so let's be clean and use a pending entry for the  
incrementations, whose data is then flushed to the corresponding entry  
in the shared hashtable when all the stats are reported, in its own  
flush callback.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0v0U0yhPbY+bqChomkPbyUrRQ3rQXnZf_SB-svDiQOpgQ@mail.gmail.com  
Backpatch-through: 18  

commit   : dd74e599b8f639fbccc3655d3856a56a6b8d4288    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Sep 2025 09:33:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Sep 2025 09:33:35 +0900    

The shared memory size was calculated based on an offset of io_handles,  
which is itself a pointer included in the structure.  We tend to  
overestimate the shared memory size overall, so this was unlikely an  
issue in practice, but let's be correct and use the full size of the  
structure in the calculation, so as the pointer for io_handles is  
included.  
  
Oversight in da7226993fd4.  
  
Author: Madhukar Prasad <madhukarprasad@google.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Discussion: https://postgr.es/m/CAKi+wrbC2dTzh_vKJoAZXV5wqTbhY0n4wRNpCjJ=e36aoo0kFw@mail.gmail.com  
Backpatch-through: 18  

commit   : 78e6047dcea588ec127f6a71c7cebd5c0f41d795    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 12:19:51 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 12:19:51 +1200    

The EvalPlanQual recheck for TID Range Scan wasn't rechecking the TID qual  
still passed after following update chains.  This could result in tuples  
being updated or deleted by plans using TID Range Scans where the ctid of  
the new (updated) tuple no longer matches the clause of the scan.  This  
isn't desired behavior, and isn't consistent with what would happen if the  
chosen plan had used an Index or Seq Scan, and that could lead to hard to  
predict behavior for scans that contain TID quals and other quals as the  
planner has freedom to choose TID Range or some other non-TID scan method  
for such queries, and the chosen plan could change at any moment.  
  
Here we fix this by properly implementing the recheck function for TID  
Range Scans.  
  
Backpatch to 14, where TID Range Scans were added  
  
Reported-by: Sophie Alpert <pg@sophiebits.com>  
Author: Sophie Alpert <pg@sophiebits.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/4a6268ff-3340-453a-9bf5-c98d51a6f729@app.fastmail.com  
Backpatch-through: 14  

commit   : bae6c74ba4e4e4fdbb45e45569a5b53f27590b1c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:49:26 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 17 Sep 2025 11:49:26 +1200    

The EvalPlanQual recheck for TID Scan wasn't rechecking the TID qual  
still passed after following update chains.  This could result in tuples  
being updated or deleted by plans using TID Scans where the ctid of the  
new (updated) tuple no longer matches the clause of the scan.  This isn't  
desired behavior, and isn't consistent with what would happen if the  
chosen plan had used an Index or Seq Scan, and that could lead to hard to  
predict behavior for scans that contain TID quals and other quals as the  
planner has freedom to choose TID or some other scan method for such  
queries, and the chosen plan could change at any moment.  
  
Here we fix this by properly implementing the recheck function for TID  
Scans.  
  
Backpatch to 13, oldest supported version  
  
Reported-by: Sophie Alpert <pg@sophiebits.com>  
Author: Sophie Alpert <pg@sophiebits.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/4a6268ff-3340-453a-9bf5-c98d51a6f729@app.fastmail.com  
Backpatch-through: 13  

commit   : ef5ee0e346182600015b38eb41cace179ce6566f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 14:36:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 14:36:51 -0400    

Cover contrib/pgcrypto, per buildfarm.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/443709.1757876535@sss.pgh.pa.us  
Backpatch-through: 17  

commit   : cc7053a5fe08883801057faa70101dcf99f0d071    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 13:05:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 13:05:53 -0400    

This reverts commit 98fc31d6499163a0a781aa6f13582a07f09cd7c6.  
That change allowed DROP OWNED BY to drop grants of the target  
role to other roles, arguing that nobody would need those  
privileges anymore.  But that's not so: if you're not superuser,  
you still need admin privilege on the target role so you can  
drop it.  
  
It's not clear whether or how the dependency-based approach  
to solving the original problem can be adapted to keep these  
grants.  Since v18 release is fast approaching, the sanest  
thing to do seems to be to revert this patch for now.  The  
race-condition problem is low severity and not worth taking  
risks for.  
  
I didn't force a catversion bump in 98fc31d64, so I won't do  
so here either.  
  
Reported-by: Dipesh Dhameliya <dipeshdhameliya125@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CABgZEgczOFicCJoqtrH9gbYMe_BV3Hq8zzCBRcMgmU6LRsihUA@mail.gmail.com  
Backpatch-through: 18  

commit   : 4ad846445dd0a1596ca7bfeb5b2ea93f6d7a751d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 16 Sep 2025 09:40:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 16 Sep 2025 09:40:44 -0700    

The COMMENT should depend on the separately-dumped constraint, not the  
domain.  Sufficient restore parallelism might fail the COMMENT command  
by issuing it before the constraint exists.  Back-patch to v13, like  
commit 0858f0f96ebb891c8960994f023ed5a17b758a38.  
  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/20250913020233.fa.nmisch@google.com  
Backpatch-through: 13  

commit   : dad1e259dfa95edd07bf9a890fbb103dc35057ce    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 16 Sep 2025 11:48:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 16 Sep 2025 11:48:48 -0400    

Reported-by: Yugo Nagata  
  
Author: Yugo Nagata  
  
Discussion: https://postgr.es/m/20250901200148.baca5744b27419c87c323362@sraoss.co.jp  
  
Backpatch-through: 18 only  

commit   : 9e2c58417342f71f921543ad36df423459196368    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 10:09:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Sep 2025 10:09:49 -0400    

In our previous discussions around making our regression tests  
pass in FIPS mode, we concluded that we didn't need to support  
the different error message wording observed with pre-3.0 OpenSSL.  
However there are still a few LTS distributions soldiering along  
with such versions, and now we have some in the buildfarm.  
So let's add the variant expected-files needed to make them happy.  
  
This commit only covers the core regression tests.  Previous  
discussion suggested that we might need some adjustments in  
contrib as well, but it's not totally clear to me what those  
would be.  Rather than work it out from first principles,  
I'll wait to see what the buildfarm shows.  
  
Back-patch to v17 which is the oldest branch that claims  
to support this case.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/443709.1757876535@sss.pgh.pa.us  
Backpatch-through: 17  

commit   : d29a3f4b46a043323dd5f39e9b97f1aaabbbec87    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 16 Sep 2025 18:42:20 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 16 Sep 2025 18:42:20 +0900    

JsonConstructorExpr can produce non-NULL output with a NULL input, so  
it should be treated as a non-strict construct.  Failing to do so can  
lead to incorrect query behavior.  
  
For example, in the reported case, when pulling up a subquery that is  
under an outer join, if the subquery's target list contains a  
JsonConstructorExpr that uses subquery variables and it is mistakenly  
treated as strict, it will be pulled up without being wrapped in a  
PlaceHolderVar.  As a result, the expression will be evaluated at the  
wrong place and will not be forced to null when the outer join should  
do so.  
  
Back-patch to v16 where JsonConstructorExpr was introduced.  
  
Bug: #19046  
Reported-by: Runyuan He <runyuan@berkeley.edu>  
Author: Tender Wang <tndrwang@gmail.com>  
Co-authored-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/19046-765b6602b0a8cfdf@postgresql.org  
Backpatch-through: 16  

commit   : 409543da5411d55d3455d6acbd885f592f20c429    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Sep 2025 08:59:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Sep 2025 08:59:12 +0200    

Fix for commit 3c86223c998.  That commit moved the typedef of pg_int64  
from postgres_ext.h to libpq-fe.h, because the only remaining place  
where it might be used is libpq users, and since the type is obsolete,  
the intent was to limit its scope.  
  
The problem is that if someone builds an extension against an  
older (pre-PG18) server version and a new (PG18) libpq, they might get  
two typedefs, depending on include file order.  This is not allowed  
under C99, so they might get warnings or errors, depending on the  
compiler and options.  The underlying types might also be  
different (e.g., long int vs. long long int), which would also lead to  
errors.  This scenario is plausible when using the standard Debian  
packaging, which provides only the newest libpq but per-major-version  
server packages.  
  
The fix is to undo that part of commit 3c86223c998.  That way, the  
typedef is in the same header file across versions.  At least, this is  
the safest fix doable before PostgreSQL 18 releases.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://www.postgresql.org/message-id/25144219-5142-4589-89f8-4e76948b32db%40eisentraut.org  

commit   : 176002c5bfa61421497b382e9a4b4f7315dda42d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 16:44:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 16:44:58 +0900    

Previously, pg_dump incorrectly queried pg_seclabel to retrieve security labels  
for subscriptions, which are stored in pg_shseclabel as they are global objects.  
This could result in security labels for subscriptions not being dumped.  
  
This commit fixes the issue by updating pg_dump to query the pg_seclabels view,  
which aggregates entries from both pg_seclabel and pg_shseclabel.  
While querying pg_shseclabel directly for subscriptions was an alternative,  
using pg_seclabels is simpler and sufficient.  
  
In addition, pg_dump is updated to dump security labels on event triggers,  
which were previously omitted.  
  
Backpatch to all supported versions.  
  
Author: Jian He <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 13  

commit   : e179115dc04159eb364ffda88fed82e511aff0f7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Sep 2025 07:23:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Sep 2025 07:23:50 +0200    

Commit 7202d72787d added in passing some const qualifiers, but the one  
on the postmaster_child_launch() startup_data argument was incorrect,  
because the function itself modifies the pointed-to data.  This is  
hidden from the compiler because of casts.  The qualifiers on the  
functions called by postmaster_child_launch() are still correct.  

commit   : 2ddbfede0c615c009bbbb0f8dfcaa848da5d2376    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 11:54:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 11:54:23 +0900    

Previously, pg_restore did not skip comments on policies even when  
--no-policies was specified. As a result, it could issue COMMENT commands  
for policies that were never created, causing those commands to fail.  
  
This commit fixes the issue by ensuring that comments on policies  
are also skipped when --no-policies is used.  
  
Backpatch to v18, where --no-policies was added in pg_restore.  
  
Author: Jian He <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 18  

commit   : 77d2b155caf716354a3519233f2cef3369984a65    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 10:35:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Sep 2025 10:35:12 +0900    

Previously, pg_restore did not skip comments on publications or subscriptions  
even when --no-publications or --no-subscriptions was specified. As a result,  
it could issue COMMENT commands for objects that were never created,  
causing those commands to fail.  
  
This commit fixes the issue by ensuring that comments on publications and  
subscriptions are also skipped when the corresponding options are used.  
  
Backpatch to all supported versions.  
  
Author: Jian He <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHCt00pR9h51AVu6+yPD5J7JQn=7dQXxqacj0XyDhc-fA@mail.gmail.com  
Backpatch-through: 13  

commit   : e7a2bbdb522dd6fc7283550742b8b52605198783    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 16:27:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 16:27:50 +0200    

Virtual generated columns in constraint expressions need to be  
expanded because the optimizer matches these expressions to qual  
clauses.  Failing to do so can cause us to miss opportunities for  
constraint exclusion.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/204804c0-798f-4c72-bd1f-36116024fda3%40eisentraut.org  

commit   : 38883916e41c5d3f3367b221b37838c3999227e2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 11:38:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 11:38:58 +0200    

The previous change (commit f225473cbae) was still not on target,  
because it talked about relation kinds, which are not what is being  
checked here.  Provide a more accurate message.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACJufxEZ48toGH0Em_6vdsT57Y3L8pLF=DZCQ_gCii6=C3MeXw@mail.gmail.com  

commit   : c11ac811a30db4159543f8399f3c0b723369fa20    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 08:13:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 08:13:21 +0200    

LLVM-21 renamed llvm::GlobalValue::getGUID() to  
getGUIDAssumingExternalLinkage(), so add a version guard.  
  
Author: Holger Hoffstätte <holger@applied-asynchrony.com>  
Discussion: https://www.postgresql.org/message-id/flat/d25e6e4a-d1b4-84d3-2f8a-6c45b975f53d%40applied-asynchrony.com  

commit   : 8309f3f86da8103f53193b218cabe4b904550b4a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 07:25:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Sep 2025 07:25:22 +0200    

If extensions of equal names were installed in different directories  
in the path, the views pg_available_extensions and  
pg_available_extension_versions would show all of them, even though  
only the first one was actually reachable by CREATE EXTENSION.  To  
fix, have those views skip extensions found later in the path if they  
have names already found earlier.  
  
Also add a bit of documentation that only the first extension in the  
path can be used.  
  
Reported-by: Pierrick <pierrick.chovelon@dalibo.com>  
Discussion: https://www.postgresql.org/message-id/flat/8f5a0517-1cb8-4085-ae89-77e7454e27ba%40dalibo.com  

commit   : bee763aea13ff27ade2fe4704eaf6605b0ad4d65    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 13 Sep 2025 21:01:31 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 13 Sep 2025 21:01:31 -0400    

The TimescaleDB extension expects to be able to change an nbtree scan's  
keys across rescans.  The issue arises in the extension's implementation  
of loose index scan.  This is arguably a misuse of the index AM API,  
though apparently it worked until recently.  It stopped working when the  
skipScan flag was added to BTScanOpaqueData by commit 8a510275, though.  
The flag wouldn't reliably track whether the scan (actually, the current  
rescan) has any skip arrays, leading to confusion in _bt_set_startikey.  
  
nbtree preprocessing will now defensively initialize the scan's skipScan  
flag in all cases, including the case where _bt_preprocess_array_keys  
returns early due to the (re)scan not using arrays.  While nbtree isn't  
obligated to support this use case (at least not according to my reading  
of the index AM API), it still seems like a good idea to be consistent  
here, on general robustness grounds.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Natalya Aksman <natalya@timescale.com>  
Discussion: https://postgr.es/m/CAJumhcirfMojbk20+W0YimbNDkwdECvJprQGQ-XqK--ph09nQw@mail.gmail.com  
Backpatch-through: 18  

commit   : 802308693f2f55704751657986abdc81f76ee4cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Sep 2025 16:55:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Sep 2025 16:55:51 -0400    

Commit e3ffc3e91 fixed the translation of character classes in  
SIMILAR TO regular expressions.  Unfortunately the fix broke a corner  
case: if there is an escape character right after the opening bracket  
(for example in "[\q]"), a closing bracket right after the escape  
sequence would not be seen as closing the character class.  
  
There were two more oversights: a backslash or a nested opening bracket  
right at the beginning of a character class should remove the special  
meaning from any following caret or closing bracket.  
  
This bug suggests that this code needs to be more readable, so also  
rename the variables "charclass_depth" and "charclass_start" to  
something more meaningful, rewrite an "if" cascade to be more  
consistent, and improve the commentary.  
  
Reported-by: Dominique Devienne <ddevienne@gmail.com>  
Reported-by: Stephan Springl <springl-psql@bfw-online.de>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFCRh-8NwJd0jq6P=R3qhHyqU7hw0BTor3W0SvUcii24et+zAw@mail.gmail.com  
Backpatch-through: 13  

commit   : 01bea6029df3f03902cc7795459fd8678cc51625    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 13 Sep 2025 14:58:49 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 13 Sep 2025 14:58:49 -0500    

commit   : 17a5ca58eb119a33e81e57b72618236538932167    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 13 Sep 2025 14:50:02 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 13 Sep 2025 14:50:02 -0500    

Backpatch-through: 18  

commit   : ef81db9697a082300b452c8dd6824d2d07f5f557    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Sep 2025 17:43:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Sep 2025 17:43:15 -0400    

Commit a0b99fc12 caused pg_event_trigger_dropped_objects()  
to not fill the object_name field for schemas, which it  
should have; and caused it to fill the object_name field  
for default values, which it should not have.  
  
In addition, triggers and RLS policies really should behave  
the same way as we're making column defaults do; that is,  
they should have is_temporary = true if they belong to a  
temporary table.  
  
Fix those things, and upgrade event_trigger.sql's woefully  
inadequate test coverage of these secondary output columns.  
  
As before, back-patch only to v15.  
  
Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/bd7b4651-1c26-4d30-832b-f942fabcb145@postgrespro.ru  
Backpatch-through: 15  

commit   : e457312c0d19b3d4e60f44f7260280a2788c1503    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 12 Sep 2025 13:22:58 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 12 Sep 2025 13:22:58 -0400    

A recently added nbtree preprocessing step failed to account for the  
fact that DESC columns already had their B-Tree strategy number commuted  
at this point in preprocessing.  As a result, preprocessing could output  
a set of scan keys where one or more keys had the correct strategy  
number, but used the wrong comparison routine.  
  
To fix, make the faulty code path that looks up a more restrictive  
replacement operator/comparison routine commute its requested inequality  
strategy (while outputting the transformed strategy number as before).  
This makes the final transformed scan key comport with the approach  
preprocessing has always used to deal with DESC columns (which is  
described by comments above _bt_fix_scankey_strategy).  
  
Oversight in commit commit b3f1a13f, which made nbtree preprocessing  
perform transformations on skip array inequalities that can reduce the  
total number of index searches.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Natalya Aksman <natalya@timescale.com>  
Discussion: https://postgr.es/m/19049-b7df801e71de41b2@postgresql.org  
Backpatch-through: 18  

commit   : 3c0018a6f417425b1e6f2516fe6493596d71bddf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 12 Sep 2025 10:18:31 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 12 Sep 2025 10:18:31 -0400    

Its size was ~3.8GB before, which sometimes was not enough. OpenBSD CI task  
often were failing due to no space left on device. Increase the RAM disk size  
to ~4.6 GB.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAN55FZ2XVVPJRJmGB2DsL3gOrOinWh=HWvj6GO1cHzJ=6LwTag@mail.gmail.com  
Backpatch-through: 18, where openbsd was added to CI  

commit   : 14bb47567a3977cd838f62c4297c2cc4c878e800    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 Sep 2025 07:27:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 Sep 2025 07:27:48 +0200    

Clang 21 shows some new compiler warnings, for example:  
  
warning: variable 'dstsize' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer]  
  
The fix is to initialize the variables when they are defined.  This is  
similar to, for example, the existing situation in gistKeyIsEQ().  
  
Discussion: https://www.postgresql.org/message-id/flat/6604ad6e-5934-43ac-8590-15113d6ae4b1%40eisentraut.org  

commit   : 3c02c46521b01f1e60caff2d056f3da5ee98ce58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Sep 2025 17:11:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Sep 2025 17:11:54 -0400    

pg_event_trigger_dropped_objects() would report a column default  
object with is_temporary = false, even if it belongs to a  
temporary table.  This seems clearly wrong, so adjust it to  
report the table's temp-ness.  
  
While here, refactor EventTriggerSQLDropAddObject to make its  
handling of namespace objects less messy and avoid duplication  
of the schema-lookup code.  And add some explicit test coverage  
of dropped-object reports for dependencies of temp tables.  
  
Back-patch to v15.  The bug exists further back, but the  
GetAttrDefaultColumnAddress function this patch depends on does not,  
and it doesn't seem worth adjusting it to cope with the older code.  
  
Author: Antoine Violin <violin.antuan@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFjUV9x3-hv0gihf+CtUc-1it0hh7Skp9iYFhMS7FJjtAeAptA@mail.gmail.com  
Backpatch-through: 15  

commit   : 3e43a7b1ab971ed22e663891d941d4d00b6dd9fe    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Sep 2025 11:55:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Sep 2025 11:55:29 +0200    

The Sun Studio compiler complains about an empty declaration here.  
  
Note for future historians:  This does not mean that this compiler is  
still of current interest for anyone using PostgreSQL.  But we can let  
this small fix be its parting gift.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/a0f817ee-fb86-483a-8a14-b6f7f5991b6e%40eisentraut.org  

commit   : a4e87604bcdfb6b877b16cc767b2ed15411c7342    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 17:17:24 +0900    

hash_xlog.h included descriptions for the blocks used in WAL records  
that were was not completely consistent with how the records are  
generated, with one block missing for SQUEEZE_PAGE, and inconsistent  
descriptions used for block 0 in VACUUM_ONE_PAGE and MOVE_PAGE_CONTENTS.  
  
This information was incorrect since c11453ce0aea, cross-checking the  
logic for the record generation.  
  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CALdSSPj1j=a1d1hVA3oabRFz0hSU3KKrYtZPijw4UPUM7LY9zw@mail.gmail.com  
Backpatch-through: 13  

commit   : e9682da594403fdb503669ca24f3f589a179cfe4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 10:15:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Sep 2025 10:15:37 +0900    

GucSource_Names was documented as being in guc.c, but since 0a20ff54f5e6  
it is located in guc_tables.c.  The reference to the location of  
GucSource_Names is important, as GucSource needs to be kept in sync with  
GucSource_Names.  
  
Author: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CAKFQuwYPgAHWPYjPzK7iXzhSZ6MKR8w20_Nz7ZXpOvx=kZbs7A@mail.gmail.com  
Backpatch-through: 16  

commit   : bc865ff6d1f0a31e997eb479785f588adf1b7cf8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Sep 2025 16:05:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Sep 2025 16:05:03 -0400    

If the hash functions used for hashing tuples leaked any memory,  
we failed to clean that up, resulting in query-lifespan memory  
leakage in queries using hashed subplans.  One way that could  
happen is if the values being hashed require de-toasting, since  
most of our hash functions don't trouble to clean up de-toasted  
inputs.  
  
Prior to commit bf6c614a2, this leakage was largely masked  
because TupleHashTableMatch would reset hashtable->tempcxt  
(via execTuplesMatch).  But it doesn't do that anymore, and  
that's not really the right place for this anyway: doing it  
there could reset the tempcxt many times per hash lookup,  
or not at all.  Instead put reset calls into ExecHashSubPlan  
and buildSubPlanHash.  Along the way to that, rearrange  
ExecHashSubPlan so that there's just one place to call  
MemoryContextReset instead of several.  
  
This amounts to accepting the de-facto API spec that the caller  
of the TupleHashTable routines is responsible for resetting the  
tempcxt adequately often.  Although the other callers seem to  
get this right, it was not documented anywhere, so add a comment  
about it.  
  
Bug: #19040  
Reported-by: Haiyang Li <mohen.lhy@alibaba-inc.com>  
Author: Haiyang Li <mohen.lhy@alibaba-inc.com>  
Reviewed-by: Fei Changhong <feichanghong@qq.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19040-c9b6073ef814f48c@postgresql.org  
Backpatch-through: 13  

commit   : 87ea6e9b66b64c10c9d203691221dfc8594c7697    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 10 Sep 2025 11:21:12 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 10 Sep 2025 11:21:12 -0500    

autoconf builds have compiled this file with -ftree-vectorize since  
commit 8870917623, but meson builds seem to have missed the memo.  
  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/aL85CeasM51-0D1h%40nathan  
Backpatch-through: 16  

commit   : 21fdc37d219acebd298d2e7b309b111a5174ae4c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Sep 2025 11:49:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Sep 2025 11:49:53 +0200    

In CREATE TABLE ... LIKE, any check constraints copied from the source  
table should be set to valid if they are ENFORCED (the default).  
  
Bug introduced in commit ca87c415e2f.  
  
Author: jian he <jian.universality@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CACJufxH%3D%2Bod8Wy0P4L3_GpapNwLUP3oAes5UFRJ7yTxrM_M5kg%40mail.gmail.com  

commit   : a7024398b80a836a83c00af42c6ab7cc25c12087    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 9 Sep 2025 16:04:04 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 9 Sep 2025 16:04:04 -0700    

Use -funroll-loops and -ftree-vectorize when building checksum.c to  
match what autoconf does.  
  
Missed backport of 9af672bcb2, noticed by Nathan Bossart.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/a81f2f7ef34afc24a89c613671ea017e3651329c.camel@j-davis.com  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Backpatch-through: 16  

commit   : 039301b3fceb00a8c7c6cdf8ccbfaf912dd8cd5f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Sep 2025 07:23:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Sep 2025 07:23:22 +0900    

The startup process does not process shared invalidation messages, only  
sending them, and never calls AtEOXact_SMgr() which clean up any  
unpinned SMgrRelations.  Hence, it is never able to free SMgrRelations  
on a periodic basis, bloating its hashtable over time.  
  
Like the checkpointer and the bgwriter, this commit takes a conservative  
approach by freeing periodically SMgrRelations when replaying a  
checkpoint record, either online or shutdown, so as the startup process  
has a way to perform a periodic cleanup.  
  
Issue caused by 21d9c3ee4ef7, so backpatch down to v17.  
  
Author: Jingtang Zhang <mrdrivingduck@gmail.com>  
Reviewed-by: Yuhang Qiu <iamqyh@gmail.com>  
Discussion: https://postgr.es/m/28C687D4-F335-417E-B06C-6612A0BD5A10@gmail.com  
Backpatch-through: 17  

commit   : a80b7a0547da0dc1dfff5df96b709a9e0321252b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 9 Sep 2025 14:35:30 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 9 Sep 2025 14:35:30 -0500    

This section claims that each backend executes the  
shmem_startup_hook shortly after attaching to shared memory, which  
is true for EXEC_BACKEND builds, but not for others.  This commit  
adds this important detail.  
  
Oversight in commit 964152c476.  
  
Reported-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0vEGT1eigGbVt604LkXP6mUPMwPMxQoRCbFny44w%2B9EUQ%40mail.gmail.com  
Backpatch-through: 17  

commit   : f256a7bba7286058bbf9d5ce160e3237dfe83b79    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 15:52:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 15:52:48 +0900    

A new pgstats entry is created as a two-step process:  
- The entry is looked at in the shared hashtable of pgstats, and is  
inserted if not found.  
- When not found and inserted, its fields are then initialized.  This  
part include a DSA chunk allocation for the stats data of the new entry.  
  
As currently coded, if the DSA chunk allocation fails due to an  
out-of-memory failure, an ERROR is generated, leaving in the pgstats  
shared hashtable an inconsistent entry due to the first step, as the  
entry has already been inserted in the hashtable.  These broken entries  
can then be found by other backends, crashing them.  
  
There are only two callers of pgstat_init_entry(), when loading the  
pgstats file at startup and when creating a new pgstats entry.  This  
commit changes pgstat_init_entry() so as we use dsa_allocate_extended()  
with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure  
instead of failing.  This way, a backend failing an entry creation can  
take appropriate cleanup actions in the shared hashtable before throwing  
an error.  Currently, this means removing the entry from the shared  
hashtable before throwing the error for the allocation failure.  
  
Out-of-memory errors unlikely happen in the wild, and we do not bother  
with back-patches when these are fixed, usually.  However, the problem  
dealt with here is a degree worse as it breaks the shared memory state  
of pgstats, impacting other processes that may look at an inconsistent  
entry that a different process has failed to create.  
  
Author: Mikhail Kot <mikhail.kot@databricks.com>  
Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com  
Backpatch-through: 15  

commit   : fbb8ae2aec009491a72597d051b9f597266e1bd1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 10:07:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Sep 2025 10:07:18 +0900    

The README was missing parse_jsontable.c which handles JSON_TABLE.  
Oversight in de3600452b61.  
  
Author: Karthik S <karthikselvaam@gmail.com>  
Discussion: https://postgr.es/m/CAK4gQD9gdcj+vq_FZGp=Rv-W+41v8_C7cmCUmDeu=cfrOdfXEw@mail.gmail.com  
Backpatch-through: 17  

commit   : c70b6db34ffeab48beef1fb4ce61bcad3772b8dd    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 5 Sep 2025 08:21:35 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 5 Sep 2025 08:21:35 +0100    

When executing a MERGE UPDATE action, if there is more than one  
concurrent update of the target row, the lock-and-retry code would  
sometimes incorrectly identify the latest version of the target tuple,  
leading to incorrect results.  
  
This was caused by using the ctid field from the TM_FailureData  
returned by table_tuple_lock() in a case where the result was TM_Ok,  
which is unsafe because the TM_FailureData struct is not guaranteed to  
be fully populated in that case. Instead, it should use the tupleid  
passed to (and updated by) table_tuple_lock().  
  
To reduce the chances of similar errors in the future, improve the  
commentary for table_tuple_lock() and TM_FailureData to make it  
clearer that table_tuple_lock() updates the tid passed to it, and most  
fields of TM_FailureData should not be relied on in non-failure cases.  
An exception to this is the "traversed" field, which is set in both  
success and failure cases.  
  
Reported-by: Dmitry <dsy.075@yandex.ru>  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/1570d30e-2b95-4239-b9c3-f7bf2f2f8556@yandex.ru  
Backpatch-through: 15  

commit   : a730ad855144d73a29a24cfdb00a5e0f954bdaec    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Sep 2025 14:10:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Sep 2025 14:10:24 +0900    

SlruRecentlyUsed() is an inline function since 53c2a97a9266, not a  
macro.  The description of long_segment_names was missing at the top of  
SimpleLruInit(), part forgotten in 4ed8f0913bfd.  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/aLpBLMOYwEQkaleF@jrouhaud  
Backpatch-through: 17  

commit   : 311340f17863b0f87b3af32649ee5a2a58988b08    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:47:15 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:47:15 +0100    

When executing a MERGE, check that the target relation supports all  
actions mentioned in the MERGE command. Specifically, check that it  
has a REPLICA IDENTITY if it publishes updates or deletes and the  
MERGE command contains update or delete actions. Failing to do this  
can silently break replication.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Tested-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/OS3PR01MB57180C87E43A679A730482DF94B62@OS3PR01MB5718.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : 344662848ac15efc89e09b7d39662d7c71b30e06    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:32:00 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 4 Sep 2025 11:32:00 +0100    

If an INSERT has an ON CONFLICT DO UPDATE clause, the executor must  
check that the target relation supports UPDATE as well as INSERT. In  
particular, it must check that the target relation has a REPLICA  
IDENTITY if it publishes updates. Formerly, it was not doing this  
check, which could lead to silently breaking replication.  
  
Fix by adding such a check to CheckValidResultRel(), which requires  
adding a new onConflictAction argument. In back-branches, preserve ABI  
compatibility by introducing a wrapper function with the original  
signature.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Tested-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/OS3PR01MB57180C87E43A679A730482DF94B62@OS3PR01MB5718.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : c91c61b2417d0c36993deff03f09b1f64c821a1b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Sep 2025 08:34:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Sep 2025 08:34:57 +0900    

The counters saved from pgWalUsage, used for the difference calculations  
when flushing the backend WAL stats, are updated when calling  
pgstat_flush_backend() under PGSTAT_BACKEND_FLUSH_WAL, and not  
pgstat_report_wal().  The comment updated in this commit referenced the  
latter, but it is perfectly OK to flush the backend stats independently  
of the WAL stats.  
  
Noticed while looking at this area of the code, introduced by  
76def4cdd7c2 as a copy-pasto.  
  
Backpatch-through: 18  

commit   : ab4a35b4ea9d2290b1ee5ec25f65df4c739077cb    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Sep 2025 16:00:38 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Sep 2025 16:00:38 +0900    

SubPlan nodes are typically built very early, before any RelOptInfos  
have been constructed for the parent query level.  As a result, the  
simple_rel_array in the parent root has not yet been initialized.  
Currently, during cost estimation of a SubPlan's testexpr, we may call  
examine_variable() to look up statistical data about the expressions.  
This can lead to "no relation entry for relid" errors.  
  
To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since  
the root does not yet contain enough information to safely consult  
statistics.  
  
One exception is SubPlan nodes built for the initplans of MIN/MAX  
aggregates from indexes.  In this case, having a NULL root is safe  
because testexpr will be NULL.  Additionally, an initplan will by  
definition not consult anything from the parent plan.  
  
Backpatch to all supported branches.  Although the reported call path  
that triggers this error is not reachable prior to v17, there's no  
guarantee that other code paths -- especially in extensions -- could  
not encounter the same issue when cost_qual_eval() is called with a  
root that lacks a valid simple_rel_array.  The test case is not  
included in pre-v17 branches though.  
  
Bug: #19037  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org  
Backpatch-through: 13  

commit   : 8df3d355db0fcb56535644c5ea2f4ae6f7dfacdf    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Sep 2025 06:17:08 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Sep 2025 06:17:08 +0000    

Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 18, where it was introduced  
Discussion: https://postgr.es/m/CANhcyEXMrcEdzj-RNGJam0nJHM4y+ttdWsgUCFmXciM7BNKc7A@mail.gmail.com  

commit   : ae53537e218a112676483e50358718d142bcfeb9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 12:54:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 12:54:27 +0900    

PQtrace() was generating its output for non-printable characters without  
casting the characters printed with unsigned char, leading to some extra  
"\xffffff" generated in the output due to the fact that char may be  
signed.  
  
Oversights introduced by commit 198b3716dba6, so backpatch down to v14.  
  
Author: Ran Benita <ran@unusedvar.com>  
Discussion: https://postgr.es/m/a3383211-4539-459b-9d51-95c736ef08e0@app.fastmail.com  
Backpatch-through: 14  

commit   : 399f7ce3daa692a5bebbba50bf9cb773f6469613    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 10:20:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Sep 2025 10:20:33 +0900    

SLRU bank locks are referred as "bank locks" or "SLRU bank locks" in the  
code comments.  The comments updated in this commit use the latter term.  
  
Oversight in 53c2a97a9266, that has replaced the single ControlLock by  
the bank control locks.  
  
Author: Julien Rouhaud <julien.rouhaud@free.fr>  
Discussion: https://postgr.es/m/aLUT2UO8RjJOzZNq@jrouhaud  
Backpatch-through: 17  

commit   : 6200622301310b1e47a2d5b7e25d098f0a38c551    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Sep 2025 16:03:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Sep 2025 16:03:08 -0400    

commit   : 83fa88945929df3931413503bbf3c9ae98457f1a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Sep 2025 13:07:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Sep 2025 13:07:49 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 0a0b90588b76075d4deb646a8c75cb6e9fd062f2  

commit   : e19c67d0fb16c6dcd75ac4813706a383623b7091    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Aug 2025 18:21:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Aug 2025 18:21:05 -0400    

Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/53125.1756591456@sss.pgh.pa.us  
  
Backpatch-through: 18  

commit   : a252ed7fba6667f913d74e72dd0af9c9b2c9b3d1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Aug 2025 17:52:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Aug 2025 17:52:06 -0400    

Discussion: https://postgr.es/m/aLMo7lJKg8bWUs3y@momjian.us  
  
Backpatch-through: 18  

commit   : e1dacaac3b9f95b10c24726dee4a15d817ca04e4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 29 Aug 2025 15:54:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 29 Aug 2025 15:54:47 -0400    

Backpatch-through: 18 only  

commit   : 8980c724b5591fe758384685d215497215b20357    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 Aug 2025 19:28:46 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 Aug 2025 19:28:46 +0200    

Compression in pg_dump is abstracted using an API with multiple  
implementations which can be selected at runtime by the user.  
The API and its implementations have evolved over time, notable  
commits include bf9aa490db, e9960732a9, 84adc8e20, and 0da243fed.  
The errorhandling defined by the API was however problematic and  
the implementations had a few bugs and/or were not following the  
API specification.  This commit modifies the API to ensure that  
callers can perform errorhandling efficiently and fixes all the  
implementations such that they all implement the API in the same  
way.  A full list of the changes can be seen below.  
  
 * write_func:  
   - Make write_func throw an error on all error conditions.  All  
     callers of write_func were already checking for success and  
     calling pg_fatal on all errors, so we might as well make the  
     API support that case directly with simpler errorhandling as  
     a result.  
  
 * open_func:  
   - zstd: move stream initialization from the open function to  
     the read and write functions as they can have fatal errors.  
     Also ensure to dup the file descriptor like none and gzip.  
   - lz4: Ensure to dup the file descriptor like none and gzip.  
  
 * close_func:  
   - zstd: Ensure to close the file descriptor even if closing  
     down the compressor fails, and clean up state allocation on  
     fclose failures.  Make sure to capture errors set by fclose.  
   - lz4: Ensure to close the file descriptor even if closing  
     down the compressor fails, and instead of calling pg_fatal  
     log the failures using pg_log_error. Make sure to capture  
     errors set by fclose.  
   - none: Make sure to catch errors set by fclose.  
  
 * read_func / gets_func:  
   - Make read_func unconditionally return the number of read  
     bytes instead of making it optional per implementation.  
   - lz4: Make sure to call throw an error and not return -1  
   - gzip: gzread returning zero cannot be assumed to indicate  
     EOF as it is documented to return zero for some types of  
     errors.  
   - lz4, zstd: Convert the _read_internal helper functions to  
     not call pg_fatal on errors to be able to handle gets_func  
     returning NULL on error.  
  
 * getc_func:  
   - zstd: Use an unsigned char rather than an int to read char  
     into.  
  
 * LZ4Stream_init:  
   - Make sure to not switch to inited state until we know that  
     initialization succeeded and reset errno just in case.  
  
On top of these changes there are minor comment cleanups and  
improvements as well as an attempt to consistently reset errno  
in codepaths where it is inspected.  
  
This work was initiated by a report of API misuse, which turned  
into a larger body of work.  As this is an internal API these  
changes can be backpatched into all affected branches.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Evgeniy Gorbanev <gorbanyoves@basealt.ru>  
Discussion: https://postgr.es/m/517794.1750082166@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 0c97c72f3f4a6b7daa7873c7ef8e432661f4e070    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Aug 2025 12:05:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Aug 2025 12:05:58 -0400    

This missed files created when running the oauth tests.  

commit   : 4aea5589106bdaa949e45e8ae6a7e49204a460f6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 30 Aug 2025 00:51:39 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 30 Aug 2025 00:51:39 +1200    

It's possible that if the only live partition is concurrently dropped  
and try_table_open() fails, that the bms_del_member() will pfree the  
live_parts Bitmapset.  Since the bms_del_member() call does not assign  
the result back to the live_parts local variable, the while loop could  
segfault as that variable would still reference the pfree'd Bitmapset.  
  
Backpatch to 15. 52f3de874 was backpatched to 14, but there's no  
bms_del_member() there due to live_parts not yet existing in RelOptInfo in  
that version.  Technically there's no bug in version 15 as  
bms_del_member() didn't pfree when the set became empty prior to  
00b41463c (from v16).  Applied to v15 anyway to keep the code similar and  
to avoid the bad coding pattern.  
  
Author: Bernd Reiß <bd_reiss@gmx.at>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/6b88f27a-c45c-4826-8e37-d61a04d90182@gmx.at  
Backpatch-through: 15  

commit   : 3eea4dc2c7cfbd9ef56e34ac25b43ab90fe62c51    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 Aug 2025 14:43:47 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 Aug 2025 14:43:47 +0200    

I think the error message for a different condition was inadvertently  
copied.  
  
This problem seems to have been introduced by commit a4d75c86bf15.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CACJufxEZ48toGH0Em_6vdsT57Y3L8pLF=DZCQ_gCii6=C3MeXw@mail.gmail.com  

commit   : d1073c3b4cc83bb9d25b0c0203adc74ca58ef866    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Aug 2025 10:18:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Aug 2025 10:18:10 +0200    

Document the small migration hazard introduced in commit fb1a18810f0,  
as suggested there.  
  
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/653f3b84-fc87-45a7-9a0c-bfb4fcab3e7d%40eisentraut.org  

commit   : 58ea074f1433abdd5de792e47ae84c1e56c263f9    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Fri, 29 Aug 2025 13:16:47 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Fri, 29 Aug 2025 13:16:47 +0900    

For a child relation, we should not assume that its parent's  
unique-ified relation (or unique-ified path in v18) always exists.  In  
cases where all RHS columns that need to be unique-ified are equated  
to constants, the unique-ified relation/path for the parent table is  
not built, as there are no columns left to unique-ify.  Failing to  
account for this can result in a SIGSEGV crash during planning.  
  
This patch checks whether the parent's unique-ified relation or path  
exists and skips unique-ification of the child relation if it does  
not.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49MOdLW2c+qbLHHBt8VBu=4ONpM91D19=AWeW93eFUF6A@mail.gmail.com  
Backpatch-through: 18  

commit   : 514688656b8bca623bd2d1a28a549f8a56751612    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 28 Aug 2025 17:06:44 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 28 Aug 2025 17:06:44 -0700    

Previously, we used LW_EXCLUSIVE in several places despite only reading  
WalSummarizerCtl fields. This patch reduces the lock level to LW_SHARED  
where we are only reading the shared fields.  
  
Backpatch to 17, where wal summarization was introduced.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoDdKhf_9oriEYxY-JCdF+Oe_muhca3pcdkMEdBMzyHyKw@mail.gmail.com  
Backpatch-through: 17  

commit   : 3aee6283709f6a7d826b3fb5773cc4496788a5df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Aug 2025 13:49:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Aug 2025 13:49:20 -0400    

One mechanism we have for implementing semi-joins is to de-duplicate  
the output of the RHS and then treat the join as a plain inner join.  
Initial construction of the join's SpecialJoinInfo identifies the  
RHS columns that need to be de-duplicated, but later we may find that  
some of those don't need to be handled explicitly, either because  
they're known to be constant or because they are redundant with some  
previous column.  
  
Up to now, while sort-based de-duplication handled such cases well,  
hash-based de-duplication didn't: we'd still hash on all of the  
originally-identified columns.  This is probably not a very big  
deal performance-wise, but in the wake of commit a3179ab69 it can  
cause planner errors.  That happens when join elimination causes  
recalculation of variables' attr_needed bitmapsets, and we decide  
that a variable mentioned in a semijoin clause doesn't need to be  
propagated up to the join level anymore.  
  
There are a number of ways we could slice the blame for this, but the  
only fix that doesn't result in pessimizing plans for loosely-related  
cases is to be more careful about not hashing columns we don't  
actually need to de-duplicate.  We can install that consideration  
into create_unique_paths in master, or the predecessor code in  
create_unique_path in v18, without much refactoring.  
  
(As follow-up work, it might be a good idea to look at more-invasive  
refactoring, in hopes of preventing other bugs in this area.  But  
with v18 release so close, there's not time for that now, nor would  
we be likely to want to put such refactoring into v18 anyway.)  
  
Reported-by: Sergey Soloviev <sergey.soloviev@tantorlabs.ru>  
Diagnosed-by: Richard Guo <guofenglinux@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/1fd1a421-4609-4d46-a1af-ab74d5de504a@tantorlabs.ru  
Backpatch-through: 18  

commit   : 663eecb5b6166b1a41276819affa38ba27951b5e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 21:17:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 21:17:58 +0200    

An improvement pass over the new stats import functionality.  

commit   : ce161b194e84c941c468261fb72f10ed3a99b958    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 27 Aug 2025 19:12:11 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 27 Aug 2025 19:12:11 -0400    

During an investigation into rather odd aio related errors on macos, observed  
by Alexander and Konstantin, we started to wonder if bitfield access is  
related to the error. At the moment it looks like it is related, we cannot  
reproduce the failures when replacing the bitfields. In addition, the problem  
can only be reproduced with some compiler [versions] and not everyone has been  
able to reproduce the issue.  
  
The observed problem is that, very rarely, PgAioHandle->{state,target} are in  
an inconsistent state, after having been checked to be in a valid state not  
long before, triggering an assertion failure. Unfortunately, this could be  
caused by wrong compiler code generation or somehow of missing memory barriers  
- we don't really know. In theory there should not be any concurrent write  
access to the handle in the state the bug is triggered, as the handle was idle  
and is just being initialized.  
  
Separately from the bug, we observed that at least gcc and clang generate  
rather terrible code for the bitfield access. Even if it's not clear if the  
observed assertion failure is actually caused by the bitfield somehow, the bad  
code generation alone is sufficient reason to stop using bitfields.  
  
Therefore, replace the enum bitfields with uint8s and instead cast in each  
switch statement.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reported-by: Konstantin Knizhnik <knizhnik@garret.ru>  
Discussion: https://postgr.es/m/1500090.1745443021@sss.pgh.pa.us  
Backpatch-through: 18  

commit   : baf45ba0533f872acec16ece7f45f4db13fcbd3f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 16:47:23 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 16:47:23 +0200    

Commit d31bbfb6590 lost some test coverage, because the situation  
being tested, a concurrent DROP, cannot happen anymore.  Put the test  
coverage back with a bit of a trick, by deleting directly from the  
catalog table.  
  
Co-authored-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/bf72b82c-124d-4efa-a484-bb928e9494e4@eisentraut.org  

commit   : 118601a7e8c088306fe952ff298afd687483b35e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 16:46:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 16:46:51 +0200    

Commit d31bbfb6590 removed the comment at objectNamesToOids() that  
there is no locking, because that commit added locking.  But to fix  
all the problems, we'd still need a stronger lock.  So put the comment  
back with more a detailed explanation.  
  
Co-authored-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/bf72b82c-124d-4efa-a484-bb928e9494e4@eisentraut.org  

commit   : d07e2d4237cb2972d396a5b1f338457db9a21a2c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 15:46:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Aug 2025 15:46:39 +0200    

This patch fixes a bug in how 'load_external_function' handles  
'$libdir/ prefixes in module paths.  
  
Previously, 'load_external_function' would unconditionally strip  
'$libdir/' from the beginning of the 'filename' string.  This caused  
an issue when the path was nested, such as "$libdir/nested/my_lib".  
Stripping the prefix resulted in a path of "nested/my_lib", which  
would fail to be found by the expand_dynamic_library_name function  
because the original '$libdir' macro was removed.  
  
To fix this, the code now checks for the presence of an additional  
directory separator ('/' or '\') after the '$libdir/' prefix.  The  
prefix is only stripped if the remaining string does not contain a  
separator.  This ensures that simple filenames like '"$libdir/my_lib"'  
are correctly handled, while nested paths are left intact for  
'expand_dynamic_library_name' to process correctly.  
  
Reported-by: Dilip Kumar <dilipbalaut@gmail.com>  
Co-authored-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Co-authored-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAFiTN-uKNzAro4tVwtJhF1UqcygfJ%2BR%2BRL%3Db-_ZMYE3LdHoGhA%40mail.gmail.com  

commit   : 08aa8f035cea9465813667a219f9895fade80dc6    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 26 Aug 2025 22:55:14 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 26 Aug 2025 22:55:14 -0700    

When checking for expression indexes that may be affected by a Unicode  
update during upgrade, check for a few more functions. Specifically,  
check for documented regexp functions, as well as the new CASEFOLD()  
function.  
  
Also, fully-qualify references to pg_catalog.text and  
pg_catalog.regtype.  
  
Discussion: https://postgr.es/m/399b656a3abb0c9283538a040f72199c0601525c.camel@j-davis.com  
Backpatch-through: 18  

commit   : bf37808ef61cbd017179b3d92ad606bf31b14b80    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 26 Aug 2025 14:28:05 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 26 Aug 2025 14:28:05 -0700    

Followup to 4e1e41733 and 52ecd05ae. oauth-utils.c uses  
pthread_sigmask(), requiring -pthread on Debian bullseye at minimum.  
  
Reported-by: Christoph Berg <myon@debian.org>  
Tested-by: Christoph Berg <myon@debian.org>  
Discussion: https://postgr.es/m/aK4PZgC0wuwQ5xSK%40msg.df7cb.de  
Backpatch-through: 18  

commit   : 952b5a4a9574d7489c51d509edf1cbfb06e96985    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 Aug 2025 22:48:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 Aug 2025 22:48:00 +0200    

Mostly adding some quoting.  

commit   : 6b34e2157539c6fbdc62a78d7bb49409f222672b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 26 Aug 2025 14:49:01 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 26 Aug 2025 14:49:01 -0500    

When vacuumdb's --missing-stats-only option is used, the catalog  
query for retrieving the list of relations to process must read  
pg_statistic and pg_statistic_ext_data.  However, those catalogs  
can only be read by superusers by default, so --missing-stats-only  
is effectively superuser-only.  This is unfortunate, but since the  
option is primarily intended for use by administrators after  
running pg_upgrade, let's just live with it for v18.  This commit  
adds a note about the aforementioned privilege requirements to the  
documentation for --missing-stats-only.  
  
We first tried to improve matters by modifying the query to read  
the pg_stats and pg_stats_ext system views instead.  While that is  
indeed more lenient from a privilege standpoint, it is also  
borderline incomprehensible.  pg_stats shows rows for which the  
user has the SELECT privilege on the corresponding column, and  
pg_stats_ext shows rows for tables the user owns.  Meanwhile,  
ANALYZE requires either MAINTAIN on the table or, for non-shared  
relations, ownership of the database.  But even if the privilege  
discrepancies were tolerable, the performance impact was not.  
Ultimately, the modified query was substantially more expensive, so  
we abandoned the idea.  
  
For v19, perhaps we could introduce a simple, inexpensive way to  
discover which relations are missing statistics, such as a system  
function or view with similar privilege requirements to ANALYZE.  
Unfortunately, it is far too late for anything like that in v18.  
  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwHh43suEfss1wvBsk7vqiou%3DUY0zcy8HGyE5hBp%2BHZ7SQ%40mail.gmail.com  
Backpatch-through: 18  

commit   : 3a7a3eaaf9fe6d4669815de719300df124b869e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 12:08:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 12:08:57 -0400    

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,  
which cannot select matching index entries but can reject  
non-matching tuples, for example a tsquery such as '!term'.  There are  
poorly-documented assumptions that such scan keys do not appear as the  
first scan key.  ginNewScanKey did nothing to ensure that, however,  
with the result that certain GIN index searches could go into an  
infinite loop while apparently-equivalent queries with the clauses in  
a different order were fine.  
  
Fix by teaching ginNewScanKey to place all excludeOnly scan keys  
after all not-excludeOnly ones.  So far as we know at present,  
it might be sufficient to avoid the case where the very first  
scan key is excludeOnly; but I'm not very convinced that there  
aren't other dependencies on the ordering.  
  
Bug: #19031  
Reported-by: Tim Wood <washwithcare@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org  
Backpatch-through: 13  

commit   : 44c2e5b76c985e9f1d5c88bdaa5460ddf73fa37d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 11:38:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Aug 2025 11:38:41 -0400    

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be  
inadequate to prevent a long uninterruptible loop, because  
we now know a case where looping occurs within scanGetItem.  
While the next patch will fix the bug that caused that, it  
seems foolish to assume that no similar patterns are possible.  
Let's do the CFI within scanGetItem's retry loop, instead.  
This demonstrably allows canceling out of the loop exhibited  
in bug #19031.  
  
Bug: #19031  
Reported-by: Tim Wood <washwithcare@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org  
Backpatch-through: 13  

commit   : 8951941fb8a4d7f239760d7a4cd8fcaeecde13e2    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 24 Aug 2025 03:34:22 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 24 Aug 2025 03:34:22 +0300    

The Self-Join Elimination SJE feature messes up keeping and removing RowMark's  
in remove_self_joins_one_group().  That didn't lead to user-level error,  
because the planned RowMark is only used to reference a rtable entry in later  
execution stages.  An RTE entry for keeping and removing relations is  
identical and refers to the same relation OID.  
  
To reduce confusion and prevent future issues, this commit cleans up the code  
and fixes the incorrect behaviour.  Furthermore, it includes sanity checks in  
setrefs.c on existing non-null RTE and RelOptInfo entries for each RowMark.  
  
Discussion: https://postgr.es/m/18c6bd6c-6d2a-419a-b0da-dfedef34b585%40gmail.com  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com>  
Backpatch-through: 18  

commit   : 8202b0e83d0928ce9344c31f90cdd4a1e963b568    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 26 Aug 2025 12:51:32 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 26 Aug 2025 12:51:32 +0300    

Rename inner and outer to rrel and krel, respectively, to highlight their  
connection to r and k indexes.  For the same reason, rename imark and omark  
to rmark and kmark.  
  
Discussion: https://postgr.es/m/18c6bd6c-6d2a-419a-b0da-dfedef34b585%40gmail.com  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com>  
Backpatch-through: 18  

commit   : 9d115b9e11f553991badc0148bfa52580d1b3c8f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 25 Aug 2025 22:59:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 25 Aug 2025 22:59:00 +0200    

Use "row" instead of "tuple" for user-facing information for  
logical replication conflicts.  

commit   : e76738e597907d7cece10f67b0769b6d0b8d461e    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 25 Aug 2025 09:31:24 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 25 Aug 2025 09:31:24 -0700    

libpq-oauth uses floor() but did not link against libm. Since libpq  
itself uses -lm, nothing in the buildfarm has had problems with  
libpq-oauth yet, and it seems difficult to hit a failure in practice.  
  
But commit 1443b6c0e attempted to add an executable based on  
libpq-oauth, which ran into link-time failures with Clang due to this  
omission. It seems prudent to fix this for both the module and the  
executable simultaneously so that no one trips over it in the future.  
  
This is a Makefile-only change. The Meson side already pulls in libm,  
through the os_deps dependency.  
  
Discussion: https://postgr.es/m/CAOYmi%2Bn6ORcmV10k%2BdAs%2Bp0b9QJ4bfpk0WuHQaF5ODXxM8Y36A%40mail.gmail.com  
Backpatch-through: 18  

commit   : c6dca7c3dd65d9f7b436db502338ac233a1c51fd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Aug 2025 16:46:20 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Aug 2025 16:46:20 -0700    

v17 introduced the MAINTAIN ON TABLES privilege.  That changed the  
applicable "baseacls" reaching buildACLCommands().  That yielded  
spurious TestUpgradeXversion diffs.  Change to use a TYPES privilege.  
Types have the same one privilege in all supported versions, so they  
avoid the problem.  Per buildfarm.  Back-patch to v13, like that commit.  
  
Discussion: https://postgr.es/m/20250823144505.88.nmisch@google.com  
Backpatch-through: 13  

commit   : 7652142f4c1446d533797b24a5bac6cd2b3a4a4e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 22 Aug 2025 20:50:28 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 22 Aug 2025 20:50:28 -0700    

Commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6 missed DO_DEFAULT_ACL,  
leading to assertion failures, potential dump order instability, and  
spurious schema diffs.  Back-patch to v13, like that commit.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Discussion: https://postgr.es/m/d32aaa8d-df7c-4f94-bcb3-4c85f02bea21@gmail.com  
Backpatch-through: 13  

commit   : 2ce6abdf50857d3564cc1ef701e7f1095fbfb438    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 22 Aug 2025 18:44:39 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 22 Aug 2025 18:44:39 +0300    

This reverts commit bc22dc0e0ddc2dcb6043a732415019cc6b6bf683.  
It appears that conditional variables are not suitable for use inside  
critical sections.  If WaitLatch()/WaitEventSetWaitBlock() face postmaster  
death, they exit, releasing all locks instead of PANIC.  In certain  
situations, this leads to data corruption.  
  
Reported-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/B3C69B86-7F82-4111-B97F-0005497BB745%40yandex-team.ru  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Aleksander Alekseev <aleksander@tigerdata.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Yura Sokolov <y.sokolov@postgrespro.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 18  

commit   : 8c0c8686374495815c2c970e8652228c5aac4495    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 22 Aug 2025 11:11:28 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 22 Aug 2025 11:11:28 -0500    

Statistics aren't created for virtual generated columns, so  
"vacuumdb --missing-stats-only" always chooses to analyze tables  
that have them.  To fix, modify vacuumdb's query for retrieving  
relations that are missing statistics to exclude those columns.  
  
Oversight in commit edba754f05.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/20250820104226.8ba51e43164cd590b863ce41%40sraoss.co.jp  
Backpatch-through: 18  

commit   : 5a26a3e4eeb279074421380ee332cc40690b2bac    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 14:47:19 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 14:47:19 +0300    

Jelte pointed out that this was unnecessary, but I failed to remove it  
before pushing f6f0542266. Oops.  
  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/CAGECzQT%3DxNV-V%2BvFC7YQwYQMj0wGN61b3p%3DJ1_rL6M0vbjTtrA@mail.gmail.com  
Backpatch-through: 18  

commit   : e7ff96853ea78fd5fc00987fac276a35c265b1bf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 14:39:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 14:39:29 +0300    

The protocol documentation states that the maximum length of a cancel  
key is 256 bytes. This starts checking for that limit in libpq.  
Otherwise third party backend implementations will probably start  
using more bytes anyway. We also start requiring that a protocol 3.0  
connection does not send a longer cancel key, to make sure that  
servers don't start breaking old 3.0-only clients by accident. Finally  
this also restricts the minimum key length to 4 bytes (both in the  
protocol spec and in the libpq implementation).  
  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Jacob Champion <jchampion@postgresql.org>  
Discussion: https://www.postgresql.org/message-id/df892f9f-5923-4046-9d6f-8c48d8980b50@iki.fi  
Backpatch-through: 18  

commit   : 8aa287c9061b719c53e331ea7af019cb4d4509c5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 14:39:25 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 14:39:25 +0300    

In most cases, if an out-of-memory situation happens, we attach the  
error message to the connection and report it at the next  
PQgetResult() call. However, there are a few cases, while processing  
messages that are not associated with any particular query, where we  
handled failed allocations differently and not very nicely:  
  
- If we ran out of memory while processing an async notification,  
  getNotify() either returned EOF, which stopped processing any  
  further data until more data was received from the server, or  
  silently dropped the notification. Returning EOF is problematic  
  because if more data never arrives, e.g. because the connection was  
  used just to wait for the notification, or because the next  
  ReadyForQuery was already received and buffered, it would get stuck  
  forever. Silently dropping a notification is not nice either.  
  
- (New in v18) If we ran out of memory while receiving BackendKeyData  
  message, getBackendKeyData() returned EOF, which has the same issues  
  as in getNotify().  
  
- If we ran out of memory while saving a received a ParameterStatus  
  message, we just skipped it. A later call to PQparameterStatus()  
  would return NULL, even though the server did send the status.  
  
Change all those cases to terminate the connnection instead. Our  
options for reporting those errors are limited, but it seems better to  
terminate than try to soldier on. Applications should handle  
connection loss gracefully, whereas silently missing a notification,  
parameter status, or cancellation key could cause much weirder  
problems.  
  
This also changes the error message on OOM while expanding the input  
buffer. It used to report "cannot allocate memory for input buffer",  
followed by "lost synchronization with server: got message type ...".  
The "lost synchronization" message seems unnecessary, so remove that  
and report only "cannot allocate memory for input buffer". (The  
comment speculated that the out of memory could indeed be caused by  
loss of sync, but that seems highly unlikely.)  
  
This evolved from a more narrow patch by Jelte Fennema-Nio, which was  
reviewed by Jacob Champion.  
  
Somewhat arbitrarily, backpatch to v18 but no further. These are  
long-standing issues, but we haven't received any complaints from the  
field. We can backpatch more later, if needed.  
  
Co-authored-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Jacob Champion <jchampion@postgresql.org>  
Discussion: https://www.postgresql.org/message-id/df892f9f-5923-4046-9d6f-8c48d8980b50@iki.fi  
Backpatch-through: 18  

commit   : 27f20441c5e7193bd0d16b0d34be58ed6a310f38    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 13:07:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2025 13:07:46 +0300    

Commit 1585ff7387 changed GetTransactionSnapshot() to throw an error  
if it's called during logical decoding, instead of returning the  
historic snapshot. I made that change for extra protection, because a  
historic snapshot can only be used to access catalog tables while  
GetTransactionSnapshot() is usually called when you're executing  
arbitrary queries. You might get very subtle visibility problems if  
you tried to use the historic snapshot for arbitrary queries.  
  
There's no built-in code in PostgreSQL that calls  
GetTransactionSnapshot() during logical decoding, but it turns out  
that the pglogical extension does just that, to evaluate row filter  
expressions. You would get weird results if the row filter runs  
arbitrary queries, but it is sane as long as you don't access any  
non-catalog tables. Even though there are no checks to enforce that in  
pglogical, a typical row filter expression does not access any tables  
and works fine. Accessing tables marked with the user_catalog_table =  
true option is also OK.  
  
To fix pglogical with row filters, and any other extensions that might  
do similar things, revert GetTransactionSnapshot() to return a  
historic snapshot during logical decoding.  
  
To try to still catch the unsafe usage of historic snapshots, add  
checks in heap_beginscan() and index_beginscan() to complain if you  
try to use a historic snapshot to scan a non-catalog table. We're very  
close to the version 18 release however, so add those new checks only  
in master.  
  
Backpatch-through: 18  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://www.postgresql.org/message-id/20250809222338.cc.nmisch@google.com  

commit   : fc387141ea64ca1bd7038f98b8105bfdb35adf18    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 22 Aug 2025 05:19:50 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 22 Aug 2025 05:19:50 +0000    

Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/OSCPR01MB149662EC5467B4135398E3731F532A@OSCPR01MB14966.jpnprd01.prod.outlook.com  

commit   : 86831952ad6054097dca8aabb1ae4bb74f791f44    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Aug 2025 09:06:34 +0900    

Temporary relations may share the same RelFileNumber with a permanent  
relation, or other temporary relations associated with other sessions.  
  
Being able to uniquely identify a temporary relation would require  
RelidByRelfilenumber() to know about the proc number of the temporary  
relation it wants to identify, something it is not designed for since  
its introduction in f01d1ae3a104.  
  
There are currently three callers of RelidByRelfilenumber():  
- autoprewarm.  
- Logical decoding, reorder buffer.  
- pg_filenode_relation(), that attempts to find a relation OID based on  
a tablespace OID and a RelFileNumber.  
  
This makes the situation problematic particularly for the first two  
cases, leading to the possibility of random ERRORs due to  
inconsistencies that temporary relations can create in the cache  
maintained by RelidByRelfilenumber().  The third case should be less of  
an issue, as I suspect that there are few direct callers of  
pg_filenode_relation().  
  
The window where the ERRORs are happen is very narrow, requiring an OID  
wraparound to create a lookup conflict in RelidByRelfilenumber() with a  
temporary table reusing the same OID as another relation already cached.  
The problem is easier to reach in workloads with a high OID consumption  
rate, especially with a higher number of temporary relations created.  
  
We could get pg_filenode_relation() and RelidByRelfilenumber() to work  
with temporary relations if provided the means to identify them with an  
optional proc number given in input, but the years have also shown that  
we do not have a use case for it, yet.  Note that this could not be  
backpatched if pg_filenode_relation() needs changes.  It is simpler to  
ignore temporary relations.  
  
Reported-by: Shenhao Wang <wangsh.fnst@fujitsu.com>  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-By: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Reviewed-By: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-By: Takamichi Osumi <osumi.takamichi@fujitsu.com>  
Reviewed-By: Michael Paquier <michael@paquier.xyz>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Reported-By: Shenhao Wang <wangsh.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/bbaaf9f9-ebb2-645f-54bb-34d6efc7ac42@fujitsu.com  
Backpatch-through: 13  

commit   : b942360f82a0fe0c450ba54f01cac0c594cf08a4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 21 Aug 2025 19:40:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 21 Aug 2025 19:40:12 +0200    

The result of pgaio_io_get_id() was being assigned to a mix of int and  
uint32 variables.  This fixes it to use int consistently, which seems  
the most correct.  Also change the queue empty special value in  
method_worker.c to -1 from UINT32_MAX.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/70c784b3-f60b-4652-b8a6-75e5f051243e%40eisentraut.org  

commit   : 859444465f7404a652cc28b1a4d74563d8707e56    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Aug 2025 13:25:50 +0900    

The description of this GUC provides a list of the situations where  
full-page writes are generated.  However, it is not completely exact,  
mentioning only the cases where full_page_writes=on or base backups.  It  
is possible to generate full-page writes in more situations than these  
two, making the description confusing as it implies that no other cases  
exist.  
  
The description is slightly reworded to take into account that other  
cases are possible, without mentioning them directly to minimize the  
maintenance burden should FPWs be generated in more contexts in the  
future.  
  
Author: Jingtang Zhang <mrdrivingduck@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CAPsk3_CtAYa_fy4p6=x7qtoutrdKvg1kGk46D5fsE=sMt2546g@mail.gmail.com  
Backpatch-through: 13  

commit   : 906b68217a1e756a49acd0864773680d1eb8a10d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Aug 2025 16:09:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Aug 2025 16:09:18 -0400    

If we error out during execution of a SQL-language function, we will  
often leave behind non-null pointers in its SQLFunctionCache's cplan  
and eslist fields.  This is problematic if the SQLFunctionCache is  
re-used, because those pointers will point at resources that were  
released during error cleanup.  This problem escaped detection so far  
because ordinarily we won't re-use an FmgrInfo+SQLFunctionCache struct  
after a query error.  However, in the rather improbable case that  
someone implements an opclass support function in SQL language, there  
will be long-lived FmgrInfos for it in the relcache, and then the  
problem is reachable after the function throws an error.  
  
To fix, add a flag to SQLFunctionCache that tracks whether execution  
escapes out of fmgr_sql, and clear out the relevant fields during  
init_sql_fcache if so.  (This is going to need more thought if we ever  
try to share FMgrInfos across threads; but it's very far from being  
the only problem such a project will encounter, since many functions  
regard fn_extra as being query-local state.)  
  
This broke at commit 0313c5dc6; before that we did not try to re-use  
SQLFunctionCache state across calls.  Hence, back-patch to v18.  
  
Bug: #19026  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19026-90aed5e71d0c8af3@postgresql.org  
Backpatch-through: 18  

commit   : ea1c6b0b0aec43b1cd513945f618793ce3343347    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Aug 2025 15:00:08 +0900    

Some replication slot manipulations (logical decoding via SQL,  
advancing) were failing an assertion when releasing a slot in  
single-user mode, because active_pid was not set in a ReplicationSlot  
when its slot is acquired.  
  
ReplicationSlotAcquire() has some logic to be able to work with the  
single-user mode.  This commit sets ReplicationSlot->active_pid to  
MyProcPid, to let the slot-related logic fall-through, considering the  
single process as the one holding the slot.  
  
Some TAP tests are added for various replication slot functions with the  
single-user mode, while on it, for slot creation, drop, advancing, copy  
and logical decoding with multiple slot types (temporary, physical vs  
logical).  These tests are skipped on Windows, as direct calls of  
postgres --single would fail on permission failures.  There is no  
platform-specific behavior that needs to be checked, so living with this  
restriction should be fine.  The CI is OK with that, now let's see what  
the buildfarm tells.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: Mutaamba Maasha <maasha@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966ED588A0328DAEBE8CB25F5FA2@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : 0beb7e9338ad58c46189f19258e9969bb333d48b    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:39 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 19 Aug 2025 12:11:39 -0700    

This commit adds CHECK_FOR_INTERRUPTS to loops iterating over shared  
buffers in several pg_buffercache functions, allowing them to be  
interrupted during long-running operations.  
  
Backpatch to all supported versions. Add CHECK_FOR_INTERRUPTS to the  
loop in pg_buffercache_pages() in all supported branches, and to  
pg_buffercache_summary() and pg_buffercache_usage_counts() in version  
16 and newer.  
  
Author: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>  
Discussion: https://postgr.es/m/CAHg+QDcejeLx7WunFT3DX6XKh1KshvGKa8F5au8xVhqVvvQPRw@mail.gmail.com  
Backpatch-through: 13  

commit   : a5d4c04150d4c5a946702734917222af7364204b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 05:18:24 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Aug 2025 05:18:24 +0000    

The DROP SUBSCRIPTION command performs several operations: it stops the  
subscription workers, removes subscription-related entries from system  
catalogs, and deletes the replication slot on the publisher server.  
Previously, this command acquired an AccessExclusiveLock on  
pg_subscription before initiating these steps.  
  
However, while holding this lock, the command attempts to connect to the  
publisher to remove the replication slot. In cases where the connection is  
made to a newly created database on the same server as subscriber, the  
cache-building process during connection tries to acquire an  
AccessShareLock on pg_subscription, resulting in a self-deadlock.  
  
To resolve this issue, we reduce the lock level on pg_subscription during  
DROP SUBSCRIPTION from AccessExclusiveLock to RowExclusiveLock. Earlier,  
the higher lock level was used to prevent the launcher from starting a new  
worker during the drop operation, as a restarted worker could become  
orphaned.  
  
Now, instead of relying on a strict lock, we acquire an AccessShareLock on  
the specific subscription being dropped and re-validate its existence  
after acquiring the lock. If the subscription is no longer valid, the  
worker exits gracefully. This approach avoids the deadlock while still  
ensuring that orphan workers are not created.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/18988-7312c868be2d467f@postgresql.org  

commit   : 4483dd9c66faecefac47ab2a45ed2a682004c520    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Aug 2025 14:54:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Aug 2025 14:54:59 -0400    

Apparently the only Test::More function this script uses is  
BAIL_OUT, so this omission just results in the wrong error  
output appearing in the cases where it bails out.  
  
Seems to have been an oversight in commit 9f899562d which  
split Kerberos.pm out of another script.  
  
Author: Maxim Orlov <orlovmg@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACG=ezY1Dp-S94b78nN0ZuaBGGcMUB6_nF-VyYUwPt1ArFqmGA@mail.gmail.com  
Backpatch-through: 17  

commit   : da3b61368177a5a9ced5412592932b8e8429b302    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 17 Aug 2025 19:40:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 17 Aug 2025 19:40:01 +0900    

Commit c5b7ba4e6 changed things so that the ri_RootResultRelInfo field  
of this struct is set for both partitions and inheritance children and  
used for tuple routing and transition capture (before that commit, it  
was only set for partitions to route tuples into), but failed to update  
these comments.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK14NF5CcdCmTZpxrvpvBiT0y4EqKikW1r_wAu1CEHeOmUA%40mail.gmail.com  
Backpatch-through: 14  

commit   : 83773eaf657898a0c747deac7da37516124347c1    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 15 Aug 2025 11:58:56 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 15 Aug 2025 11:58:56 -0700    

When extracting a timestamp from a UUIDv7, a conversion from  
milliseconds to microseconds was using the incorrect constant  
NS_PER_US instead of US_PER_MS. Although both constants have the same  
value, this fix improves code clarity by using the semantically  
correct constant.  
  
Backpatch to v18, where UUIDv7 was introduced.  
  
Author: Erik Nordström <erik@tigerdata.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CACAa4V+i07eaP6h4MHNydZeX47kkLPwAg0sqe67R=M5tLdxNuQ@mail.gmail.com  
Backpatch-through: 18  

commit   : ad3990ffea7e1fb756e2f9c72eac8c5fe9fc2d86    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 15 Aug 2025 10:29:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 15 Aug 2025 10:29:16 +0200    

Recent changes to src/tools/ci/README triggered warnings like  
  
    src/tools/ci/README:88: leftover conflict marker  
  
Raise conflict-marker-size in .gitattributes to avoid these.  

commit   : 1571c7ca5dc9d8eb9e86ac9b0ff64a60613de0b1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 18:06:13 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 18:06:13 +1200    

This seems to have been broken back in be0a66666.  
  
Reported-by: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966E11EEFB37D7857FCEDB7F535A@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : e4ba326295c51a6c3c84fab6ce4942f9fceefbea    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 17:24:21 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 15 Aug 2025 17:24:21 +1200    

This seems to have been broken for a few years by cc5ef90ed.  
  
Author: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/OSCPR01MB14966E11EEFB37D7857FCEDB7F535A@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 17  

commit   : 97d6ee5713251c1a79defb4f825b5ebc280659ef    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:48:04 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:48:04 -0400    

Handle 'ci-os-only' occurrences in the .cirrus.star file instead of  
.cirrus.tasks.yml file. Now, 'ci-os-only' occurrences are controlled  
from one central place instead of dealing with them in each task.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/20240413021221.hg53rvqlvldqh57i%40awork3.anarazel.de  
Backpatch: 15-, where CI support was added  

commit   : faa78bc1c1d4efaeef7dc6703e69aef4c6e017c3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:33:44 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Aug 2025 11:33:44 -0400    

We do not want to trigger some tasks by default, to avoid using too many  
compute credits. These tasks have to be manually triggered to be run. But  
e.g. for cfbot we do have sufficient resources, so we always want to start  
those tasks.  
  
With this commit, an individual repository can be configured to trigger  
them automatically using an environment variable defined under  
"Repository Settings", for example:  
  
REPO_CI_AUTOMATIC_TRIGGER_TASKS="mingw netbsd openbsd"  
  
This will enable cfbot to turn them on by default when running tests for the  
Commitfest app.  
  
Backpatch this back to PG 15, even though PG 15 does not have any manually  
triggered task. Keeping the CI infrastructure the same seems advantageous.  
  
Author: Andres Freund <andres@anarazel.de>  
Co-authored-by: Thomas Munro <thomas.munro@gmail.com>  
Co-authored-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/20240413021221.hg53rvqlvldqh57i%40awork3.anarazel.de  
Backpatch-through: 16  

commit   : 891dbd17cef076f6626c050de833d026922650e2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Aug 2025 16:21:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Aug 2025 16:21:58 +0900    

This function uses an argument named "maxsize" that is only used in  
assertions, being set once outside the assertion area.  Recent gcc  
versions with -Wunused-but-set-parameter complain about a warning when  
building without assertions enabled, because of that.  
  
In order to fix this issue, PG_USED_FOR_ASSERTS_ONLY is added to the  
function argument of SerializeClientConnectionInfo(), which is the first  
time we are doing so in the tree.  The CI is fine with the change, but  
let's see what the buildfarm has to say on the matter.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Jacob Champion <jchampion@postgresql.org>  
Discussion: https://postgr.es/m/pevajesswhxafjkivoq3yvwxga77tbncghlf3gq5fvchsvfuda@6uivg25sb3nx  
Backpatch-through: 16  

commit   : 2de22b1ead3cb6b506e0b4a808d1b28786338080    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Aug 2025 15:52:48 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Aug 2025 15:52:48 -0400    

Currently the pdb file for libpq and some other libraries are named the same  
for the static and shared libraries. That has been the case for a long time,  
but recently started failing, after an image update started using a newer  
ninja version. The issue is not itself caused by ninja, but just made visible,  
as the newer version optimizes the build order and builds the shared libpq  
earlier than the static library. Previously both static and shared libraries  
were built at the same time, which prevented msvc from detecting the issue.  
  
When using /DEBUG:FASTLINK pdb files cannot be updated, triggering the error.  
  
We were using /DEBUG:FASTLINK due to running out of memory in the past, but  
that was when using container based CI images, rather than full VMs.  
  
This isn't really the correct fix (that'd be to deconflict the pdb file  
names), but we'd like to get CI to become green again, and a proper fix (in  
meson) will presumably take longer.  
  
Suggested-by: Andres Freund <andres@anarazel.de>  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAN55FZ1RuBhJmPWs3Oi%3D9UoezDfrtO-VaU67db5%2B0_uy19uF%2BA%40mail.gmail.com  
Backpatch-through: 16  

commit   : 787cd2b7d5cd211627b07c7b383c0abbe67c90ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Aug 2025 11:59:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Aug 2025 11:59:47 -0400    

It turns out that on some platforms (at least current macOS, NetBSD,  
OpenBSD) semget(2) will return EINVAL if there is a pre-existing  
semaphore set with the same key and too few semaphores.  Our code  
expects EEXIST in that case and treats EINVAL as a hard failure,  
resulting in failure during initdb or postmaster start.  
  
POSIX does document EINVAL for too-few-semaphores-in-set, and is  
silent on its priority relative to EEXIST, so this behavior arguably  
conforms to spec.  Nonetheless it's quite problematic because EINVAL  
is also documented to mean that nsems is greater than the system's  
limit on the number of semaphores per set (SEMMSL).  If that is  
where the problem lies, retrying would just become an infinite loop.  
  
To resolve this contradiction, retry after EINVAL, but also install a  
loop limit that will make us give up regardless of the specific errno  
after trying 1000 different keys.  (1000 is a pretty arbitrary number,  
but it seems like it should be sufficient.)  I like this better than  
the previous infinite-looping behavior, since it will also keep us out  
of trouble if (say) we get EACCES due to a system-level permissions  
problem rather than anything to do with a specific semaphore set.  
  
This problem has only been observed in the field in PG 17, which uses  
a higher nsems value than other branches (cf. 38da05346, 810a8b1c8).  
That makes it possible to get the failure if a new v17 postmaster  
has a key collision with an existing postmaster of another branch.  
In principle though, we might see such a collision against a semaphore  
set created by some other application, in which case all branches are  
vulnerable on these platforms.  Hence, backpatch.  
  
Reported-by: Gavin Panella <gavinpanella@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CALL7chmzY3eXHA7zHnODUVGZLSvK3wYCSP0RmcDFHJY8f28Q3g@mail.gmail.com  
Backpatch-through: 13  

commit   : 2102667b3c1ba6dbc65fcbe687cccb578772a5e9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Aug 2025 13:11:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Aug 2025 13:11:48 +0900    

The tests fixed in this commit were changing the sampling setting of a  
foreign server, but then were analyzing a local table instead of a  
foreign table, meaning that the test was not running for its original  
purpose.  
  
This commit changes the ANALYZE commands to analyze the foreign table,  
and changes the foreign table definition to point to a valid remote  
table.  Attempting to analyze the foreign table "analyze_ftable" would  
have failed before this commit, because "analyze_rtable1" is not defined  
on the remote side.  
  
Issue introduced by 8ad51b5f446b.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CADkLM=cpUiJ3QF7aUthTvaVMmgQcm7QqZBRMDLhBRTR+gJX-Og@mail.gmail.com  
Backpatch-through: 16  

commit   : ab844ce378fe81d15cf000f821af663af3846ab6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:02:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:02:23 -0400    

commit   : 67a2fbb8f9e9f75df08208e75da412c43a814688    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 Aug 2025 09:00:00 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 Aug 2025 09:00:00 -0500    

A malicious server could inject psql meta-commands into plain-text  
dump output (i.e., scripts created with pg_dump --format=plain,  
pg_dumpall, or pg_restore --file) that are run at restore time on  
the machine running psql.  To fix, introduce a new "restricted"  
mode in psql that blocks all meta-commands (except for \unrestrict  
to exit the mode), and teach pg_dump, pg_dumpall, and pg_restore to  
use this mode in plain-text dumps.  
  
While at it, encourage users to only restore dumps generated from  
trusted servers or to inspect it beforehand, since restoring causes  
the destination to execute arbitrary code of the source superusers'  
choice.  However, the client running the dump and restore needn't  
trust the source or destination superusers.  
  
Reported-by: Martin Rakhmanov  
Reported-by: Matthieu Denais <litezeraw@gmail.com>  
Reported-by: RyotaK <ryotak.mail@gmail.com>  
Suggested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Security: CVE-2025-8714  
Backpatch-through: 13  

commit   : 13a67ce6034ed674a4e797c6f1545831189be02e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 11 Aug 2025 06:18:59 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 11 Aug 2025 06:18:59 -0700    

Maliciously-crafted object names could achieve SQL injection during  
restore.  CVE-2012-0868 fixed this class of problem at the time, but  
later work reintroduced three cases.  Commit  
bc8cd50fefd369b217f80078585c486505aafb62 (back-patched to v11+ in  
2023-05 releases) introduced the pg_dump case.  Commit  
6cbdbd9e8d8f2986fde44f2431ed8d0c8fce7f5d (v12+) introduced the two  
pg_dumpall cases.  Move sanitize_line(), unchanged, to dumputils.c so  
pg_dumpall has access to it in all supported versions.  Back-patch to  
v13 (all supported versions).  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Backpatch-through: 13  
Security: CVE-2025-8715  

commit   : 605fdb989b8c4213907560ae90f2188425bf77ed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:38:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:38:06 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 380d4ff4d883aef5cb4e5ced45a339771197e6ef  

commit   : 64f77c6a65cb6a0731e59acbfab1dd1663b1cdd3    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:07:36 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:07:36 +0100    

Commit e2d4ef8de86 (the fix for CVE-2017-7484) added security checks  
to the selectivity estimation functions to prevent them from running  
user-supplied operators on data obtained from pg_statistic if the user  
lacks privileges to select from the underlying table. In cases  
involving inheritance/partitioning, those checks were originally  
performed against the child RTE (which for plain inheritance might  
actually refer to the parent table). Commit 553d2ec2710 then extended  
that to also check the parent RTE, allowing access if the user had  
permissions on either the parent or the child. It turns out, however,  
that doing any checks using the child RTE is incorrect, since  
securityQuals is set to NULL when creating an RTE for an inheritance  
child (whether it refers to the parent table or the child table), and  
therefore such checks do not correctly account for any RLS policies or  
security barrier views. Therefore, do the security checks using only  
the parent RTE. This is consistent with how RLS policies are applied,  
and the executor's ACL checks, both of which use only the parent  
table's permissions/policies. Similar checks are performed in the  
extended stats code, so update that in the same way, centralizing all  
the checks in a new function.  
  
In addition, note that these checks by themselves are insufficient to  
ensure that the user has access to the table's data because, in a  
query that goes via a view, they only check that the view owner has  
permissions on the underlying table, not that the current user has  
permissions on the view itself. In the selectivity estimation  
functions, there is no easy way to navigate from underlying tables to  
views, so add permissions checks for all views mentioned in the query  
to the planner startup code. If the user lacks permissions on a view,  
a permissions error will now be reported at planner-startup, and the  
selectivity estimation functions will not be run.  
  
Checking view permissions at planner-startup in this way is a little  
ugly, since the same checks will be repeated at executor-startup.  
Longer-term, it might be better to move all the permissions checks  
from the executor to the planner so that permissions errors can be  
reported sooner, instead of creating a plan that won't ever be run.  
However, such a change seems too far-reaching to be back-patched.  
  
Back-patch to all supported versions. In v13, there is the added  
complication that UPDATEs and DELETEs on inherited target tables are  
planned using inheritance_planner(), which plans each inheritance  
child table separately, so that the selectivity estimation functions  
do not know that they are dealing with a child table accessed via its  
parent. Handle that by checking access permissions on the top parent  
table at planner-startup, in the same way as we do for views. Any  
securityQuals on the top parent table are moved down to the child  
tables by inheritance_planner(), so they continue to be checked by the  
selectivity estimation functions.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 13  
Security: CVE-2025-8713  

commit   : 0d2734eac3457016e8fdc32da65b2f4b4a092829    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 10 Aug 2025 13:05:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 10 Aug 2025 13:05:13 -0700    

Commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6 recently added the  
assertion to confirm dump order remains independent of OID values.  The  
assertion remained reachable via DO_DEFAULT_ACL.  Given the release wrap  
tomorrow, make the assertion master-only.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/d32aaa8d-df7c-4f94-bcb3-4c85f02bea21@gmail.com  
Backpatch-through: 13-18  

commit   : 9110d81641696b95ea55f3a15dd0907ec0743529    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 9 Aug 2025 12:33:06 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 9 Aug 2025 12:33:06 +1200    

The internal queue of buffers could become corrupted in a rare edge case  
that failed to invalidate an entry, causing a stale buffer to be  
"forwarded" to StartReadBuffers().  This is a simple fix for the  
immediate problem.  
  
A small API change might be able to remove this and related fragility  
entirely, but that will have to wait a bit.  
  
Defect in commit ed0b87ca.  
  
Bug: 19006  
Backpatch-through: 18  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/19006-80fcaaf69000377e%40postgresql.org  

commit   : 762fed90bfee248ca090a96fe883e063ba035088    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 19:34:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 19:34:31 +0200    

before checking ->has_scram_keys.  MyProcPort is NULL in background  
workers.  So this could crash for example if a background worker  
accessed a suitable configured foreign table.  
  
Author: Alexander Pyhalov <a.pyhalov@postgrespro.ru>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/27b29a35-9b96-46a9-bc1a-914140869dac%40gmail.com  

commit   : 41aac1483a6ce61c0a721c590caaaaaf838eae47    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:56 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:56 -0700    

Tracking down the bugs that led to the addition of comb_multiplexer()  
and drain_timer_events() was difficult, because an inefficient flow is  
not visibly different from one that is working properly. To help  
maintainers notice when something has gone wrong, track the number of  
calls into the flow as part of debug mode, and print the total when the  
flow finishes.  
  
A new test makes sure the total count is less than 100. (We expect  
something on the order of 10.) This isn't foolproof, but it is able to  
catch several regressions in the logic of the prior two commits, and  
future work to add TLS support to the oauth_validator test server should  
strengthen it as well.  
  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAOYmi+nDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA@mail.gmail.com  

commit   : e507e08acf63ffa6777424f53cec24e6a1363571    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:52 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:52 -0700    

In a case similar to the previous commit, an expired timer can remain  
permanently readable if Curl does not remove the timeout itself. Since  
that removal isn't guaranteed to happen in real-world situations,  
implement drain_timer_events() to reset the timer before calling into  
drive_request().  
  
Moving to drain_timer_events() happens to fix a logic bug in the  
previous caller of timer_expired(), which treated an error condition as  
if the timer were expired instead of bailing out.  
  
The previous implementation of timer_expired() gave differing results  
for epoll and kqueue if the timer was reset. (For epoll, a reset timer  
was considered to be expired, and for kqueue it was not.) This didn't  
previously cause problems, since timer_expired() was only called while  
the timer was known to be set, but both implementations now use the  
kqueue logic.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAOYmi+nDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA@mail.gmail.com  

commit   : 16b0c48583a5043f46d75cde99d8a3ffbd9c7c98    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:46 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:46 -0700    

If Curl needs to switch the direction of a socket's registration (e.g.  
from CURL_POLL_IN to CURL_POLL_OUT), it expects the old registration to  
be discarded. For epoll, this happened via EPOLL_CTL_MOD, but for  
kqueue, the old registration would remain if it was not explicitly  
removed by Curl.  
  
Explicitly remove the opposite-direction event during registrations. (If  
that event doesn't exist, we'll just get an ENOENT, which will be  
ignored by the same code that handles CURL_POLL_REMOVE.) A few  
assertions are also added to strengthen the relationship between the  
number of events added, the number of events pulled off the queue, and  
the lengths of the kevent arrays.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAOYmi+nDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA@mail.gmail.com  

commit   : ff181d1f876f32da332238879c3834a3e7825a46    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:37 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 8 Aug 2025 08:44:37 -0700    

If a socket is added to the kqueue, becomes readable/writable, and  
subsequently becomes non-readable/writable again, the kqueue itself will  
remain readable until either the socket registration is removed, or the  
stale event is cleared via a call to kevent().  
  
In many simple cases, Curl itself will remove the socket registration  
quickly, but in real-world usage, this is not guaranteed to happen. The  
kqueue can then remain stuck in a permanently readable state until the  
request ends, which results in pointless wakeups for the client and  
wasted CPU time.  
  
Implement comb_multiplexer() to call kevent() and unstick any stale  
events that would cause unnecessary callbacks. This is called right  
after drive_request(), before we return control to the client to wait.  
  
Suggested-by: Thomas Munro <thomas.munro@gmail.com>  
Co-authored-by: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAOYmi+nDZxJHaWj9_jRSyf8uMToCADAmOfJEggsKW-kY7aUwHA@mail.gmail.com  

commit   : 4cd9d5fc158d31afd07485e8497b7f33d3f20c6c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 9 Aug 2025 01:40:17 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 9 Aug 2025 01:40:17 +1200    

Remove a comment about potential for AIO in StartReadBuffersImpl(),  
because that change happened.  

commit   : 992a18f5161cf36147eedaf7ac1d0af8a89646dc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 12:06:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 12:06:06 +0200    

The code used  
  
    return (Selectivity) 0.0;  
  
where  
  
    PG_RETURN_FLOAT8(0.0);  
  
would be correct.  
  
On 64-bit systems, these are pretty much equivalent, but on 32-bit  
systems, PG_RETURN_FLOAT8() correctly produces a pointer, but the old  
wrong code would return a null pointer, possibly leading to a crash  
elsewhere.  
  
We think this code is actually not reachable because bqarr_in won't  
accept an empty query, and there is no other function that will  
create query_int values.  But better be safe and not let such  
incorrect code lie around.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/8246d7ff-f4b7-4363-913e-827dadfeb145%40eisentraut.org  

commit   : bba6a6fafc8ae5d2e364b713568068941a929d5f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 17:35:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 17:35:00 +0900    

This function is called from ATExecAttachPartition/ATExecAddInherit,  
which prevent tables with row-level triggers with transition tables from  
becoming partitions or inheritance children, to check if there is such a  
trigger on the given table, but failed to check if a found trigger is  
row-level, causing the caller functions to needlessly prevent a table  
with only a statement-level trigger with transition tables from becoming  
a partition or inheritance child.  Repair.  
  
Oversight in commit 501ed02cf.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK167mXzwzzmJ_0YZ3EZrbwiCxtM1vogH_8drqsE6PtxRYw%40mail.gmail.com  
Backpatch-through: 13  

commit   : e3764229e6bdcc71b03642a2f9cd728cca361889    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 8 Aug 2025 14:36:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 8 Aug 2025 14:36:39 +0900    

Previously, pg_dump --filter could misinterpret invalid object types  
in the filter file as valid ones. For example, the invalid object type  
"table-data" (likely a typo for the valid "table_data") could be  
mistakenly recognized as "table", causing pg_dump to succeed  
when it should have failed.  
  
This happened because pg_dump identified keywords as sequences of  
ASCII alphabetic characters, treating non-alphabetic characters  
(like hyphens) as keyword boundaries. As a result, "table-data" was  
parsed as "table".  
  
To fix this, pg_dump --filter now treats keywords as strings of  
non-whitespace characters, ensuring invalid types like "table-data"  
are correctly rejected.  
  
Back-patch to v17, where the --filter option was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Srinath Reddy <srinath2133@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAHGQGwFzPKUwiV5C-NLBqz1oK1+z9K8cgrF+LcxFem-p3_Ftug@mail.gmail.com  
Backpatch-through: 17  

commit   : ce88170227136bc94363be60aca57f5656dd529e    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 10:50:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 10:50:01 +0900    

Commit 9e6104c66 disallowed transition tables on foreign tables, but  
failed to account for cases where a foreign table is a child table of a  
partitioned/inherited table on which transition tables exist, leading to  
incorrect transition tuples collected from such foreign tables for  
queries on the parent table triggering transition capture.  This  
occurred not only for inherited UPDATE/DELETE but for partitioned INSERT  
later supported by commit 3d956d956, which should have handled it at  
least for the INSERT case, but didn't.  
  
To fix, modify ExecAR*Triggers to throw an error if the given relation  
is a foreign table requesting transition capture.  Also, this commit  
fixes make_modifytable so that in case of an inherited UPDATE/DELETE  
triggering transition capture, FDWs choose normal operations to modify  
child foreign tables, not DirectModify; which is needed because they  
would otherwise skip the calls to ExecAR*Triggers at execution, causing  
unexpected behavior.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK14QJYikKzBDCe3jMbpGENnQ7popFmbEgm-XTNuk55oyHg%40mail.gmail.com  
Backpatch-through: 13  

commit   : ab74ce4dc909104b3008926fd5019b3a34020ce1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Aug 2025 09:07:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Aug 2025 09:07:49 +0900    

Dropping twice a pgstats entry should not happen, and the error report  
generated was missing the "generation" counter (tracking when an entry  
is reused) that has been added in 818119afccd3.  
  
Like d92573adcb02, backpatch down to v15 where this information is  
useful to have, to gather more information from instances where the  
problem shows up.  A report has shown that this error path has been  
reached on a standby based on 17.3, for a relation stats entry and an  
OID close to wraparound.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/CAN4RuQvYth942J2+FcLmJKgdpq6fE5eqyFvb_PuskxF2eL=Wzg@mail.gmail.com  
Backpatch-through: 15  

commit   : a9ffb35274fb17282dd2f0035172720ae4a87589    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 7 Aug 2025 15:31:36 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 7 Aug 2025 15:31:36 -0700    

libpq-oauth was missing from the installed_targets list, so  
  
    $ ninja clean && ninja install-quiet  
  
failed with the error message  
  
    ERROR: File 'src/interfaces/libpq-oauth/libpq-oauth.a' could not be found  
  
It seems a little odd to have to tell Meson what's missing, since it  
clearly knows how to build that file during regular installation. But  
the "quiet" variant we've created must use --no-rebuild, to avoid  
spawning concurrent ninja processes that would step on each other.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/hbpqdwxkfnqijaxzgdpvdtp57s7gwxa5d6sbxswovjrournlk6%404jnb2gzan4em  

commit   : 31c09ef4563612467b31149713896948e5532684    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Aug 2025 18:04:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Aug 2025 18:04:45 -0400    

Although the "Floating-Point Types" section says that "float" data  
type is taken to mean "double precision", this information was not  
reflected in the data type table that lists all data type aliases.  
  
Reported-by: alexander.kjall@hafslund.no  
Author: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/175456294638.800.12038559679827947313@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : f15c00e90930e58730a930f2a8ed1e2df34222a0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Aug 2025 13:29:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Aug 2025 13:29:08 +0200    

Small touch-up on commits 25505082f0e and 50fd428b2b9.  Fix the  
formatting of the example messages in the documentation and adjust the  
wording to match the code.  

commit   : 5cfbff48a4fdd1437ff06fcebdc2dade477ed4b8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 7 Aug 2025 14:29:02 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 7 Aug 2025 14:29:02 +0300    

Use Min(NBuffers, MAX_CHECKPOINT_REQUESTS) instead of NBuffers in  
CheckpointerShmemSize() to match the actual array size limit set in  
CheckpointerShmemInit().  This prevents wasting shared memory when  
NBuffers > MAX_CHECKPOINT_REQUESTS.  Also, fix the comment.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1439188.1754506714%40sss.pgh.pa.us  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : 2ae8280d16c980a9dd68894190fc08c39f6522da    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 7 Aug 2025 14:11:49 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 7 Aug 2025 14:11:49 +0300    

This reverts commit 1fe9e3822c4e574aa526b99af723e61e03f36d4f.  That commit  
was a documentation improvement, not a bug fix.  We don't normally backpatch  
such changes.  
  
Discussion: https://postgr.es/m/d8eacbeb8194c578a98317b86d7eb2ef0b6eb0e0.camel%40j-davis.com  

commit   : dd29262077e854199497a4aa42a776a2095eeec7    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:12:44 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:12:44 +0700    

Recent ICU versions have added U_SHOW_CPLUSPLUS_HEADER_API, and we need  
to set this to zero as well to hide the ICU C++ APIs from pg_locale.h  
  
Per discussion, we want cpluspluscheck to work cleanly in backbranches,  
so backpatch both this and its predecessor commit ed26c4e25a4 to all  
supported versions.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1115793.1754414782%40sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 1084e76f3ce54b238f765b7ae228fe4b1dc43bf9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Aug 2025 11:48:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Aug 2025 11:48:43 +0200    

Fix commit f295494d338 to use consistent four-space indentation for  
verbose messages.  

commit   : 67ffe1987d0acab35c2efaa8ffcbe092db333113    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 7 Aug 2025 11:49:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 7 Aug 2025 11:49:29 +0900    

Commit d85ce012f99f has added some new error handling code to  
date_trunc() of timestamp, timestamptz, and interval with infinite  
values.  
  
However, the new test cases added by that commit did not actually test  
all of the new code, missing coverage for the following cases:  
1) For timestamp without time zone:  
1-1) infinite value with valid unit  
1-2) infinite value with unsupported unit  
1-3) finite value with unsupported unit, for a code path older than  
d85ce012f99f.  
2) For timestamp with time zone, without a time zone specified for the  
truncation:  
2-1) infinite value with valid unit  
2-2) infinite value with unsupported unit  
2-3) finite value with unsupported unit, for a code path older than  
d85ce012f99f.  
3) For timestamp with time zone, with a time zone specified for the  
truncation:  
3-1) infinite value with valid unit.  
3-2) infinite value with unsupported unit.  
  
This commit also provides coverage for the bug fixed in 2242b26ce472,  
through cases 2-1) and 3-1), when using an infinite value with a valid  
unit, with[out] the optional time zone parameter used for the  
truncation.  
  
Author: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/2d320b6f-b4af-4fbc-9eec-5d0fa15d187b@eisentraut.org  
Discussion: https://postgr.es/m/4bf60a84-2862-4a53-acd5-8eddf134a60e@eisentraut.org  
Backpatch-through: 18  

commit   : 074db8604ad1fa7cd11bffbb4bb5cf9c69c6824b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 7 Aug 2025 11:02:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 7 Aug 2025 11:02:09 +0900    

The code used a PG_RETURN_TIMESTAMPTZ() where the return type is  
TimestampTz and not a Datum.  
  
On 64-bit systems, there is no effect since this just ends up casting  
64-bit integers back and forth.  On 32-bit systems, timestamptz is  
pass-by-reference.  PG_RETURN_TIMESTAMPTZ() allocates new memory and  
returns the address, meaning that the caller could interpret this as a  
timestamp value.  
  
The effect is using "date_trunc(..., 'infinity'::timestamptz) will  
return random values (instead of the correct return value 'infinity').  
  
Bug introduced in commit d85ce012f99f.  
  
Author: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2d320b6f-b4af-4fbc-9eec-5d0fa15d187b@eisentraut.org  
Discussion: https://postgr.es/m/4bf60a84-2862-4a53-acd5-8eddf134a60e@eisentraut.org  
Backpatch-through: 18  

commit   : ce13bb96fbcc3d3dd93b398fba2acf1e70a2080b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 Aug 2025 10:54:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 Aug 2025 10:54:48 +0200    

These were introduced (commit efdc7d74753) at the same time as we were  
moving to using the standard inttypes.h format macros (commit  
a0ed19e0a9e).  It doesn't seem useful to keep a new already-deprecated  
interface like this with only a few users, so remove the new symbols  
again and have the callers use PRIx64.  
  
(Also, INT64_HEX_FORMAT was kind of a misnomer, since hex formats all  
use unsigned types.)  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/0ac47b5d-e5ab-4cac-98a7-bdee0e2831e4%40eisentraut.org