PostgreSQL 20.0 (upcoming) commit log

commit   : 32e4508db27d1fa3dc07404ad69d43ed97870f15    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 20:16:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 20:16:34 +0900    

The data checksums launcher and workers were exposed in pg_stat_io  
with the same broad set of object/context combinations as general  
background workers. However, several of those entries can never  
accumulate I/O statistics for these processes, such as bulkwrite,  
relation init, temporary relation, and launcher vacuum entries.  
  
Teach pgstat_tracks_io_object() and pgstat_tracks_io_op() about the  
actual I/O performed by the data checksum processes. Keep the entries  
needed for catalog scans, including bulkread catalog scans, worker  
relation processing with a vacuum access strategy, and WAL writes and  
initialization, while excluding WAL reads and other object/context  
combinations that can never be used.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAHGQGwHz_-nt+YkHDMRZNBZrnoHro8cMOgSwuXEmSYT6vxgQ=w@mail.gmail.com  
Backpatch-through: 19  

commit   : 03480907e9ff5d9bb3296b56c9b49db3df756e0f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:47:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2026 09:47:33 +0530    

The previous text claimed that once the slot is disassociated with  
ALTER SUBSCRIPTION ... SET (slot_name = NONE), DROP SUBSCRIPTION "will no  
longer attempt any actions on a remote host".  That is inaccurate:  
DROP SUBSCRIPTION may still connect to the publisher to drop  
internally-created table synchronization slots when some table  
synchronization is left unfinished.  Reword to describe this, and note  
that if the publisher is unreachable those slots (and the main slot, if  
it still exists) must be dropped manually to avoid indefinitely reserving  
WAL.  
  
Reported-by: Jeff Davis <pgsql@j-davis.com>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAA4eK1+tyYSpPxMBy1974kjivuGeR7YY=yopwRGrK3+vCTysdg@mail.gmail.com  
Discussion: https://postgr.es/m/D908370F-2695-4231-851D-17179A6A6F2A@gmail.com  

commit   : 323530e00d279f267265ef32c7e6b40a04c94105    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:36 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:55:36 -0400    

Commit c7aeb775 rewrote the HOT-chain offset sanity checks in three  
places, but in heap_get_root_tuples it accidentally tested offnum -- the  
outer loop variable, which is already bounded by the loop condition --  
instead of nextoffnum, the offset actually passed to PageGetItemId.  The  
pre-c7aeb775 check tested nextoffnum.  
  
With the check ineffective, a stale t_ctid could make PageGetItemId read  
past the end of the line pointer array (which is data corruption that we  
expect to be able to catch here).  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Konstantin Knizhnik <knizhnik@garret.ru>  
Discussion: https://postgr.es/m/87c7d8a4-3a82-4334-bee6-e8c2ad3f3293@garret.ru  
Backpatch-through: 15  

commit   : 7af998936d304b676d4e8fb2f2780560cf8443ca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jul 2026 07:40:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jul 2026 07:40:10 +0900    

Since 457ac0331cd3, current_user() is the recommended way to get access  
to this information, and getpgusername() was marked as deprecated since,  
without being documented.  
  
Bump catalog version.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv44sPoKhHZqBvhqRdrFUEKwatGEmXBtqC360UuD5Lt7Nw@mail.gmail.com  

commit   : cea74f48d36bc1073da0adab755946ad94aa6902    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:08:43 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 Jul 2026 18:08:43 -0400    

Defensively make sure that all hash index atomic actions use a fake LSN  
with an unlogged relation.  
  
Oversight in commit e5836f7b, which added fake LSN support to the hash  
index AM, but missed log_split_page.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://postgr.es/m/CAH2-WzkC-opX8iS6X=a470DDC31er_x5rzPw=HjRxha9N8brZw@mail.gmail.com  
Backpatch-through: 19  

commit   : 8108765f04b8dae252825123834fe350cafe174f    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 12:20:39 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 12:20:39 -0700    

The logical decoding status is stored in checkpoint records and used  
to restore the status at server startup, but pg_controldata did not  
show it. This information is useful for diagnosing issues around the  
dynamic activation and deactivation of logical decoding.  
  
Oversight in 67c20979ce7.  
  
Reviewed-by: Guoqing Yang <yanggq1988@126.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/CAD21AoAnPAugUnDic+ESvrfXjXHk2bss9eHAD7zP0-Chy2UabA@mail.gmail.com  
Backpatch-through: 19  

commit   : c209931bd40c9d47fd32903d4055a998856395d9    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 12:13:13 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 12:13:13 -0700    

Crash recovery running with wal_level='minimal' can replay an  
XLOG_LOGICAL_DECODING_STATUS_CHANGE record that activates logical  
decoding, if the server previously ran with a higher wal_level and  
crashed after the last logical slot was dropped but before the  
checkpointer deactivated logical decoding. Replaying such a record is  
correct since it reflects the status at the time it was  
written. However, UpdateLogicalDecodingStatusEndOfRecovery() asserted  
that logical decoding is never active with wal_level='minimal',  
causing an assertion failure at the end of recovery. In production  
builds, logical decoding would remain active while running with  
wal_level='minimal'.  
  
Instead of special-casing wal_level='minimal', recompute the status at  
the end of recovery as usual: no logical slot can exist with  
wal_level='minimal' as RestoreSlotFromDisk() would have rejected it,  
so the recomputation always deactivates logical decoding in this case,  
also writing the corresponding status change record.  
  
Oversight in 67c20979ce7.  
  
Reviewed-by: Guoqing Yang <yanggq1988@126.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/CAD21AoAnPAugUnDic+ESvrfXjXHk2bss9eHAD7zP0-Chy2UabA@mail.gmail.com  
Backpatch-through: 19  

commit   : 7575215e0b9cf56340ea5fc202fa45f7613852c9    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 11:50:10 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 16 Jul 2026 11:50:10 -0700    

uuidv7(interval) shifts the current time by the given interval before  
encoding it into the 48-bit Unix-millisecond timestamp field of the  
generated UUID. Two cases were mishandled:  
  
An infinite interval ('infinity' or '-infinity') produced an infinite  
timestamp, which overflowed during the conversion to Unix-epoch  
microseconds and yielded a garbage UUID. Reject infinite intervals up  
front, before any timestamp arithmetic.  
  
A shift that moved the timestamp outside the range representable by  
the 48-bit field was silently accepted. Timestamps before the Unix  
epoch wrapped when cast to unsigned, and timestamps beyond  
approximately year 10889 overflowed the field; both produced UUIDs  
with bogus timestamps that break sort ordering. Reject any shifted  
timestamp outside the supported range.  
  
Also document that infinite intervals and out-of-range shifts are  
rejected.  
  
Although raising a new error changes behavior in a stable branch, this  
is back-patched to 18 (where uuidv7(interval) was introduced) because  
the previous behavior can silently corrupt data. Failing loudly is far  
safer than silently accepting the wraparound; otherwise users may not  
discover that their UUIDv7 values are no longer sortable until years  
later, when recovery is painful. It also matches how PostgreSQL  
already handles timestamp + interval overflow, which raises an  
error. The change only affects applications passing an interval large  
enough to push the result outside the representable range.  
  
Backpatch to 18, where uuidv7(interval) was introduced.  
  
Reported-by: Christophe Pettus <xof@thebuild.com>  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/799A70FA-6E5C-4118-99EB-2FBBE1CBAC54@thebuild.com  
Backpatch-through: 18  

commit   : 637aa273e6335c2e4d196f510d6787210403ed24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jul 2026 11:56:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jul 2026 11:56:01 -0400    

Process these just like the adjacent loop for expressions in regular  
index columns.  This logic was originally omitted because there was  
no intention of supporting index expressions in INCLUDING.  
There's still no near-term intention of that, but without this change  
the ChooseIndexExpressionName code added by 181b6185c spits up on  
expressions in INCLUDING: that expects to handle parse-transformed  
expressions, and it runs before we reach the place that is currently  
supposed to throw the "not supported" error.  We could fix this  
problem in other ways, but this way avoids contorting the logic,  
and it results in less code to be revised not more if we ever get  
around to supporting INCLUDING expressions.  
  
Reported-by: Maaz Syed Adeeb <maaz.adeeb@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Test-authored-by: Maaz Syed Adeeb <maaz.adeeb@gmail.com>  
Discussion: https://postgr.es/m/CAG+FJqOxYj=sVyHcys64h9DbvzP6EUPGHJ7oKj-PW=Qp5Ebk_g@mail.gmail.com  

commit   : 55f518684895bfe43e667acf59284b49707ee685    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 00:50:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 00:50:54 +0900    

Commit d4a657b0a4d added a call to has_sequence_privilege() while  
fetching sequence information from the publisher, so that  
publisher-side permission failures could be distinguished from missing  
sequences. It also assumed that has_sequence_privilege() could never  
return NULL, and asserted accordingly.  
  
However, that assumption was incorrect. If a sequence is dropped after  
the synchronization worker collects its metadata but while fetching the  
sequence information, has_sequence_privilege() can return NULL.  
This can trigger the assertion failure. This was also reported in  
a buildfarm failure on member culicidae.  
  
Fix this by treating a NULL result from has_sequence_privilege() as  
indicating that the sequence was dropped concurrently, and report it as  
a missing sequence instead of asserting that the result is never NULL.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/20260710045217.f0.noahmisch@microsoft.com  
Discussion: https://postgr.es/m/CALDaNm2fHGLeiQKj0r6OG7N9QeayxSmpLrWYJRyt4dL_m3VRWw@mail.gmail.com  
Backpatch-through: 19  

commit   : a704d0367a400fbc327469d96dc6cdba118dba8a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 00:49:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Jul 2026 00:49:26 +0900    

The regression test for postgres_fdw_get_connections(true) assumed that  
a terminated remote connection would still remain visible in the FDW  
connection cache long enough to be reported as closed with a nonzero  
remote_backend_pid.  
  
That assumption is not always valid. postgres_fdw_get_connections()  
reports only entries that are still present in ConnectionHash, while  
pgfdw_inval_callback() may immediately discard an idle cached connection  
(xact_depth == 0) when a relevant invalidation arrives. In CI, that can  
happen between terminating the remote backend and querying  
postgres_fdw_get_connections(true), causing the function to return no  
rows.  
  
Adjust the idle-connection test to accept either outcome: if the cache  
entry is still present, verify that it reports the expected server name,  
closed status, and nonzero remote backend PID; otherwise treat zero rows  
as a legitimate result.  
  
To preserve coverage of the terminated-backend reporting path, add a  
separate check inside an explicit transaction. In that case, concurrent  
invalidation may mark the connection invalid but cannot discard it  
before transaction end, so postgres_fdw_get_connections(true) should  
still report the terminated connection as in-use, closed, and associated  
with a nonzero remote backend PID.  
  
Backpatch to v18, where the affected postgres_fdw_get_connections(true)  
test was introduced.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA+Tgmoax3cHXHsm9OidN4F-xiu16y8q2W8T5dTNFic1Zoo2cOw@mail.gmail.com  
Backpatch-through: 18  

commit   : 0de346f464b1efd2bfa74fb22c1d6ffe2f733b63    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 16 Jul 2026 16:05:36 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 16 Jul 2026 16:05:36 +0200    

Commit 67846550dc6d removed the xreflabels for initdb options, which  
turned the sentence "The second field contains the page checksum if  
data checksums are enabled" into "The second field contains the page  
checksum if -k are enabled", as well "Only has effect if data checksums  
are enabled" into "Only has effect if -k are enabled".  
  
Fix by setting an explicit link text, and while there also change the  
link to point to the data checksum page which has more information  
than just the initdb option.  
  
The original report was for one instance, further inspection turned  
up quite a few more cases.  Also redirect the link in the amcheck  
docs which albeit was reading right, but will be more helpful if  
linking to the main page on data checksums.  Backpatch to v18 where  
the xreflabels were removed.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: y.saburov@gmail.com  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/178350739237.73862.4549076173872335741@wrigleys.postgresql.org  
Backpatch-through: 18  

commit   : f4f77f557bb1a173f82be42770a28758732f4cc0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 12:38:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 12:38:37 +0200    

This reverts commit b6d3ccf2f5f1a179e25e277bae3f432cc084ce58.  
  
macOS still ships with Tcl 8.5.  

commit   : 4854b2373c738a3e2fe5a46c2667d908f7c7e13a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    

Support for older versions is removed.  Since we no longer support  
RHEL 7, we don't need to support these old versions anymore.  This  
allows a fair amount of code cleanup, including some code blocks that  
specifically catered to old versions that probably received very  
little actual testing and use.  
  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/flat/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com  

commit   : b6d3ccf2f5f1a179e25e277bae3f432cc084ce58    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    

Support for Tcl 8.5 and 8.4 is removed.  Since we no longer support  
RHEL 7, we don't need to support these old versions anymore.  This  
allows some small amount of code cleanup.  
  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/flat/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com  

commit   : da9451830455a402fd6e29403a6512ebb2b41d97    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    

Commit aa7c8685234 added a workaround for _MSC_VER less than 1933,  
which is Visual Studio 2022 version 17.3.  Since we dropped support  
for Visual Studio before 2022, and the versions up to 17.3 are long  
EOL, we can drop this extra code.  
  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/flat/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com  

commit   : 6319d6372c8f28cfb30bd2b7b0893f28e44491e6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Jul 2026 11:47:41 +0200    

The use of _Generic from commit "Replace __builtin_types_compatible_p  
with _Generic" causes compiler errors from VS 2019.  Apparently, that  
compiler is just broken for that (even though it appears to support  
_Generic in general, for example in commit 59c2f03d1ec).  
  
Per discussion, just drop support for VS 2019 and require at least VS  
2022.  This just updates the documentation about that.  In passing,  
some information about VS 2026 is added.  
  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/flat/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com  

commit   : 3cf5264557bee2ba848e5276beecc10571d468a6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:38:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:38:34 +0900    

Previously, libpqrcv_create_slot() checked only that  
CREATE_REPLICATION_SLOT returned PGRES_TUPLES_OK before reading  
values from the first row. If the server unexpectedly returned an  
invalid result, such as zero rows, PQgetvalue() could return NULL,  
leading to a crash while parsing the LSN.  
  
Other replication commands, such as IDENTIFY_SYSTEM, already validate  
the response shape before accessing result values, but  
CREATE_REPLICATION_SLOT did not.  
  
Fix this by verifying that CREATE_REPLICATION_SLOT response contains  
exactly one row with four fields, and report a protocol violation otherwise.  
  
Backpatch to all supported versions.  
  
Bug: #19547  
Reported-by: Yuelin Wang <1217816127@qq.com>  
Author: Kenny Chen <kennychen851228@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/19547-f7986f668f71e788@postgresql.org  
Discussion: https://postgr.es/m/CAPXstDtW2iqe+DJAOTQTX+rRziJp2UhZSo1+HRj1COAtbu+nKw@mail.gmail.com  
Backpatch-through: 14  

commit   : 3ef575e4f190a26e50e46f2f8584a53b524660d0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:37:28 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:37:28 +0900    

REPACK requires the MAINTAIN privilege, but it was omitted from the  
lists of commands covered by that privilege in ddl.sgml and the  
description of the predefined pg_maintain role in user-manag.sgml.  
This was an oversight in commit ac58465e061, which introduced  
REPACK.  
  
Add REPACK to both documentation lists, and update the corresponding  
comment in aclchk.c.  
  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAOzEurRJOVokiB2J8nrF569nX-ZMb0oRSB0C=yZQ17mZxd4_BQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 89e78de0436c3ba1710431df8c3e8dd6415f7134    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:35:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Jul 2026 13:35:36 +0900    

The documentation for log_parameter_max_length said it affects messages  
generated by log_duration. However, log_duration alone does not log bind  
parameter values, so this is misleading.  
  
This commit updates the documentation to reference log_min_duration_statement,  
which can log bind parameters, to better reflect actual behavior.  
  
Backpatch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Surya Poondla <suryapoondla4@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGnCVMVz8-LU9F8Sh57bkQX3jMZzx7age7M0LFEz5=Fog@mail.gmail.com  
Backpatch-through: 14  

commit   : 5174d157a0381876cb1c6c5903c1844669d5bbc2    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    

The WAL summarizer only tracks registered buffers, so unregistered VM  
clears are ommitted from incremental backups, corrupting the restored  
visibility map. Test those cases are now fixed.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/oqcsevg35xjan2327x5kdfth6q4fgeqboxfo3v3imeyih2uiny%406sez5dzxl6nt  
Backpatch-through: 17  

commit   : ed62d26cacac96ca5c6b4e6fcc5308b11a8371c8    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    

Heap WAL records that clear bits on the visibility map (like inserts and  
deletes) did not register the visibility map blocks they modified.  
Because the WAL summarizer only records registered blocks, an  
incremental backup taken over such operations would omit the changed VM  
pages. On restore, the VM would retain stale all-visible/all-frozen  
bits, which can cause wrong results from index-only scans and incorrect  
relfrozenxid advancement due to vacuum page skipping.  
  
Not registering the VM buffer also meant we never emitted FPIs of VM  
pages when clearing bits. A torn VM page won't raise an error because  
the VM is read with ZERO_ON_ERROR; with checksums on, it would be  
detected and zeroed, but with checksums off, it is accepted as-is and  
can lead to data corruption.  
  
Fix this by registering the VM buffer in the WAL record when clearing VM  
bits. The VM buffer must now be locked throughout the critical section  
that modifies the VM and heap pages and emits the WAL record. This can  
slow down operations that clear the VM, since the VM lock is held longer  
and VM FPIs may be emitted, but it is required for correctness.  
  
Note that this fix does not repair existing incremental backups.  
  
Bumps XLOG_PAGE_MAGIC.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/flat/CAAKRu_bn%2Be7F4yPFBgFbnP%2BsyJRKyNK092bjD2LKvZW7O4Svag>  
Backpatch-through: 17  

commit   : 2340fb8f02b28d2fe7f0023d84c3055a38cd5b9e    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    

This brings it in line with visibilitymap_set(). An upcoming commit will  
start reading visibility map buffers with XLogReadBuffer*() functions,  
so we no longer require a relation object to pin the visibility map,  
allowing us to remove this fake relcache business altogether.  
  
While we're at it, remove a spurious const qualifier from the  
RelFileLocator parameter to visibilitymap_set().  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/flat/CAAKRu_bn%2Be7F4yPFBgFbnP%2BsyJRKyNK092bjD2LKvZW7O4Svag%40mail.gmail.com  

commit   : 10911fde088aef9c3be511955e9be632964f7a4a    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 17:24:49 -0400    

When registering a buffer with the WAL machinery, the caller assigns it a  
block reference ID, and replay must read each block back by that same ID.  
Today these IDs are bare integers assigned by convention (0, 1, 2, ...),  
which is easy to follow when a record registers a single block, or when the  
blocks are handled during replay in their registration order.  
  
An upcoming bug fix registers up to two visibility map blocks in addition  
to the heap block(s) when clearing the VM, and these are not handled during  
replay in a straightforward 1:1, in-registration-order fashion. Relying on  
bare integers for the block IDs in that case is error-prone.  
  
Introduce macros naming the block reference IDs for the heap record types  
that the upcoming commit extends to register visibility map blocks, so the  
registration and replay sites refer to the same block by a meaningful name.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/66mqpfyti3qhfttcsv6r2lbvqqd32rrmpn6i47ovrsnvguts46%40gou54xc>  
Backpatch through: 17  

commit   : a2fd8d65a0b75aeb81cd52204f358544d1888b02    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 15:49:59 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Wed, 15 Jul 2026 15:49:59 -0400    

When bulk-extending a relation, we add the newly-added blocks that we  
won't immediately use to the free space map and then call  
FreeSpaceMapVacuumRange() to propagate that free space up the FSM tree,  
so other backends can find and reuse it.  
  
However, the end block argument to FreeSpaceMapVacuumRange() is  
exclusive, and we passed the number of the last added block (since  
00d1e02be24). If that block was the first one covered by a new FSM page,  
its free space wasn't propagated up the tree and was therefore invisible  
to FSM searches until the next FSM vacuum.  
  
Fix by passing the block number one past the last added block, so the  
full range is vacuumed.  
  
Author: Jingtang Zhang <mrdrivingduck@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/flat/CAPsk3_Bx_vdybN%3D-DZu8HLStf%2BXnuFUBkLwxouONSMkWuO9oug%40mail.gmail.com  
Backpatch-through: 16  

commit   : 77b4d35e0f530c666514326f86d68d1268e3ec7b    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 15 Jul 2026 21:40:09 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 15 Jul 2026 21:40:09 +0200    

Commit 6f164e6d17616 accidentally mistyped --client as --clients in  
the error message.  Backpatch down to v15 where the it was introduced.  
  
Author: Semih Doğan <semih702do@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CALOtZ7tuWisV=v0cUY_q6PLHJ-fOiQ7ZN476JwmM0PyV0t5i7Q@mail.gmail.com  
Backpatch-through: 15  

commit   : cc3358087822654d68d7bfb8e80fd797a4b9d1b9    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 15 Jul 2026 12:34:20 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 15 Jul 2026 12:34:20 -0700    

A wrong calculation introduced by 9c8de15969 could cause trailing  
characters from the prefix to be passed to like_selectivity() rather  
than just the "rest".  
  
Discussion: https://postgr.es/m/c7334a7a44243d2e4ec5e83747589908b3787491.camel@j-davis.com  
Backpatch-through: 19  

commit   : ee654419d5fe7a37b230b865018dc8c1f6b9fc08    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jul 2026 13:04:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jul 2026 13:04:32 -0400    

Code elsewhere in the system assumes that fork numbers and chunk sizes  
are within bounds, so the code that reads those quantities from disk  
should validate that they are. Without these additional checks, a  
corrupted file can cause us to index off the end of fork number or chunk  
entry arrays, potentially resulting in a crash.  
  
Reported-by: oxsignal <awo@kakao.com> (chunk sizes)  
Reported-by: Robert Haas <rhaas@postgresql.org> (fork numbers)  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: http://postgr.es/m/CA+TgmoYP8RKoBGosS7C6Fdr-GNCfyz_W1zmK=Tx1Fe0ZvzGh0g@mail.gmail.com  
Backpatch-through: 17  

commit   : 11ed011ae22a620b01a43634b5eea2f9af5c709c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Jul 2026 21:22:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Jul 2026 21:22:38 +0900    

pg_clear_attribute_stats() checks its required arguments manually  
because the function is not strict. Previously, when schemaname or  
relname was passed as NULL, the error incorrectly reported the  
argument name as "relation" in both cases:  
  
    ERROR:  argument "relation" must not be null  
  
This was misleading, especially for schemaname, and inconsistent with  
the function's SQL-visible argument names.  
  
The cause is that cleararginfo[] in attribute_stats.c used  
"relation" for both the schema-name and relation-name arguments.  
  
This commit fixes the issue by using "schemaname" and "relname" instead,  
matching the function's declared argument names so that the error reports  
the correct argument name.  
  
Backpatch to v18, where pg_clear_attribute_stats() was introduced.  
  
Author: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/4bf66c5e-8dd7-4ef3-8691-db67ecff6f16@tantorlabs.com  
Backpatch-through: 18  

commit   : f38afa4abb04e85530c94b88daf11c089375daca    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 15 Jul 2026 15:40:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 15 Jul 2026 15:40:36 +0530    

'ALTER SUBSCRIPTION ... REFRESH SEQUENCES' can race with an already  
running sequence synchronization worker. If a second refresh request  
resets the synchronization state while the worker has already fetched  
sequence values from the publisher but has not yet applied them to the  
subscriber, the worker can overwrite the subscriber with stale values  
and mark the synchronization as complete.  
  
Avoid this race by rejecting 'ALTER SUBSCRIPTION ... REFRESH SEQUENCES'  
when a sequence synchronization worker is already running for the  
subscription. The command reports an error asking the user to rerun it  
after the current synchronization completes.  
  
Also add a wait for the re-added 'regress_s4' sequence to finish  
synchronizing in 036_sequences.pl, so the subsequent test does not race  
against its sequencesync worker.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Shveta Malik <shveta.malik@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 19, where it was introduced  
Discussion: https://postgr.es/m/20260710045217.f0.noahmisch@microsoft.com  

commit   : 01f78a84bf5aca4c00fe1168381830aca6f1b873    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 10:58:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 10:58:13 +0200    

The result from pg_preadv() or pg_pwritev(), which is of type ssize_t,  
is assigned to PgAioHandle.result, which is of type int.  This should  
be ok because the maximum result is limited by PG_IOV_MAX times  
BLCKSZ.  Add an assertion and a code comment to explain and check  
this.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 1f8c504e3086cf70a1538038b63b045de5df6a9b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 10:58:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 10:58:13 +0200    

and analogously for pg_pwrite() and FileWrite()  
  
Be sure to store the return value in a variable of type ssize_t, not  
int.  
  
Some callers of FileWrite() did not have a separate error message for  
a short write.  This is okay in practice because FileWriteV() sets  
ENOSPC for all non-error returns, so you'll get a reasonable error  
message either way.  But callers handled this inconsistently, and this  
behavior isn't really prominently documented and commit 871fe4917e1  
seems to frown upon it, so it seems better to make all callers handle  
this consistently by adding the separate error message.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : ca326e903df4b2efcc7b9090abc4d1a9c27c3088    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 09:43:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 09:43:03 +0200    

and analogously for pg_pread() and FileRead()  
  
Be sure to store the return value in a variable of type ssize_t, not  
int.  
  
Also make the error messages for short reads consistent.  They should  
always be like "read %zd of %zu".  Appearance of other placeholders  
indicates the types are probably wrong (although in some cases some  
casts are added to make macros have the right type and keep the  
strings consistent, and it some cases it's left as "%zu of %zu", which  
is close enough).  
  
In several cases, the input length is derived from struct stat  
st_size, which has type off_t, which is neither size_t nor ssize_t.  
To keep the type handling clearer, this introduces intermediate  
variables in these cases.  
  
In SendTimeLineHistory() in walsender.c, we need to adjust the logic a  
bit to over underflow wrap if we end up reading more from the file  
than expected.  This is believed to be a theoretical problem only.  
Alternatively, we could treat this as an error.  Note that the  
previous code would have processed the extra data but only up to a  
full block, which seems wrong in any case.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 7d45a6dc19743d999f5c83c95ad144a0f2eb6745    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 07:59:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2026 07:59:42 +0200    

The return type is ssize_t, not int, but some callers didn't handle  
this properly.  
  
The BIO callbacks are constrained by the OpenSSL API, so they take int  
for the length and return int.  This is safe, since the return value  
can't be greater than the input length.  To make it more clear that  
this is intentional, cast the result of the  
secure_read()/secure_write() call to int explicitly.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 572c3b2ddf8c90303d57bf33add4dcbf1b30b866    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:34:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:34:19 +0900    

Contrary to the from_serialized_data callback used by the pgstats reads  
at startup, the to_serialized_data callback used for the pgstats writes  
matched with pgstat_write_statsfile(), by not returning a boolean  
status, expecting a ferror() failure to deal with the discard of the  
stats file should an error happen while writing the stats.  This was  
slightly confusing designed this way.  
  
Things are changed in this commit with:  
- to_serialized_data now returns a boolean status on a write failure.  
pgstat_write_statsfile() detects that and switches to failure mode  
instead of continuing to process the entries to write, speeding up the  
shutdown.  
- pgstat_write_statsfile() now uses STATS_DISCARD if a failure happens,  
to let the registered callbacks directly know that something is wrong,  
and that things need to be cleaned up.  This gives a better error path  
detection for custom stats kinds.  For example, they do not have to rely  
solely on the expectation of an ferror() for an auxiliary file.  
  
This new set of behaviors matches with what is already done in  
pgstat_read_statsfile() for the finish() callback (DISCARD on failure,  
READ on success) and the from_serialized_data with a status returned.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0sMgOvuhpb2P=KSJOjgjC6AfUu+GYcu9mHar-y_Xtd=Pg@mail.gmail.com  
Backpatch-through: 19  

commit   : 8c551aab156d45f0626a64c43fcdeba1a40ead0d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 10:03:35 +0900    

equalPolicy() is used in the relation cache to check if two policy  
definitions are equivalent, but missed to check for polpermissive.  
  
ALTER POLICY cannot switch a policy to be PERMISSIVE or RESTRICTIVE, so  
this would need a dropped and then re-created policy, which would  
trigger a relcache invalidation.  Anyway, there is no harm in being  
consistent in the check, and if one decides to add an ALTER POLICY to  
switch PERMISSIVE or RESTRICTIVE, we would be silently in trouble.  
  
Author: Andreas Lind <andreaslindpetersen@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/CAMxA3rv1CS6R7JR5ojz-3CmCEnZEFrqu+XXTnGbLRWrjJRH7sA@mail.gmail.com  
Backpatch-through: 14  

commit   : d68576bcfc7227d94c4391a3c34aadb8dbf8a3c7    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 15 Jul 2026 09:20:35 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 15 Jul 2026 09:20:35 +0900    

Commit 9a60f295b stripped the stale PlaceHolderVars left behind by  
left-join removal from the surviving rels' baserestrictinfo and from  
EquivalenceClass member expressions, but it overlooked join clauses.  
A PlaceHolderVar embedded in a join clause can likewise retain the  
removed rel and join in its phrels, since remove_rel_from_query()  
fixes up the RestrictInfo's own relid sets but not the PHVs inside its  
expression.  
  
As before, this is normally harmless, because later processing  
consults those relid sets rather than the embedded PHVs.  However, a  
restriction clause derived from such an OR join clause inherits the  
stale PlaceHolderVar, and when the derived clause is translated for an  
appendrel child, pull_varnos() recomputes its relids and folds the  
removed relation back in.  The rebuilt clause then references a  
no-longer-existent relation, tripping an assertion during path  
generation.  
  
Fix by also stripping the removed relation from the PlaceHolderVars in  
the surviving rels' join clauses, including the sub-clauses of any OR  
clause.  
  
Like 9a60f295b, this is only reachable on v18 and later, where  
match_index_to_operand() began ignoring PlaceHolderVars.  
  
Author: Arne Roland <arne.roland@malkut.net>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/27a44087-3d65-473e-8d88-7c12228e0d7e@malkut.net  
Backpatch-through: 18  

commit   : 381b3cfe2be02aa114ef7a28c4ec24feaf377c63    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 08:05:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2026 08:05:03 +0900    

This reverts commit ed823da1289, that has made pgstat_write_chunk() and  
pgstat_read_chunk() available for public use.  These routines do not  
have a symmetric API definition across reads and writes, with the write  
part returning a void status, deferring an error detection once all the  
stats entries have been processed with an ferror(), and the read part  
returning a boolean status.  
  
These routines are just tiny wrappers around fread() and fwrite(), and  
extensions can just define they own routines instead of relying on the  
same facilities as the core pgstat.c.  This commit removes their  
declaration from the public headers, to reduce the confusion.  
test_custom_stats is updated to use its own read/write routines.  
Perhaps something better could be designed in the future; trying to do  
so for v19 is not feasable during beta.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Author: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/a4a8e9af-3eaf-4bbf-9b21-21620f3fc434@eisentraut.org  
Backpatch-through: 19  

commit   : e5354459383536a9644c4b0c8c26df0fcacae5f3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 01:39:33 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 01:39:33 +0300    

Commit 62c3b4cd9ddc taught postgres_fdw to push down ArrayCoerceExpr, but  
foreign_expr_walker() only recursed into the input array expression and  
never examined elemexpr, the per-element conversion that gives the  
coercion its semantics.  deparseArrayCoerceExpr() then shipped a bare  
"arg::resulttype" cast, or nothing at all for an implicit-format  
coercion, leaving the remote server to re-resolve the element conversion  
against its own catalogs and session state.  
  
This produced wrong results or remote errors whenever the element  
conversion was not a plain relabeling, and it was inconsistent with how  
postgres_fdw treats the equivalent scalar coercions.  An ArrayCoerceExpr  
was shipped even when its elemexpr was a cast function (whose  
shippability was never checked), a CoerceViaIO (e.g. float8out or  
byteaout, which depend on extra_float_digits / bytea_output that  
postgres_fdw sets differently on the remote session), or a  
CoerceToDomain (which pushes domain enforcement to the remote catalog).  
By contrast, a scalar CoerceViaIO is never shipped, and a scalar cast  
function is shipped only when it is shippable.  
  
Restrict pushdown to element coercions that are a plain relabeling, that  
is, elemexpr is a RelabelType or a bare CaseTestExpr.  Any other element  
coercion is now evaluated locally.  This keeps the common  
binary-coercible case pushed down, including "col = ANY($1)" with a  
varchar[]-to-text[] relabeling, which is the case 62c3b4cd9ddc set out to  
optimize.  
  
Pushing down shippable element cast functions, to reach parity with the  
scalar case, is left out here for simplicity.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260711024234.43.noahmisch%40microsoft.com  
Backpatch-through: 19  

commit   : 9ee5241d02442911ffec9a0ce35327a0fea4a5c1    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:48:07 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:48:07 +0300    

transformJsonTableNestedColumns() looked up the nested column named by a  
JSON_TABLE PLAN node and raised "invalid JSON_TABLE plan clause / PATH  
name was %s not found in nested columns list" if none was found.  That  
lookup cannot fail: validateJsonTableChildPlan() runs first, at every  
plan level, and already matches the plan's sibling path names one-to-one  
against the nested columns (reporting any uncovered nested path or any  
extra or duplicate sibling node).  The check has been unreachable since  
the PLAN clause code was first written.  
  
Replace it with an Assert documenting the invariant, which also removes  
a user-facing message that could never be emitted.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv5_9%3DzgA_Y7aoFp-%2BQSeh0kx4dfbAas9Wx%3DyrweQSqa6Q%40mail.gmail.com  

commit   : 6d8fd5a88183a65e77308aff374ebc239c44c6af    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:47:54 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:47:54 +0300    

86ab7f4c721d makes JSON_TABLE with a NESTED PATH re-ran the nested path's  
jsonpath expression several times for each parent row.  That makes such  
queries significantly slower as the nested arrays grew, even without a PLAN  
clause.  
  
Two leftovers from the plan/join executor rework were responsible.  
JsonTablePlanScanNextRow() still reset and advanced the nested plan  
itself, although JsonTablePlanNextRow() now does that; and  
JsonTableResetNestedPlan() eagerly called JsonTableResetRowPattern()  
(which evaluates the path) in addition to setting the reset flag that  
makes JsonTablePlanNextRow() evaluate it again.  Together these caused  
the nested path to be evaluated multiple times per parent row.  
  
Reduce JsonTablePlanScanNextRow() to advancing its own row pattern  
iterator, and have JsonTableResetNestedPlan() only reset the transient  
scan state (so a not-yet-advanced sibling still reads as NULL) while  
deferring the actual path evaluation to the reset flag.  The nested path  
is now evaluated exactly once per parent row, as before the PLAN clause  
feature; results are unchanged and are covered by the existing tests.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv5U94KD4C%2BLhAPYcCeGvs1xBMngcS5oEkZHN9YWwXUHsA%40mail.gmail.com  

commit   : 4a82912bb2a2bc757142eca48f0fded1817a9a7c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:47:33 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:47:33 +0300    

Correct the JSON_TABLE synopsis to place the ON ERROR clause after the  
PLAN clause, matching the grammar (the previous order could not be  
typed).  Replace a dangling reference to json_path_specification with  
path_expression, the term the synopsis actually defines.  Mark up the  
PLAN DEFAULT keywords with <literal> and fix a couple of wording issues.  
Also list OUTER before INNER consistently, including in the parent/child  
join description, where OUTER is the default.  
  
Author: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv5PGAFmAEpbhKQz8wppoOOTHfo-=LJb2sAB3974-9QtOw@mail.gmail.com  

commit   : cd5fd08be7ec1cef1a4c34791ce743954c2b2293    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:47:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:47:16 +0300    

generateJsonTablePathName() produced names of the form  
"json_table_path_N" in the same namespace as user-supplied path and  
column names, without checking whether the name was already in use.  
When an unnamed NESTED path's generated name happened to match a  
user-supplied path name that a PLAN clause referenced, two sibling paths  
matched the same plan entry and one of them, together with its columns,  
was silently dropped from the output.  
  
Bump the counter until the generated name is unused, so a generated name  
can no longer coincide with a user-supplied one.  The still-uncovered  
path is then correctly reported as not found in the plan.  
  
The row pattern (root) path is named before the user-supplied column and  
path names are collected, so when it is left unnamed its generated name  
could not avoid them either, and a user column or path named like a  
generated name, e.g.  
  
    SELECT * FROM JSON_TABLE(jsonb '1', '$'  
                             COLUMNS (json_table_path_0 int PATH '$')) jt;  
  
was rejected with a bogus "duplicate JSON_TABLE column or path name"  
error.  Collect the user-supplied names first and generate the row  
pattern path's name afterwards, so that it avoids all of them.  An  
explicit root path name is still seeded into the namespace, so a column  
duplicating it is still correctly rejected.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv7aZGSExnbjJRw8eKkoXbu34TdoKLLA2gPye3aHjO5OSA@mail.gmail.com  
Discussion: https://postgr.es/m/CAA-aLv5U94KD4C%2BLhAPYcCeGvs1xBMngcS5oEkZHN9YWwXUHsA%40mail.gmail.com  

commit   : 160ef2751b524cbc797e59642543790c4a8132ec    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:46:56 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:46:56 +0300    

get_json_table_plan() parenthesized the child of a parent/child  
(OUTER/INNER) plan only when that child was a sibling (UNION/CROSS)  
join, not when it was itself a parent/child join.  A plan such as  
PLAN (p0 OUTER (p1 INNER p11)) was therefore deparsed as  
PLAN (p0 OUTER p1 INNER p11), which does not parse back to the same  
plan tree -- a dump/restore hazard.  Parenthesize the child whenever it  
is not a bare path name, matching the logic already used for the  
operands of sibling joins.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv7aZGSExnbjJRw8eKkoXbu34TdoKLLA2gPye3aHjO5OSA@mail.gmail.com  

commit   : af6fad879fbf9b542cfde05c52695c9dffa6bb47    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:46:40 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 15 Jul 2026 00:46:40 +0300    

86ab7f4c721d commit made the table-level ON ERROR clause serve as the default  
ON ERROR for columns lacking their own, so that a top-level ERROR ON ERROR  
turned per-column evaluation errors into hard errors.  
  
The SQL standard does mandate this cascade, but introducing it should be  
a deliberate, separately-documented change, so restore the previous  
behavior for now.  This also reverts the paired ruleutils.c logic that  
deparsed a column's behavior against an ERROR default: that dropped an  
explicit ERROR ON EMPTY from a dumped view, and otherwise emitted a  
redundant NULL ON EMPTY.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv7aZGSExnbjJRw8eKkoXbu34TdoKLLA2gPye3aHjO5OSA@mail.gmail.com  

commit   : d15a6bc2e16d4b330d6d455e41ce1ab3395d8e03    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jul 2026 10:28:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jul 2026 10:28:04 +0200    

_Generic is the C11 standard equivalent (and superset) of  
__builtin_types_compatible_p, so by replacing the latter with the  
former, we can now rely on this working on all compilers, instead of  
previously just with GCC-compatible ones.  And we can drop a configure  
test.  
  
This affects StaticAssertVariableIsOfType() and  
StaticAssertVariableIsOfTypeMacro() and indirectly unconstify() and  
unvolatize().  
  
Neither _Generic nor __builtin_types_compatible_p works in C++, so  
this does not change that, but this adds an explicit code comment  
about that.  
  
There are some subtle behavior changes, but these do not affect cases  
that are in use or likely to be useful.  _Generic does lvalue  
conversion on the controlling expression, which means it drops  
top-level qualifiers and converts arrays to pointers.  
__builtin_types_compatible_p on the other hand, supports arrays and  
just ignores qualifiers.  So before, StaticAssertVariableIsOfType(x,  
const int) might have worked, but now it does not.  (But note that it  
would previously have succeeded even if x was a non-const int, so this  
usage would always have been dubious.)  Also,  
StaticAssertVariableIsOfType(y, char[]) would have worked, but now you  
need to write char *.  (But this is not backward compatible, because  
char * would previously not have succeeded.)  Similarly, unconstify of  
non-pointers, like unconstify(const int, x) would previously have  
worked, but this was just by accident and never useful (you can just  
assign directly, without a cast), and the C++ implementation rejects  
non-pointers anyway.  Some comments are added to explain this a bit.  
There are no current uses affected by this.  
  
Note that even though we have required C11 since f5e0186f865, we have  
not made use of _Generic until now (except in an MSVC-specific case in  
commit 59c2f03d1ec).  This now raises the effective compiler  
requirement on the trailing edge slightly from GCC 4.8 to GCC 4.9.  
This in turn means that we effectively drop support for RHEL 7.  
  
Author: Peter Eisentraut <peter@eisentraut.org>  
Co-authored-by: Thomas Munro <thomas.munro@gmail.com>  
Co-authored-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://www.postgresql.org/message-id/flat/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com  

commit   : 8f71f64deee6747ad9dea18819018b25424d61e5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2026 08:00:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2026 08:00:46 +0900    

This commit adds a test case for early startup where a backup_label file  
uses a checkpoint LSN and a redo LSN located in two different segments,  
where the segment of the redo LSN is missing.  This code has never been  
covered, and is complex enough that a test case is going to be useful in  
the long-term.  
  
Nitin has proposed a more complex approach than what is added by this  
commit, by forcing a reuse of the injection points to produce a split  
between redo and checkpoint.  This commit relies on the checkpoint and  
redo LSNs generated by the first steps of the test, combined with a  
generated backup_label, making the whole cheaper.  
  
Author: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com  

commit   : 7b87f08e8778c2d38c95e3808419e2d18c55c672    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    

It was using int for the input and output length, where size_t or  
ssize_t would be more appropriate.  It might not matter in practice,  
but it makes the APIs consistent at all levels.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 1ae87df63ff693a91fbcb968850103a5a5d8cd96    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    

The return type is ssize_t, not int.  Fix that in one instance; the  
others were already okay.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 302222eddc3967d11c11708a59bdafd6d51da556    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    

The return type of readlink() per POSIX is ssize_t, but most existing  
callers use int, so fix that.  Also fix the return type of the Windows  
implementation to match.  
  
In _pglstat64(), we neglected to handle the case where the output  
buffer is not large enough and the result would be truncated.  This  
case actually can't happen, because the Windows pgreadlink()  
implementation doesn't ever return that case, but adding this seems  
good for consistency with _pgstat64(), which already had this check,  
and in case pgreadlink() ever changes in this regard.  
  
Some callers of readlink(), in particular _pglstat64(), assume that  
errno == EINVAL means that the file was not a symlink.  But Windows  
pgreadlink() also sets EINVAL in other cases, in particular if the  
buffer was too small.  This could result in incorrect behavior, so  
pick a different errno.  (There might be other cases where EINVAL is  
set inappropriately, but they are outside the theme of this patch.)  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 8ef9896e61e7699a676f7dca33636d0533b38edb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    

It needs to be much earlier in win32_port.h so that declarations in  
that file can also use it.  To be used by a subsequent patch.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 7f77b2a89bd4788b6bd686ba63138f51302d9839    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jul 2026 11:01:36 +0200    

These are some cases in the vicinity of the patches to improve the  
size_t/ssize_t use with POSIX file system APIs.  For example, the  
input buffers for write operations or the file names passed for error  
reporting can be const.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/f9aab072-0078-49e4-ab93-3b08086a4406@eisentraut.org  

commit   : 1863452a4bfecfefc51336ecfc78837a164fbb10    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jul 2026 09:27:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jul 2026 09:27:47 +0530    

A table published both explicitly and through its schema (FOR TABLES IN  
SCHEMA) was listed twice by \dRp+ and \d.  Since publishing a schema  
publishes its tables in full, the explicit entry's row filter has no  
effect; suppress it when the same publication also publishes the table's  
schema.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Co-author: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Discussion: https://postgr.es/m/CAHut%2BPvSOmRrQX%2BVrFYHtFipV9hM%3Dp99FeOwYCzkuU2BOaLu7Q%40mail.gmail.com  

commit   : 2b8598a2b045b172a8f726ba130e9eb764dc0688    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jul 2026 09:19:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jul 2026 09:19:20 +0900    

This test is able to trigger the following failure at the beginning of  
recovery, that was not covered yet:  
FATAL:  could not locate required checkpoint record at %X/%X  
  
Note that the backup used for the node created has its pg_wal/ removed,  
which is why the segment expected is missing.  
  
Extracted from a larger patch by the same author.  
  
Author: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Discussion: https://postgr.es/m/CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com  

commit   : 1c4b1de888559a47df599dcef356ea7fbf96fd0c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 11 Jul 2026 15:14:50 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 11 Jul 2026 15:14:50 +0200    

The pg_attribute_always_inline macro name is so long it forces pgindent  
to format the code in strange ways. Which may incentivize patch authors  
to either structure the code in strange ways (e.g. reorder prototypes),  
use shorter names, etc. Neither is very desirable for code readability.  
  
This shortens the name by removing the _attribute_ part. It also makes  
it more consistent with pg_noinline, which does not have the _attribute_  
part either.  
  
Backpatched to all supported branches, to prevent conflicts when  
backpatching other fixes. The backbranches however keep both the old and  
new macro name, so that existing code keeps working.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/bqqdehahpoa36igpictuqyn2s2mexk3t3ehidh2ffd2slb35e5@rzgksuiszgbg  
Backpatch-through: 14  

commit   : 5f14f82280db4b0e49d774362854c9d362106484    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jul 2026 14:38:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jul 2026 14:38:33 +0200    

lengthof returns type size_t, but most for loops used int as a loop  
variable.  Fix that.  This avoids possible warnings about  
signed/unsigned mismatches under higher warning levels.  (The compiler  
will likely optimize these loops beyond recognition, so this shouldn't  
affect the generated code much.)  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/d639aede-209f-412b-927a-d38d4848b370%40eisentraut.org  

commit   : e615da8cb21b3745456da45197fa5dc620f19dab    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jul 2026 14:38:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jul 2026 14:38:33 +0200    

A number of for loops used loop variables that did not match the type  
of the end condition.  This could lead to wraparound or  
signed/unsigned mismatches.  Probably none of these are a problem in  
practice, but it's fragile code.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/d639aede-209f-412b-927a-d38d4848b370%40eisentraut.org  

commit   : eed6c0d33e09c53e5861fa92e99318814c5862f7    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Fri, 10 Jul 2026 18:10:23 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Fri, 10 Jul 2026 18:10:23 -0400    

b46e1e54d078de allowed setting the VM while on-access pruning, but it  
neglected to update the freespace map. Once the page was all-visible,  
vacuum could skip it, leading to stale freespace map values and,  
effectively, bloat. Fix it by updating the FSM if we updated the VM.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/flat/CAAKRu_b2StZrEC%3DHmW8LePuQbczyFRnfs8qTAJwn_%3DW76-y24w%40mail.gmail.com  
Backpatch-through: 19  

commit   : c787c952bc882626c66ec64b1d35a664902bfa8b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 10 Jul 2026 13:25:08 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 10 Jul 2026 13:25:08 -0400    

In c75ebc657ffc I (Andres) introduced UnlockBufHdrExt() which can set and  
clear bits in the buffer state using CAS. Unfortunately I added bits before  
subtracting them, which means that a bit that was both removed and set would  
remain unset.  Fix the order of operations.  
  
The only known case where that is a problem is that BM_IO_ERROR would not  
actually remain set.  
  
It's unfortunately not trivial to add a decent, race-free, test to verify that  
BM_IO_ERROR remains set. That's therefore left for the 20 cycle.  
  
Reported-by: Yura Sokolov <y.sokolov@postgrespro.ru>  
Discussion: https://postgr.es/m/ab0dcc9e-aba0-44e3-ac23-8d74c48888e6@postgrespro.ru  
Backpatch-through: 19, where c75ebc657ffc went in  

commit   : c71d43025d7aaf12fe461ec635bd2eda220c9f4a    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 10 Jul 2026 16:10:36 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 10 Jul 2026 16:10:36 +0200    

When doing a whole database repack, we build a list of tables to process  
taking a lock on each.  But because it's a regular transaction-scoped  
lock, it's automatically released immediately after building the list  
anyway, which makes it not very useful.  (Also, we have three ways to  
obtain a list of tables to repack, and only one of them acquired this  
lock.)  Remove that lock acquisition, as it's useless and inconsistent.  
  
We acquire a lock properly afterwards (and recheck that the table can  
still be repacked as indicated), so we don't need to do anything other  
than drop that initial lock acquisition and harden the code in  
repack_is_permitted_for_relation() against possible concurrent drops.  
This is similar to how vacuum does it in get_all_vacuum_rels().  
  
In order for this to work reliably, also change  
repack_is_permitted_for_relation() to cope with the possibility of the  
table going away partway through.  Similarly, in ExecRepack(), be  
prepared for what we believed to be a table or matview to now be  
something else, and skip it without erroring out, by changing  
try_table_open() to try_relation_open() and testing the relkind  
separately.  
  
While at it, replace one relation_close() call in get_tables_to_repack()  
with table_close() to match the table_open() that opened the catalog.  
  
Author: ChangAo Chen <cca5507@qq.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com  

commit   : 97a18c221b8a71c89a68870c0c0343759b41d290    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 22:34:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 22:34:24 +0900    

When building the list of temporary relations to wait for, the code  
previously included temporary relations without storage, such as  
temporary views, even though they are irrelevant to checksum  
processing. As a result, enabling data checksums could wait for a  
long-lived session that owned only a temporary view.  
  
This commit fixes the issue by filtering temporary relations with storage  
only, matching the existing behavior for non-temporary relations.  
  
Also, when enabling data checksums online, the launcher assigns the  
first worker to process shared catalogs and prevents later workers from  
doing so. Previously, if that worker's database was dropped after it  
had been selected for processing but before checksum processing began,  
the worker failed without processing the shared catalogs, yet they were  
still marked as processed. As a result, later workers skipped them, and  
checksum enabling could complete successfully even though the shared  
catalogs had never been processed.  
  
This commit fixes the issue by marking shared catalogs as processed  
only after a worker completes successfully.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAHGQGwGDHAQw=bmpRzk+EmKzVtxZiD5YDurMUffBMwr6WXugQA@mail.gmail.com  
Backpatch-through: 19  

commit   : e9810253f095f19aab899694f491a1a529f9eb4d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 22:32:53 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 22:32:53 +0900    

pg_stat_progress_data_checksums uses -1 as a sentinel value that is  
displayed as NULL for progress counters. However, after  
pgstat_progress_start_command() initialized all progress counters to  
zero, data checksum progress did not reset those counters to -1.  
As a result, some counters could incorrectly appear as zero instead  
of NULL. For example, workers could report zero database counters,  
and the disabling launcher could report zero relation and block counters.  
  
Also, blocks_done was not reset when a worker started processing  
a new relation fork. As a result, it could temporarily exceed blocks_total  
or report a stale value for an empty relation fork.  
  
Fix this by initializing the data checksum progress counters to -1  
when progress reporting starts for both launcher and worker processes.  
Also reset blocks_done together with blocks_total when starting each  
relation fork.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAHGQGwEOQyEzW2cqrHEzvwbcsAsuH8MEe7MMidFOFxECy0E1_Q@mail.gmail.com  
Backpatch-through: 19  

commit   : 701f021b680ec33a799022d31b574fbcd618a40f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 20:36:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 20:36:36 +0900    

The set_*_arg helper functions in postgres_fdw.c are declared  
static, but their definitions omitted the static keyword. Add it to  
make their file-local scope explicit and keep the declarations and  
definitions consistent.  
  
Also fix a couple of nearby comment typos.  
  
This is a followup to commit 54cd6fc8317.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGjcQ4SwHMUQ9P8UYQ7iLKL1QE3uLSdONToQ1MrzpUUoQ@mail.gmail.com  
Backpatch-through: 19  

commit   : dfce19c2300ab00a8c41386e49dfdd6a3c8edae9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 10 Jul 2026 10:08:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 10 Jul 2026 10:08:21 +0200    

Previously, an attempt to use these features together caused a crash.  
Oversight of commit 8e72d914c528.  
  
Tests are added also to show that the check for this should be in the  
rewriter, not the parser, as an earlier patch version suggested.  
  
Author: Aleksander Alekseev <aleksander@tigerdata.com>  
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAJ7c6TME%2Bix6VRf-2TPnVTsj8qn_hy6sYAOmMhZEivwsu2wS6g%40mail.gmail.com  

commit   : 54cd6fc83176d7c03abf95554aef26b0b24acc7d    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 10 Jul 2026 13:20:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 10 Jul 2026 13:20:00 +0900    

Previously, this function imported remote statistics by executing SQL  
functions like pg_restore_relation_stats and pg_restore_attribute_stats  
via SPI (in read-write mode).  As the SQL functions take a schema name  
and a relation name as two separate arguments, rather than a single OID  
argument, if the containing schema was concurrently renamed, the  
callback function would throw an error like this:  
  
  ERROR: schema "foo" does not exist  
  
To fix, 1) provide new interface functions to import remote statistics  
that are directly callable from FDWs and take a single OID, and 2)  
modify the callback function to use the interface functions instead when  
importing remote statistics.  
  
For #1, this commit does a bit of refactoring to  
relation_statistics_update and attribute_statistics_update, which are  
the workhorse functions for pg_restore_relation_stats and  
pg_restore_attribute_stats respectively: since they also take a schema  
name and a relation name, separate the guts of them into new functions  
so that they take a single OID and are callable not only from the  
workhorse functions but from the interface functions introduced by #1.  
  
Oversight in commit 28972b6fc.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Suggested-by: Robert Haas <robertmhaas@gmail.com>  
Author: Corey Huinker <corey.huinker@gmail.com>  
Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CA%2BTgmoYqMtWb4zLUkT98oFnEkJ%3DWz0Pw-ggDJrp9wnSXPzUaeQ%40mail.gmail.com  
Backpatch-through: 19  

commit   : 5594f209c3eff6e478e1d6109094f14b59bd3dce    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 08:37:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 08:37:59 +0900    

truncate_query_log() returns NULL when statement truncation is  
disabled or the supplied query does not need to be truncated. Therefore,  
callers do not need to check log_statement_max_length before calling  
it.  
  
Remove the redundant checks and let truncate_query_log() make the  
decision in one place. This simplifies the statement and duration  
logging code without changing its behavior.  
  
Author: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwFOV+7nOdfoO=kfVH=-fRA9aQE1YcHHLYty3nfQ9rQ4RA@mail.gmail.com  

commit   : 999a8412bbabec4811195fee7e315c282c97f694    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 08:36:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Jul 2026 08:36:46 +0900    

log_statement_max_length limits the statement text logged by  
log_statement and duration logging. However, the prepared statement  
shown in the DETAIL message for EXECUTE was still logged in full,  
allowing very large prepared queries to bypass the limit.  
  
Apply the same truncation to the prepared statement text in  
errdetail_execute(), making the setting behave consistently across the  
main log message and its associated DETAIL output.  
  
Also append an ellipsis to truncated statement text so users can easily  
tell when truncation has occurred. With this change, a limit of zero  
logs only the ellipsis, indicating that the entire statement text was  
truncated.  
  
Finally, avoid scanning the entire query string just to determine  
whether truncation is needed. Use strnlen() with sufficient lookahead  
for multibyte character handling, then use pg_mbcliplen() to ensure  
truncation never splits a multibyte character.  
  
Author: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwFOV+7nOdfoO=kfVH=-fRA9aQE1YcHHLYty3nfQ9rQ4RA@mail.gmail.com  

commit   : 21e958c303bc8f79627726f4f15a8428c6a22003    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 9 Jul 2026 22:23:26 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 9 Jul 2026 22:23:26 +0300    

86ab7f4c721d misses catversion bump as it adds new fields to the existing  
nodes.  
  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv7aZGSExnbjJRw8eKkoXbu34TdoKLLA2gPye3aHjO5OSA%40mail.gmail.com  

commit   : 8f7af125e03739b66998a75840dedd943ec3624e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 9 Jul 2026 11:09:53 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 9 Jul 2026 11:09:53 -0500    

The spinlock is unnecessary because the counter is only ever  
accessed with WaitEventCustomLock held exclusively.  This commit  
removes the struct definition and converts WaitEventCustomCounter  
to a pointer to an integer in shared memory.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/ak8MeTS9QBmz6DKt%40nathan  

commit   : 17accbe0f4e8a9afd563a8e255fead45e5145de5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:27 +0300    

Check explicitly for pqsecure_read() returning an error. It shouldn't  
fail, and we would've caught it in the check for a short read, but  
better to be explicit so that the error message is more informative.  
We also shouldn't update 'inEnd' when the read fails, although that  
too is just pro forma as we will bail out and close the connection on  
error.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://www.postgresql.org/message-id/34844e8c-267c-4daf-b1e0-f26059a4a7d3@eisentraut.org  
Backpatch-through: 14  

commit   : d293f03455b2db859249f9876e4b5ec24c95d11a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 18:34:24 +0300    

When compiling against OpenSSL, the <limits.h> header is indirectly  
included via openssl/ossl_typ.h from openssl/conf.h, but the LibreSSL  
version of ossl_typ.h does not include <limits.h> which cause compiler  
failure due to missing symbol (since ffd080d94fe).  Fix by explicitly  
including <limits.h>.  
  
Author: Daniel Gustafsson <dgustafsson@postgresql.org>  
Discussion: https://www.postgresql.org/message-id/6A9E7815-BD5A-4C31-A515-48159823406B@yesql.se  
Backpatch-through: 14  

commit   : dff789e555404571cc76097c1539e93dc7f2e3de    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 15:14:19 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2026 15:14:19 +0300    

Autovacuum launcher is not an aux process, so it needs to be  
advertised in InitProcess() rather than InitAuxiliaryProcess()  
  
In the passing, also remove some now-unnecessary 'volatile' qualifiers  
left behind by the same commit.  
  
Reported-by: Thom Brown <thom@linux.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAA-aLv6UHXubNxmAjNH8PnyKKkaXePO1ggB15=iidNW08T4hSg@mail.gmail.com  

commit   : 86ab7f4c721d61282c058acc0b4aa0b3adf04410    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 9 Jul 2026 14:37:31 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 9 Jul 2026 14:37:31 +0300    

This patch adds the PLAN clauses for JSON_TABLE, which allow the user  
to specify how data from nested paths are joined, allowing  
considerable freedom in shaping the tabular output of JSON_TABLE.  
PLAN DEFAULT allows the user to specify the global strategies when  
dealing with sibling or child nested paths. This is often sufficient  
to achieve the necessary goal, and is considerably simpler than the  
full PLAN clause, which allows the user to specify the strategy to be  
used for each named nested path.  
  
Path names may be attached to the row pattern and to each NESTED path  
using AS.  Unlike the SQL/JSON standard, which requires a name for every  
NESTED path when a PLAN clause is present, PostgreSQL does not require  
them and generates a name for any path left unnamed; a specific PLAN()  
can only reference paths by name, so unnamed paths it must mention are  
reported as not covered by the plan.  
  
Author: Nikita Malakhov <n.malakhov@postgrespro.ru>  
Co-authored-by: Nikita Glukhov <n.gluhov@postgrespro.ru>  
Co-authored-by: Teodor Sigaev <teodor@sigaev.ru>  
Co-authored-by: Oleg Bartunov <obartunov@gmail.com>  
Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com>  
Co-authored-by: Andrew Dunstan <andrew@dunslane.net>  
Co-authored-by: Amit Langote <amitlangote09@gmail.com>  
Co-authored-by: Anton Melnikov <a.melnikov@postgrespro.ru>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Andrew Alsup <bluesbreaker@gmail.com>  
Reviewed-by: Erik Rijkers <er@xs4all.nl>  
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>  
Reviewed-by: Himanshu Upadhyaya <upadhyaya.himanshu@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Vladlen Popolitov <v.popolitov@postgrespro.ru>  
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru  
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de  
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org  
Discussion: https://postgr.es/m/CA+HiwqE4XTdfb1nW=Ojoy_tQSRhYt-q_kb6i5d4xcKyrLC1Nbg@mail.gmail.com  
Discussion: https://postgr.es/m/CAN-LCVP7HXmGu-WcinsHvdKqMGEdv=1Y67H4U58F6Y=Q0M5GyQ@mail.gmail.com  

commit   : 2e6578292a9184dcaae6c5abc235a26db9cb2973    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jul 2026 10:10:07 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jul 2026 10:10:07 +0200    

Specifying a locking clause (FOR UPDATE/SHARE) that names a  
GRAPH_TABLE alias currently results in an unhelpful "unrecognized RTE  
type: 8" error.  This commit explicitly prohibits specifying a locking  
clause on a GRAPH_TABLE alias, raising a more user-friendly error  
instead.  
  
(Locking clause support for GRAPH_TABLE could be added as a separate  
feature in the future.)  
  
Author: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDcE9wp6nOEC3SCRQ90nrCO%3DQF%2BOZq1MG8Qc6hnusmogqw%40mail.gmail.com  

commit   : 51ceb751eaed32950013a8084dd2ae2bf3ce465d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jul 2026 09:53:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jul 2026 09:53:18 +0200    

In transformLockingClause(), there was a comment that listed all the  
RTE kinds it did not want to process, but that list was already  
outdated about what RTE kinds actually exist.  Rather than keeping  
that up-to-date, just say "all other".  
  
Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDcE9wp6nOEC3SCRQ90nrCO%3DQF%2BOZq1MG8Qc6hnusmogqw%40mail.gmail.com  

commit   : df293aed46e3133df3b5b337f095e3ebed69fd79    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 9 Jul 2026 14:23:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 9 Jul 2026 14:23:42 +0900    

pg_restore_attribute_stats() and pg_restore_extended_stats()  
(expressions) can handle a STATISTIC_KIND_BOUNDS_HISTOGRAM value, but  
did not check its shape when importing, especially regarding:  
- Empty ranges.  
- Unsorted elements.  
  
These properties are respected by ANALYZE in compute_range_stats(), when  
computing a histogram for a [multi]range, and by the planner when  
reading the data from the stats catalogs.  The effects of importing data  
with these properties depend on the compilation options:  
- A assertion would be hit, if enabled.  
- A non-sensical value that would make the load of the stats fail.  
- A failure is hit if an empty range is loaded.  
  
While the owner of the table or the one with MAINTAIN rights is  
responsible for the stats data inserted, buggy data makes little sense  
if their load is going to fail.  This commit adds a validation step to  
match what compute_range_stats() expects.  
  
This issue would be unlikely hit in practice, so no backpatch is done.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://postgr.es/m/CAON2xHNM809WLR_g0ymKgU-tWxtbyH1Xvh4fqzRqy9YP2A59pg@mail.gmail.com  

commit   : c1702cb513634878425e8b3f49dc1894d2aa781e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 9 Jul 2026 08:09:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 9 Jul 2026 08:09:07 +0530    

Explain more accurately how REFRESH SEQUENCES differs from REFRESH  
PUBLICATION in ALTER SUBSCRIPTION, and note that CREATE SUBSCRIPTION uses  
copy_data = true (the default) to copy initial sequence values.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 19  
Discussion: https://postgr.es/m/CAHut+PtFkGvZNihGRDoghWNKMfJufEpR9+thbG_8qPQ7RyVN4w@mail.gmail.com  

commit   : e01b23b84e4346c1941e2aad78e3d80a5498038d    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 9 Jul 2026 09:44:56 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 9 Jul 2026 09:44:56 +0900    

We've long had enable_hashagg to discourage hashed aggregation, but  
there was no equivalent for grouping that works by reading presorted  
input.  That's handy when investigating planner cost misestimates, and  
as an escape hatch when a sorted grouping plan is chosen over a much  
cheaper hashed one.  
  
enable_groupagg (on by default) covers the GroupAggregate and Group  
nodes, the sort-based Unique step used for DISTINCT and semijoin  
unique-ification, and the sorted mode of SetOp.  It isn't a hard  
switch; it only bumps disabled_nodes, so plans with no other choice  
are still produced.  
  
Several regression and module tests had been setting enable_sort off,  
and one enable_indexscan off, only to force a hashed plan.  Use  
enable_groupagg there instead, where that was the real intent.  In  
union.sql this also lets us test the hashed UNION path, which we had  
no way to reach before.  
  
Author: Tatsuro Yamada <yamatattsu@gmail.com>  
Co-authored-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAOKkKFvYHSEsFazkrf9bRH14p-H27XMaqbZfRYjS6EHBruvZMQ@mail.gmail.com  

commit   : ff076c042a7467c2870d6dac4eba48651498d57b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Jul 2026 09:12:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Jul 2026 09:12:13 +0900    

Add pg_stat_progress_data_checksums to the progress reporting summary  
and the list of commands with progress reporting.  
  
Also clarify that the view reports both enabling and disabling data  
checksums, and correct the documented types of its progress counters  
to bigint.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAHGQGwHJHJYAkYZBi3_O13np-Rou9UL637=hB3Y_-qdCgcZn-w@mail.gmail.com  
Backpatch-through: 19  

commit   : b5d73d2dd73d5a0dc744bf82ec3c18846c42c072    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2026 11:50:18 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2026 11:50:18 +1200    

I had previously made "seed" a uint64, as that's what pg_prng_seed()  
expects to get.  However, GetCurrentTimestamp() and PG_GETARG_INT64()  
both return int64, so there was a mismatch in signedness.  
  
There are no bugs being fixed here, but it seems cleaner to make the  
variable int64 and cast to unsigned when passing to pg_prng_seed().  This  
means we no longer have to use the INT64_FORMAT specifier on the unsigned  
type to format the seed of the failing test correctly to allow a user to  
use the same seed from SQL when trying to recreate any failures manually.  
  
The most important thing to ensure is correct here is that users can  
specify the full range of seed values that could be automatically  
selected by GetCurrentTimestamp() so that we can recreate any failures  
from runs where the seed was auto-selected.  This still works as  
expected when using the int64 type.  
  
In passing, adjust a comment that was a little misleading.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/08fa9f01-373e-4cb4-9650-ad20517e2de3@eisentraut.org  

commit   : 881033ae8b55dbd22f7ee9c26991b6c4e67d6bd5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 9 Jul 2026 02:17:08 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 9 Jul 2026 02:17:08 +0300    

The new partitions built for ALTER TABLE ... SPLIT PARTITION and  
ALTER TABLE ... MERGE PARTITIONS are created at the explicit request of  
the user, just like a plain CREATE TABLE.  createPartitionTable() passes  
is_internal=true to heap_create_with_catalog(), while createTableConstraints()  
does the same to StoreAttrDefault() and AddRelationNewConstraints().  
Pass is_internal=false in all these places instead, so that object-access  
hooks treat them as user-requested objects.  The is_internal flag is intended  
for objects created as internal implementation details, such as a transient  
heap built during CLUSTER.  
  
While at it, pass 0 rather than PERFORM_DELETION_INTERNAL to the  
performDeletionCheck() calls that pre-check the drop eligibility of the  
old partitions, to match the subsequent performDeletion().  The flag has  
no functional effect on performDeletionCheck(), but change this for code  
consistency.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260707185751.f9.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : 5e90e0914cfa9345de35efd34eb7a94b59bc23b5    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 8 Jul 2026 16:22:12 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 8 Jul 2026 16:22:12 -0500    

refint was sample code from the pre-built-in-FK era and has long  
been documented as superseded by the built-in foreign key  
mechanism.  Recent fixes (see commits b0b6196386, 8cfbdf8f4d,  
260e97733b, 611756948e, 1fbe2066dc, and 1541d91d1c) made it clear  
that the code has more issues than its sample-code value justifies.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: solai v <solai.cdac@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAJTYsWUHq8Ohc6-N-xamOPYz-q3qUYMtwQX-1%3DZi%3D5N1Q_GSEQ%40mail.gmail.com  

commit   : 8e0c252753bac55601f23f0c04d4e1601fb60074    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 8 Jul 2026 20:46:25 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 8 Jul 2026 20:46:25 +0100    

When executing an UPDATE with a RETURNING clause on a table with a  
BEFORE UPDATE row trigger, the computation of the OLD values in the  
RETURNING list was incorrect if the target tuple was concurrently  
updated by another session, at isolation level READ COMMITTED.  
  
The problem was that the trigger code would lock the target tuple,  
waiting for the other session to commit, and then fetch the updated  
target tuple, but ExecUpdate() would not realise that the target tuple  
had changed, and use the outdated target tuple for computing OLD  
values. Fix by having ExecUpdate() check the TM_FailureData from  
trigger execution and re-fetch the target tuple if necessary.  
  
Re-fetching the target tuple like this is a little inefficient, but  
probably negligible compared to the trigger execution and update. A  
better long-term fix might be to move the EPQ code out of trigger.c,  
and let ExecUpdate() handle it, like ExecMergeMatched() does, but that  
would likely mean changing the trigger API, which seems a bit much for  
back-patching.  
  
Backpatch to v18, where support for RETURNING OLD/NEW was added.  
  
Bug: #19536  
Reported-by: Jonas Boberg <bobergj@gmail.com>  
Diagnosed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://postgr.es/m/19536-73ce5847e6c0e7b1@postgresql.org  
Backpatch-through: 18  

commit   : 306d7680f084cf320841128f23d888294ecba6cd    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 8 Jul 2026 20:44:22 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 8 Jul 2026 20:44:22 +0300    

WAIT_FOR_WAL_FLUSH, WAIT_FOR_WAL_REPLAY, and WAIT_FOR_WAL_WRITE were  
placed in the WaitEventClient class.  But WaitEventClient is about  
waiting for a socket to become readable or writable, while these events  
have other delay sources as well: local fsync and local replay, which  
may be disk- or CPU-bound.  WaitEventIPC is a better fit, so move them  
there.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260706012642.f9.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : a4639d64e2199885f8e995395b6fe874cb7228bf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2026 18:44:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2026 18:44:54 +0200    

When changing the expression of a generated column via ALTER TABLE  
ALTER COLUMN SET EXPRESSION, objects that depend on the column via  
indirect whole-row references (such as CHECK constraints, indexes)  
must be handled specially, because technically pg_depend does not  
contain such dependencies, see  
recordDependencyOnSingleRelExpr->find_expr_references_walker.  
  
This is a fix for commit f80bedd52, "Allow ALTER COLUMN SET EXPRESSION  
on virtual columns with CHECK constraints".  
  
Author: jian he <jian.universality@gmail.com>  
Co-authored-by: Peter Eisentraut <peter@eisentraut.org>  
Reported-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: solai v <solai.cdac@gmail.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAJTYsWXOkyeDVbzymWc9sKrq7Y_MUv6XJXN4H9GfsBOPd3NJ+w@mail.gmail.com  

commit   : 842169b6c110f48c9f7a2dc29d0cedcc97c2ff29    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 20:33:36 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 20:33:36 +0300    

This moves the responsibility of setting the ProcGlobal->walwriterProc  
and checkpointerProc fields into InitAuxiliaryProcess. Also switch to  
the same pattern to advertise the autovacuum launcher's ProcNumber,  
replacing the ad hoc av_launcherpid field in shared memory. This can  
easily be extended to other aux processes in the future, if other  
processes need to find them.  
  
Switch to pg_atomic_uint32 for the fields. Seems easier to reason  
about than volatile pointers. There was some precedence for that, as  
were already using pg_atomic_uint32 for the procArrayGroupFirst and  
clogGroupFirst fields, which also store ProcNumbers.  
  
Todo: We could also replace WalRecv->procno with this, but that's a  
little more code churn so I left that for the future.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/818bafaf-1e77-4c78-8037-d7120878d87c@iki.fi  

commit   : ad7877b00a4232d71bb4cb63c22f9d748e65e3f7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 18:45:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 18:45:09 +0300    

When pg_dump or pg_restore --jobs N is interrupted with Ctrl-C on  
Windows, we cancel all queries, but we don't want the cancellations to  
be reported as errors to the user in the short time before the whole  
process exits. That was previously achieved by calling  
TerminateThread() on each worker thread before sending the cancel  
message, but that doesn't appear to be 100% safe: the implementations  
of write() and the socket calls inside PQcancel() might acquire user  
space locks that were held by the terminated threads.  (write()  
certainly does that.)  
  
Instead of silencing the threads in such a sketchy way this now sets a  
volatile flag before sending any cancel requests that tells the  
threads to not log errors anymore. (Instead of a volatile, it would be  
better to use an atomic operation here, but that has to wait until we  
add support for atomics on the frontend.)  
  
Note that this also stops using pg_fatal() and exit to exit() from  
workers on failure and instead use pg_log_error combined with  
exit_nicely. If a query fails in a worker we want it to kill the  
worker not the whole process. On Unix that's currently the same thing,  
but on Windows workers are threads.  
  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Bryan Green <dbryan.green@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://www.postgresql.org/message-id/DJPQS3FYSD4U.3DBTXA6U8IQ0Q@jeltef.nl  

commit   : bb7ded1eebed708865d9bb0a3513c7ed3afe7065    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2026 01:11:42 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2026 01:11:42 +1200    

Effectively, a function to bitshift members by the specified number of  
bits.  We have various fragments of code doing this manually with a  
bms_next_member() -> bms_add_member() loop.  We can do this more  
efficiently in terms of CPU and memory allocation by making a new  
Bitmapset and bitshifting in the words of the old set to populate it.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/CAApHDvq=eEdw2Qp+aSzSOtTSe+h0fnVQ55CcTNqBkLDYiRZmxw@mail.gmail.com  

commit   : 3601f976c2e99123203413fd157f117632b3db78    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 18:16:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 18:16:38 +0900    

Sequence synchronization reports insufficient privileges on publisher  
and subscriber sequences, but the warnings do not indicate which role  
needs which privilege. This makes common configuration mistakes harder  
to diagnose.  
  
Add HINT messages for these warnings. Publisher-side warnings suggest  
granting SELECT to the role used for the replication connection.  
Subscriber-side warnings suggest granting UPDATE to the subscription  
owner when run_as_owner is enabled. Otherwise, the worker runs as the  
sequence owner, so no useful GRANT hint can be provided.  
  
Suggested-by : Amit Kapila <amit.kapila16@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://postgr.es/m/CAA4eK1JOo0aJRhFHNWpj3hMwaTtNOopY34f1Lh_QD=z=+DrzWQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 5412abc22d068ff52e13c60309e9d54eb08e6403    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 18:15:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 18:15:33 +0900    

The documentation previously said that pg_get_sequence_data() returns  
a row of NULL values if the sequence does not exist or if the current  
user lacks privileges on it. This was incomplete and could be misleading.  
A nonexistent relation name is rejected during regclass input conversion,  
while the function returns NULLs for a nonexistent relation OID and  
several other cases.  
  
This commit clarifies that the function returns NULLs when the specified  
relation OID does not exist, the relation is not a sequence, the current  
user lacks SELECT privilege on the sequence, the sequence belongs to  
another session's temporary schema, or it is an unlogged sequence on  
a standby server.  
  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAA4eK1JOo0aJRhFHNWpj3hMwaTtNOopY34f1Lh_QD=z=+DrzWQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 57f93af36f02a2559b005491d9fb0da660e32850    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2026 10:11:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2026 10:11:11 +0200    

When a string literal is provided as a property expression, the data  
type of the property was set to "unknown", which may lead to various  
failures when the property is used in GRAPH_TABLE or when its data  
type is compared against other properties with the same name.  To fix  
this, call resolveTargetListUnknowns() on the targetlist of new  
properties being added to resolve unknown type literals.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/20260630173053.51.noahmisch%40microsoft.com  

commit   : 16a4b3ef8eebd2f3da44c17523fef23d2de80679    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2026 09:40:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2026 09:40:46 +0200    

replace_property_refs() called expression_tree_mutator() with the root  
of the expression tree as the input node.  But  
expression_tree_mutator() does not call the mutator function on the  
root node, so the root node remains unchanged.  If the root node is a  
property reference or a lateral reference -- the two node kinds that  
replace_property_refs_mutator() rewrites -- it is returned unchanged.  
Modules after the rewriter do not know about property reference nodes,  
resulting in "ERROR: unrecognized node type: 63".  Since varlevelsup  
of lateral references is not incremented, they are not resolved  
correctly in the planner, leading to many different symptoms.  Fix  
this by calling replace_property_refs_mutator() directly from  
replace_property_refs(), similar to how other mutator functions do.  
  
The only case when a property reference or a lateral reference can be  
the root of a GRAPH_TABLE expression tree is when it is a bare  
property reference or a bare lateral reference in the WHERE clause.  
The COLUMNS clause is passed to replace_property_refs() as a  
targetlist.  Every other expression has at least one expression node  
covering the property reference or a lateral reference in the  
expression tree.  That explains why this bug was not seen so far.  
  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://www.postgresql.org/message-id/flat/20260630173053.51.noahmisch%40microsoft.com  

commit   : 4b587f666a73a5f8e2f8a47a1be010ffcb084955    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 10:20:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 10:20:34 +0300    

Reported-by: Erik Rijkers <er@xs4all.nl>  
Discussion: https://www.postgresql.org/message-id/6223b7dc-bfee-fcff-88d9-13f99b8d4897@xs4all.nl  
Backpatch-through: 19  

commit   : 8daeaa9b642c3c23cbc516da80d50aade6f4dc07    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2026 14:34:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2026 14:34:09 +0900    

This change switches the implementation of wait and wakeups in the  
module injection_points to not rely anymore on condition variables,  
using a more primitive implementation based on atomics.  The former  
implementation required a PGPROC, making it impossible to inject waits  
in the postmaster or during authentication.  A couple of use cases have  
popped up for these in the past, where this would have become handy.  
  
The loop in the wait callback that relied on a condition variable is  
replaced by an atomic counter, whose check increases over time in an  
exponential manner (starts at 10us for quick responsiveness, up to  
100ms).  
  
This change may be backpatched at some point depending on how much  
testing coverage is wanted.  Let's limit ourselves to HEAD for now,  
checking things first with the buildfarm.  
  
Creating a wait still requires the SQL interface.  We are looking at  
expanding that with an alternative implementation, so as early startup  
or authentication waits would become possible.  This refactoring piece  
is mandatory to achieve this goal.  
  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/aher0VsjJ8xeNgLq@paquier.xyz  

commit   : d92e98340fcb4c3ef728b3e8204573bdc86098f7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2026 13:22:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2026 13:22:50 +0900    

This is a continuation of the work done in ac59a90bef45.  The  
*GetDatum() macros for output should match with what the SQL functions  
use as DatumGet*() in input.  
  
Aleksander has spotted some of the areas patched here, for pageinspect.  
I have spotted the rest while digging into the state of the tree.  
  
There is no behavior change after this commit, since all the affected  
values are small enough that the signed bit is never used.  
  
Author: Aleksander Alekseev <aleksander@tigerdata.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/afLsqRjVqKK8hhKk@paquier.xyz  

commit   : d35e8babc4602c73ec4f66f93a5004a2ead62438    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 12:44:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 12:44:06 +0900    

Commit aa606b9316a disallowed generated columns in COPY FROM WHERE  
expressions, and commit 21c69dc73f9 disallowed system columns.  
However, the COPY reference page still mentions only the restriction  
on subqueries.  
  
Update the documentation to also list generated columns and system  
columns as unsupported in COPY FROM WHERE expressions.  
  
Backpatch the generated-column documentation change to all supported  
versions. Backpatch the system-column documentation change to v19,  
where that restriction was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwEgxErc54yVOAVWCsr1O=8pgw4oKRPuEQ9mfhkoYGR_XA@mail.gmail.com  
Backpatch-through: 14  

commit   : b5a8018116c422f39de94f69f0108ff0c9224f0a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 12:16:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 12:16:34 +0900    

Previously, when pg_recvlogical exited due to SIGINT or SIGTERM,  
it could terminate without sending final feedback for the last decoded  
changes it had already written locally. So, if pg_recvlogical was  
restarted afterwards, the server-side logical replication slot could  
still point behind those changes, causing them to be sent again.  
  
Make pg_recvlogical send final feedback once more during SIGINT/SIGTERM  
shutdown, before sending CopyDone. This gives the server one more chance  
to advance the slot far enough to avoid resending already-written data,  
so users are less likely to see duplicate decoded output after stopping  
and restarting pg_recvlogical.  
  
This remains a best-effort improvement rather than a guarantee. Depending  
on when the signal arrives, pg_recvlogical can already have written  
decoded output that the server cannot yet safely treat as confirmed, so a  
later restart can still receive duplicate data.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwE83z9O=X7ADMsSa3e1EuP3_GgqHjFt5SmPDNxZo_wgJA@mail.gmail.com  

commit   : 4721430f199ffaf0936dc19bd473f34e8b1ee791    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 12:02:21 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 12:02:21 +0900    

When fixing up the targetlist and qpqual of an outer join, we must  
account for the effects of the outer join.  Vars and PHVs appearing  
there are logically above the join, so they should have nullingrels  
equal to the input Vars/PHVs' nullingrels plus the bit added by the  
outer join.  
  
Determining the effects of the outer join can be tricky when the join  
has been commuted with another one per outer join identity 3.  In this  
case, the Vars/PHVs in the join's targetlist and qpqual should have  
the same nullingrels that they would if the two joins had been done in  
syntactic order.  Unfortunately, in setrefs.c, we don't have enough  
information to identify what that should be, so we have to use  
superset nullingrels matches instead of exact ones.  
  
However, we can tighten the check somewhat.  Currently, we check  
whether the jointype is JOIN_INNER and use NRM_SUPERSET if it is not.  
We can improve this by checking whether the Join node has non-empty  
ojrelids and using NRM_SUPERSET only in that case.  This allows us to  
perform exact matches in more situations.  
  
To support this, we record the outer-join relids in Join plan nodes.  
This information can also improve EXPLAIN (RANGE_TABLE) output by  
showing which outer-join relids are completed by each Join plan node.  
We may discover additional uses for this information in the future.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs482_DFHzQ079ZPp6c8UvmFdz3Jj+4K8tVRu9g2Bw34NPA@mail.gmail.com  

commit   : 3b0991059f33305118d850bb94fc9dca590c4ed6    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 12:01:44 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 12:01:44 +0900    

With the changes in the previous commit, we can now use exact  
nullingrels matches in all cases when fixing up expressions of  
upper-level plan nodes that are not joins.  Therefore, we can remove  
the nrm_match parameter from fix_upper_expr(), along with the  
corresponding field in fix_upper_expr_context.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs482_DFHzQ079ZPp6c8UvmFdz3Jj+4K8tVRu9g2Bw34NPA@mail.gmail.com  

commit   : 9dce6b5a42bbf97721bd0aeef28688745e77e82f    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 12:00:36 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 12:00:36 +0900    

We have been using NRM_SUBSET to process NestLoopParams in setrefs.c,  
because Vars or PHVs in NestLoopParam expressions may previously have  
had nullingrels that were just subsets of those in the Vars or PHVs  
actually available from the outer side.  
  
Since 66e9df9f6, identify_current_nestloop_params ensures that any  
Vars or PHVs seen in a NestLoopParam expression have nullingrels that  
include exactly the outer-join relids that appear in the outer side's  
output and can null the respective Var or PHV.  As noted in that  
commit's message, we can now safely use NRM_EQUAL to process  
NestLoopParams in setrefs.c.  
  
This patch makes that change and removes the definition of NRM_SUBSET,  
along with all remaining checks for it, since it is no longer used.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs482_DFHzQ079ZPp6c8UvmFdz3Jj+4K8tVRu9g2Bw34NPA@mail.gmail.com  

commit   : e6e08dc5543485c7f4851551e67a99b0cf8027eb    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:20:15 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:20:15 -0700    

Discussion: https://postgr.es/m/20260630012919.78@rfd.leadboat.com  
Backpatch-through: 19  

commit   : dbbeafe61ad049c8881aa82575ecf3e89d707ce3    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:20:06 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:20:06 -0700    

Necessary for 16-bit wchar_t platforms (Windows).  
  
Other guards are just defensive. Also correct style issue with  
branches.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260630012919.78@rfd.leadboat.com  
Backpatch-through: 19  

commit   : 3ab2abc9494dde30dbdfe9eeb7c96a63128941ae    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:19:59 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:19:59 -0700    

Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260630012919.78@rfd.leadboat.com  
Backpatch-through: 19  

commit   : d34ce773d2d3bd891e2725ec4d4b94f1195e52cf    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:04:33 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 18:04:33 -0700    

Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20260630012919.78@rfd.leadboat.com  
Backpatch-through: 19  

commit   : 906b1e4a19a59612deb144ff6018cb048f7d73f8    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 09:38:31 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 09:38:31 +0900    

Previously, examine_simple_variable() would return early when a  
subquery or CTE used GROUP BY or DISTINCT.  It could detect uniqueness  
for single-column cases, but for multi-column GROUP BY or DISTINCT,  
selectivity estimation fell back on 1/DEFAULT_NUM_DISTINCT (1/200).  
This produced wildly inaccurate estimates for filters and joins on  
such columns, often leading the planner to choose nested loop joins  
where hash joins would be far better.  This was a significant factor  
in poor TPC-DS benchmark performance.  
  
For DISTINCT or GROUP BY key columns that are simple Vars, we now  
recurse into the subquery to obtain the base table's stadistinct,  
which remains valid after grouping (the set of distinct values is  
preserved).  However, MCV frequencies, histograms, and correlation  
data are not valid because GROUP BY and DISTINCT change the frequency  
distribution of key columns.  So we strip all stats slots from the  
copied stats tuple, causing callers like var_eq_const() to use the  
1/ndistinct estimate instead.  If stadistinct is stored as a negative  
value (a fraction of the base table's row count), we convert it to an  
absolute count so it is not misinterpreted relative to the subquery's  
output row count.  
  
stanullfrac is adjusted too, since grouping collapses NULLs.  For a  
single grouping key, at most one NULL group survives, so the null  
fraction is 1/(ndistinct+1).  For multiple grouping keys the null  
fraction depends on the joint distribution of the keys, which we don't  
have, so we approximate it as zero; NULLs collapse far more  
aggressively than non-NULLs, so the real fraction is well below the  
base table's, and erring low keeps estimates on the hash-join-favoring  
side.  
  
Non-key columns (e.g., aggregate outputs) continue to get no stats,  
same as before.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49rWYrecgreDhKsfx3VSDW=qo35s+iAmgGu=wpARrM8_g@mail.gmail.com  

commit   : 0237f1480a0d618f60d8dd4eca097e99aa7256d9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 09:04:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2026 09:04:31 +0900    

Commit dcb00495236 accidentally changed the final expanded query's  
condition to > 2 while rewriting the example into SQL operator notation.  
  
The original query and the preceding rewritten forms all use >= 2,  
and view expansion should preserve that qualification. This commit  
changes the final condition from > 2 to >= 2.  
  
Backpatch to all supported versions.  
  
Reported-by: Yaroslav Saburov <y.saburov@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/178248467618.108999.9966122434342474006@wrigleys.postgresql.org  
Backpatch-through: 14  

commit   : 96ab9a990eed2265c6b073646d1566a1dd2bd3f7    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 08:46:43 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 8 Jul 2026 08:46:43 +0900    

If an expression containing an aggregate is evaluated above the plan  
node that computes the aggregate, as happens with window functions or  
with expressions postponed to above the final sort, setrefs.c replaces  
the Aggref or WindowFunc with a Var referencing the lower node's  
output.  For SQL/JSON aggregates such as JSON_ARRAYAGG and  
JSON_OBJECTAGG, deparsing the containing JsonConstructorExpr then  
failed with "invalid JsonConstructorExpr underlying node type", since  
get_json_agg_constructor() did not expect a Var there.  
  
Fix by resolving the Var back to the underlying Aggref or WindowFunc  
and deparsing the constructor as if the aggregate were computed at the  
current node.  The JsonConstructorExpr retains the RETURNING clause  
and the ABSENT/NULL ON NULL and WITH UNIQUE options, and the arguments  
come from the resolved aggregate, so the original JSON aggregate  
syntax is reproduced in full.  This mirrors how get_agg_expr() already  
looks through such a Var when deparsing a combining aggregate.  
  
Reported-by: Thom Brown <thom@linux.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAA-aLv5QYTaMOk=Qhv6cgwceeHETZV8YJvWZ_rH+yVZCuchATA@mail.gmail.com  
Backpatch-through: 16  

commit   : 07211f64ace0150c92a00769a1cfe8b9305b9e78    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 15:23:54 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 15:23:54 -0700    

Errors at this point are not expected, but if encountered, signal to  
the caller so it can raise the appropriate error.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/c355354e6c3f4a7aafb047361b73db247260fca0.camel@j-davis.com  

commit   : 7258c891d4cabd366e4529484f2ad6e99234db48    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 01:16:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 01:16:24 +0300    

heapam_tuple_complete_speculative() fetched a tuple from the slot only  
to free it immediately afterwards, without ever using it.  
  
The function only needs slot->tts_tid to complete or abort the  
speculative insertion, so remove the unnecessary fetch and pfree().  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Surya Poondla <suryapoondla4@gmail.com>  
Discussion: https://www.postgresql.org/message-id/FCB61654-575D-4F08-AA7E-ED462EDE48A7@gmail.com  

commit   : 36869368989ce37d85c08c33258eb01ae96e2375    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 14:29:15 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 14:29:15 -0700    

If the string is preceded only by Case Ignorable characters, don't  
consider it to be a final sigma.  
  
In the process, refactor so that the preceding and following  
characters are found first, and then the rule is applied, to improve  
clarity.  
  
Discussion: https://postgr.es/m/c355354e6c3f4a7aafb047361b73db247260fca0.camel@j-davis.com  
Backpatch-through: 18  

commit   : 99319edb8f5e9c4363ac79088e58a70570d728bb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 00:25:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2026 00:25:24 +0300    

Replace the metapage sanity checks in _bt_gettrueroot() with a call to  
_bt_getmeta(), which does exactly the same checks.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Neil Chen <carpenter.nail.cz@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAEoWx2nisjqs4iC9o4Hu7-Ab767=cMZZzmhBGb8SaQtMMmVqPQ@mail.gmail.com  

commit   : 21ffc271d475a31dbc67706fc1f2a2c5bfc83e14    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 13:34:55 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Jul 2026 13:34:55 -0700    

Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/c355354e6c3f4a7aafb047361b73db247260fca0.camel@j-davis.com  
Backpatch-through: 17  

commit   : 6f7199a1245cab986a13c7b57812255fe77679d1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 22:32:36 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 22:32:36 +0300    

Make it explicit in the docs that the shmem initialization callbacks  
are called while holding ShmemIndexLock.  
  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAExHW5sHs+eSiTDOd14buayc6JbBX=Hm5ssFMBK0Ki9sTGEOuA@mail.gmail.com  
Backpatch-through: 19  

commit   : 9c9ddf109bd8d73660ff3fef317f95bc1d7d6cc5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 21:21:16 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 21:21:16 +0300    

GiST index killitems feature misbehaves for single-page GiST index,  
i.e. one that has only a root page. This is caused by the GiST scan's  
curBlkno variable not being initialized for the first-to-scan page,  
which is the root page.  Fix this by moving the initializing of  
curBlkno into gistScanPage(), where we also set the related curPageLSN  
variable.  
  
Commit 377b7ab145 actually added a regression test for this already,  
but it merely noted that it's not working and memorized the result  
where the items were not killed. Now they are, as the test shows.  
  
This has been broken all along, but since it's just a very minor  
performance issue on tiny tables, I didn't bother backpatching it.  
  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com>  
Discussion: https://postgr.es/m/CALdSSPgZWX_D8%2BFx4YQqRN5eW5iSx_rJdqQhCfdWTvqKXVfJ4w%40mail.gmail.com  
Discussion: https://postgr.es/m/lxzj26ga6ippdeunz6kuncectr5gfuugmm2ry22qu6hcx6oid6@lzx3sjsqhmt6  

commit   : 650bb73c137ccdea3a502775e08482731cc799ba    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 20:05:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 20:05:56 +0300    

Only "tombstone" files (first segment of main fork) are unlinked after  
checkpoints, so rename the function and remove the extra arguments to  
make that more clear.  
  
Additionally, add an assertion in mdunlinkfiletag() that the FileTag  
only contains expected values.  
  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAEze2WjfP95SL_Hsu7GzYXLnQyEsT49zOnNvbY_mBLCFiQra1g@mail.gmail.com  

commit   : 592de8bd21e177229eeef51cb474ccfc2070c65d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 7 Jul 2026 09:51:04 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 7 Jul 2026 09:51:04 -0700    

Adding a GRANT caused pg_dump to emit a useless REVOKE + GRANT of owner  
privileges, as seen in a dump of the regression database:  
  
  REVOKE ALL ON PROPERTY GRAPH graph_rls_schema.cabinet FROM nm;  
  GRANT ALL ON PROPERTY GRAPH graph_rls_schema.cabinet TO nm;  
  GRANT ALL ON PROPERTY GRAPH graph_rls_schema.cabinet TO PUBLIC;  
  
For normal dumps, this has no functional consequences.  For --no-owner  
restores, the extra statements may fail or locate unrelated users of the  
destination cluster.  
  
The problem was pg_dump assuming NULL relacl implies acldefault('r'),  
the default for TABLE.  Fix by teaching acldefault() to retrieve the  
PROPERTY GRAPH default ACL.  So pg_dump can still dump from 19beta1, use  
acldefault('g') for v20+ only.  For v19, use a hard-coded snapshot of  
the v19 default.  
  
information_schema.pg_property_graph_privileges also misused  
acldefault('r'), but its "c.prtype IN ('SELECT')" predicate compensated  
for it.  Switch to the new acldefault('g') for clarity.  Bump catversion  
since a new view won't work with old binaries.  Back-patch to v19, which  
introduced PROPERTY GRAPH.  
  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20260630023308.c7.noahmisch@microsoft.com  
Backpatch-through: 19  

commit   : b34fd845e03aea7401d3bf403c87e171d10f7709    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 7 Jul 2026 10:57:48 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 7 Jul 2026 10:57:48 -0500    

This commit cleans up volatile qualifiers that fit the below  
criteria:  
  
* Accesses to shared memory protected by a spinlock or LWLock.  
Before commit 0709b7ee72, callers had to use volatile when  
accessing spinlock-protected shared memory.  Since spinlock  
acquire/release became compiler barriers, and because LWLocks  
provide the same guarantee, that is no longer necessary.  These  
either predate that change or were cargo-culted from code that did.  
  
* Pointers used only to find the address of a member.  The volatile  
qualifier only affects accesses made by dereferencing the pointer,  
so it is unnecessary there.  
  
* Accesses to struct members that are marked volatile in the struct  
definition.  There's no need to mark these pointers volatile,  
either.  
  
* Leftovers from removed PG_TRY blocks.  These were marked volatile  
to protect a value that is modified inside a PG_TRY block, but the  
PG_TRY has since been removed.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://postgr.es/m/akQ5eJR1tCCXme8e%40nathan  

commit   : 343594a26d37522efdbae5fe5de13e19ccf2fa72    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:37 +0300    

The previous commit strengthened a workaround for a hang when large  
messages are split across TLS records/GSS tokens. Because that  
workaround is implemented in libpq internals, it can only help us when  
libpq itself is polling on the socket. In nonblocking situations,  
where the client above libpq is expected to poll, the same bugs can  
show up.  
  
As a contrived example, consider a large protocol-2.0 error coming  
back from a server during PQconnectPoll(), split in an odd way across  
two records:  
  
    -- TLS record (8192-byte payload) --  
    EEEE[...repeated a total of 8192 times]  
    -- TLS record (8193-byte payload) --  
    EEEE[...repeated a total of 8192 times]\0  
  
The first record will fill the first half of the libpq receive buffer,  
which is 16k long by default. The second record completely fills the  
last half with its first 8192 bytes, leaving the terminating NULL in  
the OpenSSL buffer. Since we still haven't seen the terminator at our  
level, PQconnectPoll() will return PGRES_POLLING_READING, expecting to  
come back when the server has sent "the rest" of the data.  But there  
is nothing left to read from the socket; OpenSSL had to pull all of  
the data in the 8193-byte record off of the wire to decrypt it.  
  
A real server would probably not split up the records this way, nor  
keep the connection open after sending a fatal connection error. But  
servers that regularly use larger TLS records can get the libpq  
receive buffer into the same state if DataRows are big enough, as  
reported on the list. While the PostgreSQL server doesn't use larger  
TLS records like that, other non-PostgreSQL servers that implement the  
wire protocol are known to do that, as well as proxies that sit  
between the server and the client  
  
This is a layering violation. libpq makes decisions based on data in  
the application buffer, above the transport buffer (whether SSL or  
GSS), but clients are polling the socket below the transport buffer.  
One way to fix this in a backportable way, without changing APIs too  
much, is to ensure data never stays in the transport buffer. Then  
pqReadData's postconditions will look similar for both raw sockets and  
SSL/GSS: any available data is either in the application buffer, or  
still on the socket.  
  
Building on the prior commit, make pqReadData() to drain all pending  
data from the transport layer into conn->inBuffer, expanding the  
buffer as necessary. This is not particularly efficient from an  
architectural perspective (the pqsecure_read() implementations take  
care to fit their packets into the current buffer, and that effort is  
now completely discarded), but it's hopefully easier to reason about  
than a full rewrite would be for the back branches.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Reviewed-by: solai v <solai.cdac@gmail.com>  
Reported-by: Lars Kanis <lars@greiz-reinsdorf.de>  
Discussion: https://postgr.es/m/2039ac58-d3e0-434b-ac1a-2a987f3b4cb1%40greiz-reinsdorf.de  
Backpatch-through: 14  

commit   : ffd080d94fe7154940a1bdac005390d0aee034bc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:45:34 +0300    

An extra check for pending bytes in the SSL layer has been part of  
pqReadReady() for a very long time (79ff2e96d). But when GSS transport  
encryption was added, it didn't receive the same treatment. (As  
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally  
hard to reproduce reliably.")  
  
Without that check, it's possible to hit a hang in gssencmode, if the  
server splits a large libpq message such that the final message in a  
streamed response is part of the same wrapped token as the split  
message:  
  
    DataRowDataRowDataRowDataRowDataRowData  
    -- token boundary --  
    RowDataRowCommandCompleteReadyForQuery  
  
If the split message takes up enough memory to nearly fill libpq's  
receive buffer, libpq may return from pqReadData() before the later  
messages are pulled out of the PqGSSRecvBuffer. Without additional  
socket activity from the server, pqReadReady() (via pqSocketCheck())  
will never again return true, hanging the connection.  
  
Pull the pending-bytes check into the pqsecure API layer, where both  
SSL and GSS now implement it.  
  
Note that this does not fix the root problem! Third party clients of  
libpq have no way to call pqsecure_read_is_pending() in their own  
polling. This just brings the GSS implementation up to par with the  
existing SSL workaround; a broader fix is left to a subsequent commit.  
  
In preparation for the broader fix, this patch already changes the  
*_read_pending() functions to return the number of bytes in the buffer  
rather than just a boolean. The current callers don't need that, but  
the subsequent fix will.  
  
Author: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com  
Backpatch-through: 14  

commit   : b9df8d5b8e4f58ef81e6b592278207889863c367    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 7 Jul 2026 17:34:58 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 7 Jul 2026 17:34:58 +0200    

Three error messages were using the default file name pg_hosts.conf  
and not the variable backing the GUC, which would make logging be  
confusing for users who have renamed the file using the GUC.  Fix  
by consistently using the HostsFileName variable.  
  
Backpatch down to v19 where serverside SNI was introduced.  
  
Author: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Surya Poondla <suryapoondla4@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAN4CZFMARYjQfgyRaCKOXDO=Q91kuKn=pSC02DAOOr23ojhEGQ@mail.gmail.com  
Backpatch-through: 19  

commit   : 75e201bf95d8825f1c025792eed0f13d65657c5d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:11:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2026 18:11:28 +0300    

ParallelBackupStart() stored _beginthreadex()'s return value as the  
worker's thread handle without checking it.  On failure that value is 0,  
which would later reach WaitForMultipleObjects() as a null handle, caught  
only by an Assert.  The fork() path already calls pg_fatal() when it  
fails; do the same for _beginthreadex(), as pgbench does.  
  
Author: Bryan Green <dbryan.green@gmail.com>  
Discussion: https://www.postgresql.org/message-id/8c712d76-ecf7-4749-a6d8-dddc01f298ec@gmail.com  
Backpatch-through: 14  

commit   : 9762809448b42d841ec09bf17db72ff769ac8b79    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 7 Jul 2026 15:55:24 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 7 Jul 2026 15:55:24 +0200    

The reference page for CREATE PROCEDURE had a See Also reference to  
CREATE FUNCTION, but the inverse was missing.  
  
Author: Jian He <jian.universality@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/CACJufxFTi3ceVRJqWRr3L8GR5q+ZhPCZw=1aDTaBGS1AugweFw@mail.gmail.com  

commit   : d007800f02a7b9fe3ca984a1b870405657d990ed    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 7 Jul 2026 23:57:45 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 7 Jul 2026 23:57:45 +1200    

9d9c02ccd added code to allow the executor to stop early when processing  
WindowAgg nodes where a monotonic window function starts producing  
values that result in a pushed-down qual no longer matching, and will  
never match again due to the window function's monotonic properties.  
  
That commit requires a SupportRequestWFuncMonotonic to exist on the  
window function and for it to detect when the function is monotonic.  For  
COUNT(ANY) and COUNT(*), the support function failed to consider some  
cases where the WindowClause used EXCLUDE to exclude certain rows from  
being aggregated.  Some WindowClause definitions mean we aggregate rows  
that come after the current row, and when processing those rows later,  
if we EXCLUDE certain rows, the monotonic property can be broken.  
Wrongly treating the COUNT(*) or COUNT(ANY) aggregate as monotonic could  
lead to rows being filtered that should not be filtered from the result  
set.  
  
Another issue was that the support function for the COUNT aggregate  
mistakenly thought that a WindowClause without an ORDER BY meant that  
the results would be both monotonically increasing and decreasing, but  
that's only true when in RANGE mode, where all rows are peers.  
  
It is possible to support various cases that do have an EXCLUDE clause,  
but getting the logic correct for the exact set of cases that are valid  
is quite complex and would likely better be left for a future project.  
  
Here, we mostly disable run condition pushdown when there is an EXCLUDE  
clause unless the clause is for EXCLUDE CURRENT ROW, uses COUNT(*)  
(rather than COUNT(ANY)), and the window aggregate has no FILTER clause.  
  
Bug: #19533  
Reported-by: Qifan Liu <imchifan@163.com>  
Author: Chengpeng Yan <chengpeng_yan@outlook.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Discussion: https://postgr.es/m/19533-413a1014e5d0e766@postgresql.org  
Backpatch-through: 15  

commit   : c22d2f7fd46c692c83152773387be6b731c1a4b9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2026 11:50:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2026 11:50:22 +0200    

This was the dominant style already, but some places used %llu  
instead.  Since off_t/pgoff_t are signed types, using %lld seems a  
better match, and it might handle obscure error conditions with  
negative values better.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/20ce62fa-47fc-457b-b504-12f3c1651726%40eisentraut.org  

commit   : 04fc2564fbbabe97cadbf782e8d40b8e3f7b22a5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2026 11:45:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2026 11:45:09 +0200    

pgoff_t is most likely a 64-bit integer, so casting it to a 32-bit  
type for output could lose data.  In the cases addressed here, the  
files cannot actually get that large, so this is only cosmetic and to  
set better examples for the future.  (Similar issues that could have  
actual practical impact were addressed separately in commit  
e8f851d6172.)  
  
In one case, the 32-bit size is baked into the protocol, so here we  
add an elog and document this discrepancy.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/20ce62fa-47fc-457b-b504-12f3c1651726%40eisentraut.org  

commit   : bb4142fb68cfab35b7c5f8db7645196c50662631    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 7 Jul 2026 18:40:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 7 Jul 2026 18:40:00 +0900    

Commit 28972b6fc should have done this, but didn't.  
  
While at it, remove an extra blank line in fetch_remote_statistics()  
introduced by that commit.  
  
Reported-by: Chao Li <lic@highgo.com>  
Co-authored-by: Chao Li <lic@highgo.com>  
Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/6ED81190-B398-44C9-A1E9-8EFE4ED183AF%40gmail.com  
Backpatch-through: 19  

commit   : 2ce74583652fb4cd29299a220ff31043adf5c96e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2026 08:37:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2026 08:37:15 +0200    

When GROUP BY ALL was added in commit ef38a4d9756, the SQL standard  
working draft was silent on what to do with window functions.  This  
has now been fixed in the SQL standard working draft.  Update the  
documentation and code comments about that.  
  
Also make the documentation more specific that we are only talking  
about aggregate functions referring to the same query level, which is  
another thing that has been made more precise in the SQL standard  
working draft since.  
  
The PostgreSQL implementation was already doing the right thing for  
both aspects, so no functionality changes.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/CAHM0NXjz0kDwtzoe-fnHAqPB1qA8_VJN0XAmCgUZ%2BiPnvP5LbA%40mail.gmail.com  

commit   : 4c75cc786301886145bc1a450977cbd024814ef5    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Tue, 7 Jul 2026 08:14:04 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Tue, 7 Jul 2026 08:14:04 +0900    

transformJsonBehavior() coerced an ON EMPTY / ON ERROR DEFAULT  
expression only when its type differed from the RETURNING type's OID.  
When the base type matched but the RETURNING type carried a type  
modifier (e.g. numeric(4,1) or varchar(3)), the coercion that enforces  
the typmod was skipped, so the DEFAULT value could violate the  
declared type:  
  
    SELECT JSON_VALUE(jsonb '{}', '$.a'  
                      RETURNING numeric(4,1) DEFAULT 99999.999 ON EMPTY);  
  
returned 99999.999, which 99999.999::numeric(4,1) would reject; the  
value could even be stored into a numeric(4,1) column, as later  
coercions trust its already-correct type label.  
  
Fix by also coercing when the RETURNING type has a typmod, except for  
a NULL constant.  coerce_to_target_type() is a no-op when the typmod  
already matches.  The matching-OID short-circuit dates to 74c96699be3.  
  
Reported-by: Ewan Young <kdbase.hack@gmail.com>  
Author: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://postgr.es/m/CAON2xHPO9f4cAmyGn1mQ=VqoS7wN5rz4yOiqudxX78zninZpCw@mail.gmail.com  
Backpatch-through: 17  

commit   : 4c84545067822bcc8697b7d8f3082c5cf1937d1b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jul 2026 15:34:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jul 2026 15:34:12 -0400    

We forgot to use the PG_MODULE_MAGIC_EXT in some newly added modules:  
pg_plan_advice, pg_stash_advice and the pgrepack output plugin and  
instead used the older PG_MODULE_MAGIC macro.  
  
Author: Andreas Karlsson <andreas@proxel.se>  
Discussion: http://postgr.es/m/ad7b910c-d145-4120-994d-2e55c456aa75@proxel.se  
Backpatch-through: 19  

commit   : 42b7ff3aaefa5f63b4890679a283f83f1a4acb00    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2026 14:47:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2026 14:47:58 -0400    

The loop in MatchText() processed a leading '\' without regard to  
nondeterministic locales, which is problematic if what the '\'  
precedes is an ordinary character that should be subject to  
nondeterministic matching.  We'd insist on a literal match for it,  
which is not right and is not like what happens with a '\' that  
follows some ordinary characters.  Worse, we'd then advance the text  
and pattern pointers by one byte, so that if the escaped character  
is multibyte the next loop iteration would take the nondeterministic  
code path starting at a point within the character.  That could very  
possibly cause pg_strncoll() to misbehave.  
  
The fix is quite simple: move the stanza that handles '\' down past  
the one that handles nondeterminism.  The stanzas for '%' and '_'  
are fine where they are, but the '\' stanza is only correct for  
deterministic matching.  The logic for nondeterministic cases is  
already prepared to do the right things with a '\'.  
  
While here, I replaced tests of "locale && !locale->deterministic"  
with a boolean local variable, reasoning that those are in the hot  
loop paths so saving a branch and indirect fetch is worth the  
trouble.  I also improved a number of related comments.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/391592.1783187986@sss.pgh.pa.us  
Backpatch-through: 18  

commit   : d6ffcae32a10bd9b53fcfe7be507ba00c6083acc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2026 14:35:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2026 14:35:21 -0400    

Commit 85b7efa1c added support for LIKE with nondeterministic  
collations, but it included a bug in the de-escaping logic for  
literal pattern substrings.  That unconditionally skipped all  
backslashes, but when it encounters '\\' it should emit the second  
backslash as a de-escaped character.  That led to acting as though  
the escaped backslash was not there.  
  
Bug: #19474  
Reported-by: Bowen Shi <zxwsbg12138@gmail.com>  
Author: Nitin Motiani <nitinmotiani@google.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19474-5b86a95f3d9a7ecb@postgresql.org  
Discussion: https://postgr.es/m/CAH5HC94yU+K8Gcdy12M5BS8gwD_SXLSHzc9k5tNk7JDnpBiFMA@mail.gmail.com  
Backpatch-through: 18  

commit   : 431896a84eb127b4fe1b609a56c67e28105136c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2026 13:48:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2026 13:48:42 -0400