PostgreSQL 18.0 (upcoming) commit log

commit   : f20a347e1a613cfc9053e7bc3d254608ae968386    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Jun 2025 10:20:14 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Jun 2025 10:20:14 -0400    

Reported-by: Antonin Houska <ah@cybertec.at>  
Author: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/5250.1751266701@localhost  
Backpatch-through: 18, where da7226993fd4 introduced this  

commit   : c3e28e9fd936b83dbb6dfb5003b6221d98f8469c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Jun 2025 09:49:31 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Jun 2025 09:49:31 -0400    

If the method is called in scalar context and we didn't pass in a stderr  
handle, one won't be created. However, some error paths assume that it  
exists, so in this case create a dummy stderr to avoid the resulting  
perl error.  
  
Per gripe from Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> and  
adapted from his patch.  
  
Discussion: https://postgr.es/m/378eac5de4b8ecb5be7bcdf2db9d2c4d@postgrespro.ru  

commit   : 40a96cd1484fdf3ab57e8cb7b09767ec7a7f73b1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:23:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:23:33 +0200    

Python's subprocess.run docs say that if the env argument is not None,  
it will be used "instead of the default behavior of inheriting the  
current process’ environment".  However, the environment should be  
preserved, only adding FLEX_TMP_DIR to it.  
  
Author: Javier Maestro <jjmaestro@ieee.org>  
Discussion: https://www.postgresql.org/message-id/flat/CABvji06GUpmrTqqiCr6_F9vRL2-JUSVAh8ChgWa6k47FUCvYmA%40mail.gmail.com  

commit   : cc2ac0e6f99e4efc3ae5710010ff35e646990a60    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:00:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:00:00 +0200    

Author: Aleksander Alekseev <aleksander@timescale.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAJ7c6TOowVbR-0NEvvDm6a_mag18krR0XJ2FKrc9DHXj7hFRtQ%40mail.gmail.com  

commit   : a6a4641252ed166ba187d7fbe0504ddb5a5f0e33    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:38:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:38:18 +0200    

commit   : a4c10de9291291bce3dd2b81bd8b5f0b98649244    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Jun 2025 18:36:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Jun 2025 18:36:24 +0900    

Previously, tab completion for COPY only suggested plain tables  
and partitioned tables, even though materialized views are also  
valid for COPY TO (since commit 534874fac0b), and foreign tables  
are valid for COPY FROM.  
  
This commit enhances tab completion for COPY to also include  
materialized views and foreign tables.  
  
Views with INSTEAD OF INSERT triggers are supported with  
COPY FROM but rarely used, so plain views are intentionally  
excluded from completion.  
  
Author: jian he <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CACJufxFxnSkikp+GormAGHcMTX1YH2HRXW1+3dJM9w7yY9hdsg@mail.gmail.com  

commit   : 960135114629bc89da0dd1d839541098c7e6401a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:28:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:28:11 +0200    

It was quite hard to guess what leaf_fragmentation meant without looking  
at pgstattuple's code.  This patch aims to give to the user a better  
idea of what it means.  
  
Author: Frédéric Yhuel <frederic.yhuel@dalibo.com>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Benoit Lobréau <benoit.lobreau@dalibo.com>  
Discussion: https://postgr.es/m/bf110561-f774-4957-a890-bb6fab6804e0%40dalibo.com  
Discussion: https://postgr.es/m/4c5dee3a-8381-4e0f-b882-d1bd950e8972@dalibo.com  

commit   : 3431e3e4aa3a33e8411f15e76c284cdd4c54ca28    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:45:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:45:08 +0200    

Run program_XXX tests instead of its own tests.  This ensures  
consistency with the test suites of other programs and enforces common  
policies, such as help line length.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://www.postgresql.org/message-id/flat/OSCPR01MB14966247015B7E3D8D340D022F56FA@OSCPR01MB14966.jpnprd01.prod.outlook.com  

commit   : 2e640a0fa224e4233220252b360efd33c98b3e90    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:32:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:32:26 +0200    

When postfix operators where dropped in 1ed6b8956, the CREATE OPERATOR  
docs were not updated to make the RIGHTARG argument mandatory in the  
grammar.  
  
While at it, make the RIGHTARG docs more concise. Also, the operator  
docs were mentioning "infix" in the introduction, while using "binary"  
everywhere else.  
  
Author: Christoph Berg <myon@debian.org>  
Discussion: https://www.postgresql.org/message-id/flat/aAtpbnQphv4LWAye@msg.df7cb.de  

commit   : c5c4fbb4d482b87c2a6c90337f3b657b2d0002ca    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 30 Jun 2025 10:12:31 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 30 Jun 2025 10:12:31 +0200    

Commit 1546e17f9d0 accidentally misspelled additionally as  
additionaly.  Backpatch to v17 to match where the original  
commit was backpatched.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Backpatch-through: 17  

commit   : 2252fcd4276cfeabae8786ab7c5a421dd674743e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 15:42:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 15:42:50 +0900    

This commit refactors the vacuum routines that rely on VacuumParams,  
adding const markers where necessary to force a new policy in the code.  
This structure should not use a pointer as it may be used across  
multiple relations, and its contents should never be updated.  
vacuum_rel() stands as an exception as it touches the "index_cleanup"  
and "truncate" options.  
  
VacuumParams has been introduced in 0d831389749a, and 661643dedad9 has  
fixed a bug impacting VACUUM operating on multiple relations.  The  
changes done in tableam.h break ABI compatibility, so this commit can  
only happen on HEAD.  
  
Author: Shihao Zhong <zhong950419@gmail.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/CAGRkXqTo+aK=GTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw@mail.gmail.com  

commit   : 5ba00e175a4eaefa4dc38ea14c667bbeb13af305    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 13:56:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 13:56:31 +0900    

log_line_prefix is changed to include "%b", the backend type in the TAP  
test configuration.  %v and %x are removed from the CI configuration,  
with the format around %b changed.  
  
The lack of backend type in postgresql.conf set by Cluster.pm for the  
TAP test configuration was something that has been bugging me, beginning  
the discussion that has led to this change.  The change in the CI has  
come up during the discussion, to become consistent with pg_regress.c,  
%v and %x not being that useful to have.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aC0VaIWAXLgXcHVP@paquier.xyz  

commit   : 2652835d3efa003439ecc23d5fc3cf089c5952a6    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 22:28:10 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 22:28:10 -0400    

Let the hacking begin ...  

commit   : 9c5b9a280cb6089c011a01797868da83f97d0230    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 21:43:39 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 21:43:39 -0400    

Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta  
tasks specified by RELEASE_CHANGES.  For reference, the command was  
  
./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6300  
  
This should have been done prior to beta1, but it was forgotten. This  
will ensure we get the correct numbering for beta2 onward.  

commit   : 0ebd24255581837f9a5b189ef15147b769df116b    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 21:14:21 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 21:14:21 -0400    

This is required before the creation of a new branch.  pgindent is  
clean, as well as is reformat-dat-files.  
  
perltidy version is v20230309, as documented in pgindent's README.  

commit   : 66e9df9f6ef50719b25ca63b60aad934e14f4a1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Jun 2025 15:04:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Jun 2025 15:04:32 -0400    

In the wake of commit a16ef313f, we need to deal with more cases  
involving PlaceHolderVars in NestLoopParams than we did before.  
  
For one thing, a16ef313f was incorrect to suppose that we could  
rely on the required-outer relids of the lefthand path to decide  
placement of nestloop-parameter PHVs.  As Richard Guo argued at  
the time, we must look at the required-outer relids of the join  
path itself.  
  
For another, we have to apply replace_nestloop_params() to such  
a PHV's expression, in case it contains references to values that  
will be supplied from NestLoopParams of higher-level nestloops.  
  
For another, we need to be more careful about the phnullingrels  
of the PHV than we were being.  identify_current_nestloop_params  
only bothered to ensure that the phnullingrels didn't contain  
"too many" relids, but now it has to be exact, because setrefs.c  
will apply both NRM_SUBSET and NRM_SUPERSET checks in different  
places.  We can compute the correct relids by determining the  
set of outer joins that should be able to null the PHV and then  
subtracting whatever's been applied at or below this join.  
Do the same for plain Vars, too.  (This should make it possible  
to use NRM_EQUAL to process nestloop params in setrefs.c, but  
I won't risk making such a change in v18 now.)  
  
Lastly, if a nestloop parameter PHV was pulled up out of a subquery  
and it contains a subquery that was originally pushed down from this  
query level, then that will still be represented as a SubLink, because  
SS_process_sublinks won't recurse into outer PHVs, so it didn't get  
transformed during expression preprocessing in the subquery.  We can  
substitute the version of the PHV's expression appearing in its  
PlaceHolderInfo to ensure that that preprocessing has happened.  
(Seems like this processing sequence could stand to be redesigned,  
but again, late in v18 development is not the time for that.)  
  
It's not very clear to me why the old have_dangerous_phv join-order  
restriction prevented us from seeing the last three of these problems.  
But given the lack of field complaints, it must have done so.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18953-1c9883a9d4afeb30@postgresql.org  

commit   : 8319e5cb5493046e65d60da3cc17ab78c91749b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Jun 2025 13:56:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Jun 2025 13:56:03 -0400    

Sometimes a table's constraint may depend on a column of another  
table, so that we have to update the constraint when changing the  
referenced column's type.  We need to have lock on the constraint's  
table to do that.  ATPostAlterTypeCleanup believed that this case  
was only possible for FOREIGN KEY constraints, but it's wrong at  
least for CHECK and EXCLUDE constraints; and in general, we'd  
probably need exclusive lock to alter any sort of constraint.  
So just remove the contype check and acquire lock for any other  
table.  This prevents a "you don't have lock" assertion failure,  
though no ill effect is observed in production builds.  
  
We'll error out later anyway because we don't presently support  
physically altering column types within stored composite columns.  
But the catalog-munging is basically all there, so we may as well  
make that part work.  
  
Bug: #18970  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Diagnosed-by: jian he <jian.universality@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18970-a7d1cfe1f8d5d8d9@postgresql.org  
Backpatch-through: 13  

commit   : 6d12d5a433c9c8cbf92fc19afd2a3465f275564c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Jun 2025 17:02:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Jun 2025 17:02:35 +0200    

This commit renames the pg_recvlogical options --two-phase and  
--failover to --enable-two-phase and --enable-failover, respectively.  
The new names distinguish these enabling options from action options  
like --start and --create-slot, while clearly indicating their purpose  
to enable specific logical slot features.  
  
The option --failover is new in PostgreSQL 18 (commit cf2655a9029), so  
no compatibility break there.  The option --two-phase has existed  
since PostgreSQL 15 (commit cda03cfed6b), so for compatibility we keep  
the old option name --two-phase around as deprecated.  
  
Also note that pg_createsubscriber has acquired an --enable-two-phase  
option, so this increases consistency across tools.  
  
Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/a28f66df-1354-4709-8d63-932ded4cac35@eisentraut.org  

commit   : 50fd428b2b9cb036c9c5982b56443d7e28119707    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Jun 2025 19:18:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Jun 2025 19:18:06 +0200    

commit   : bbccf7ecb363e50ae9d9aa71d0e7c6d49ee0bb06    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 27 Jun 2025 13:37:26 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 27 Jun 2025 13:37:26 -0500    

This is purely cosmetic, as dsm_attach() interprets its argument as  
a dsm_handle (i.e., an unsigned integer), but we might as well fix  
it.  
  
Oversight in commit 4db3744f1f.  
  
Author: Jianghua Yang <yjhjstz@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAAZLFmRxkUD5jRs0W3K%3DUe4_ZS%2BRcAb0PCE1S0vVJBn3sWH2UQ%40mail.gmail.com  
Backpatch-through: 13  

commit   : 7195c804bd12f47a9f1b2df9c2e1794bb04c5987    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 27 Jun 2025 11:49:00 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 27 Jun 2025 11:49:00 +0300    

ca307d5cec90 made CheckPointReplicationSlots() unconditionally call  
ReplicationSlotsComputeRequiredLSN().  It causes an assertion trap when  
max_replication_slots equals 0.  This commit makes  
CheckPointReplicationSlots() call ReplicationSlotsComputeRequiredLSN() only  
when at least one slot gets its last_saved_restart_lsn updated.  That avoids  
an assert trap and also saves some cycles when no one slot has  
last_saved_restart_lsn updated.  
  
Based on ideas from Dilip Kumar <dilipbalaut@gmail.com> and  
Hayato Kuroda <kuroda.hayato@fujitsu.com>.  
  
Reported-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/OS0PR01MB5716BB506AF934376FF3A8BB947BA%40OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 94e2e150ec72a3b37e3847be99c4aca3320c38f9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Jun 2025 09:31:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Jun 2025 09:31:23 +0900    

binaryheap.c and stringinfo.c have been moved to src/common/ by  
respectively 5af0263afd7b and 26aaf97b683d, and the README patched here  
still mentioned these two files as available in src/backend/lib/.  
  
Author: Aleksander Alekseev <aleksander@timescale.com>  
Discussion: https://postgr.es/m/CAJ7c6TPg-=tC+fzq0tGTtmL7r79-aWeCmpwAyQiGu0N+sKGj8Q@mail.gmail.com  

commit   : 7fb3c38e7d7d12a742e1e7600879570251e1886a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jun 2025 22:13:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jun 2025 22:13:53 +0200    

commit   : 95e12d4d9b228855af8a2a34ca28c33924d4edd1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jun 2025 22:02:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jun 2025 22:02:16 +0200    

Commit 7d6d2c4bbd7 dropped opcintype from the index AM strategy  
translation API.  But some error messages about failed lookups still  
mentioned it, even though it was not used for the lookup.  Fix by  
removing ipcintype from the error messages as well.  

commit   : 483f7246f39b3af250fed1e613d962b85b568861    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:48 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:48 -0400    

8e03eb92e9a reverted the commit 39b66a91bd which allowed freezing  
in the heap_insert() code path but forgot to remove the corresponding  
check in heap_xlog_insert(). This code is extraneous but not harmful.  
However, cleaning it up makes it very clear that, as of now, we do not  
support any freezing of pages in the heap_insert() path.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/flat/CAAKRu_Zp4Pi-t51OFWm1YZ-cctDfBhHCMZ%3DEx6PKxv0o8y2GvA%40mail.gmail.com  
Backpatch-through: 14  

commit   : 060f420a03a8d8186423e7d64302b72e01365c20    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 14:25:45 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 14:25:45 -0400    

We can simplify the VM counters added in dc6acfd910b8 to  
lazy_vacuum_heap_page() and lazy_scan_new_or_empty().  
  
We won't invoke lazy_vacuum_heap_page() unless there are dead line  
pointers, so we know the page can't be all-visible.  
  
In lazy_scan_new_or_empty(), we only update the VM if the page-level  
hint PD_ALL_VISIBLE is clear, and the VM bit cannot be set if the page  
level bit is clear because a subsequent page update would fail to clear  
the visibility map bit.  
  
Simplify the logic for determining which log counters to increment based  
on this knowledge. Doing so is worthwhile because the old logic was  
confusing and misguided.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/flat/CAAKRu_a9w_n2mwY%3DG4LjfWTvRTJtjbfvnYAKi4WjO8QXHHrA0g%40mail.gmail.com  

commit   : a3994ec6acb27545300ce1e336e4d119d8000ba9    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 26 Jun 2025 18:33:48 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 26 Jun 2025 18:33:48 +0200    

Introduced by c2da1a5d6325  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aFt4qeRwrV-3qNix@paquier.xyz  

commit   : 48c80aba7538d7c515d0c89f4d11f88974fee851    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 26 Jun 2025 18:25:05 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 26 Jun 2025 18:25:05 +0200    

commit   : 47fb87563bf3cca2244840241dde2eb93830559b    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 26 Jun 2025 18:24:12 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 26 Jun 2025 18:24:12 +0200    

We were missing collecting comments for not-null constraints that are  
dumped inline with the table definition (i.e., valid ones), because they  
aren't represented by a separately dumpable object.  Fix by creating  
separate TocEntries for the comments.  
  
Co-Authored-By: Jian He <jian.universality@gmail.com>  
Co-Authored-By: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-By: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-By: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://postgr.es/m/d50ff977-c728-4e9e-8488-fc2688e08754@oss.nttdata.com  

commit   : 81ce602d48e8b9cbc3c3a7d5b9d9ddbea7789c02    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Jun 2025 20:25:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Jun 2025 20:25:34 +0900    

Commit 14e87ffa5c5 introduced support for adding comments to NOT NULL  
constraints. However, CREATE TABLE LIKE INCLUDING COMMENTS did not copy  
these comments to the new table. This was an oversight in that commit.  
  
This commit corrects the behavior by ensuring CREATE TABLE LIKE to also copy  
the comments on NOT NULL constraints when INCLUDING COMMENTS is specified.  
  
Author: Jian He <jian.universality@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/127debef-e558-4784-9e24-0d5eaf91e2d1@oss.nttdata.com  

commit   : 3ba9639e39ed8cf2d9dd30f6b8a3b3e9fffb9a64    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 10:13:00 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 10:13:00 +0100    

Fix a couple of sentences in the documentation that were missed in  
commit 80feb727c8.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/CAEZATCUcqADJuapZSjPf2b6hFJ6AGOUwefRvh8Ht3UZoqqw69Q@mail.gmail.com  

commit   : eca624c6591be14a1a03f0b2d374043cdf276431    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:36:05 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:36:05 +0100    

The convention in the documentation for other SQL commands is to  
indent continuation lines and sub-clauses in the "Synopsis" section by  
4 spaces, so do the same for MERGE.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/CAEZATCV+9tR9+WM-SCcdBEZ3x7WVxUpADD5jX9WeGX97z4LCGA@mail.gmail.com  
Backpatch-through: 15  

commit   : 5069fef1cfae271ca62e254b16dc831145bc5a4f    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 26 Jun 2025 12:17:12 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 26 Jun 2025 12:17:12 +0900    

For the subcommand ALTER COLUMN TYPE of the ALTER TABLE command, the  
USING expression may reference virtual generated columns.  These  
columns must be expanded before the expression is fed through  
expression_planner and the expression-execution machinery.  Failing to  
do so can result in incorrect rewrite decisions, and can also lead to  
"ERROR:  unexpected virtual generated column reference".  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/b5f96b24-ccac-47fd-9e20-14681b894f36@gmail.com  

commit   : 62a47aea1d8d8ea36e63fe6dd3d9891452a3f968    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Jun 2025 12:44:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Jun 2025 12:44:03 +0200    

Author: Robert Treat <rob@xzilla.net>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CACJufxFo4yTwzbSZrP%2BzQiR6_M00skoZMFaUnNJCdY6he%3DuQfA%40mail.gmail.com  

commit   : 60dda7bbc45f30e2ba50ecf20dfb9d944a589a38    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Jun 2025 10:33:23 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Jun 2025 10:33:23 +0200    

After discussion, the name --remove was suboptimally chosen.  --clean  
has more precedent in other PostgreSQL tools.  
  
Reviewed-by: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>  
Discussion: https://www.postgresql.org/message-id/84be7ff3-2763-4c0f-ac1e-ca9862077f41@eisentraut.org  

commit   : 0cd69b3d7ef357f2b43258de5831c4de0bd51dec    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Jun 2025 09:55:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Jun 2025 09:55:04 +0200    

Just like selecting from a view is exploitable (CVE-2024-7348),  
selecting from a table with virtual generated columns is exploitable.  
Users who are concerned about this can avoid selecting from views, but  
telling them to avoid selecting from tables is less practical.  
  
To address this, this changes it so that generation expressions for  
virtual generated columns are restricted to using built-in functions  
and types, and the columns are restricted to having a built-in type.  
We assume that built-in functions and types cannot be exploited for  
this purpose.  
  
In the future, this could be expanded by some new mechanism to declare  
other functions and types as safe or trusted for this purpose, but  
that is to be designed.  
  
(An alternative approach might have been to expand the  
restrict_nonsystem_relation_kind GUC to handle this, like the fix for  
CVE-2024-7348.  But that is kind of an ugly approach.  That fix had to  
fit in the constraints of fixing an ancient vulnerability in all  
branches.  Since virtual generated columns are new, we're free from  
the constraints of the past, and we can and should use cleaner  
options.)  
  
Reported-by: Feike Steenbergen <feikesteenbergen@gmail.com>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAK_s-G2Q7de8Q0qOYUR%3D_CTB5FzzVBm5iZjOp%2BmeVWpMpmfO0w%40mail.gmail.com  

commit   : 69e5cdc47fa1fbd97c8b8c7abe6fb0b9a9822acb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Jun 2025 10:25:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Jun 2025 10:25:15 +0530    

Protocol v4 introduces parallel streaming, which allows Stream Abort  
messages to include additional abort information such as LSN and  
timestamp. However, the current documentation only states, "This field is  
available since protocol version 4," which may misleadingly suggest that  
the fields are always present when using protocol v4.  
  
This patch clarifies that the abort LSN and timestamp are included only  
when parallel streaming is enabled, even under protocol v4.  
  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where it was introduced  
Discussion: https://postgr.es/m/CAO6_XqoKteQR1AnaR8iPcegbBE+HkAc2-g12rxN04yOt4-2ORg@mail.gmail.com  

commit   : 661643dedad97f8b924991fdc739b1f47b0fb60b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:46 +0900    

This fixes two issues with the handling of VacuumParams in vacuum_rel().  
This code path has the idea to change the passed-in pointer of  
VacuumParams for the "truncate" and "index_cleanup" options for the  
relation worked on, impacting the two following scenarios where  
incorrect options may be used because a VacuumParams pointer is shared  
across multiple relations:  
- Multiple relations in a single VACUUM command.  
- TOAST relations vacuumed with their main relation.  
  
The problem is avoided by providing to the two callers of vacuum_rel()  
copies of VacuumParams, before the pointer is updated for the "truncate"  
and "index_cleanup" options.  
  
The refactoring of the VACUUM option and parameters done in 0d831389749a  
did not introduce an issue, but it has encouraged the problem we are  
dealing with in this commit, with b84dbc8eb80b for "truncate" and  
a96c41feec6b for "index_cleanup" that have been added a couple of years  
after the initial refactoring.  HEAD will be improved with a different  
patch that hardens the uses of VacuumParams across the tree.  This  
cannot be backpatched as it introduces an ABI breakage.  
  
The backend portion of the patch has been authored by Nathan, while I  
have implemented the tests.  The tests rely on injection points to check  
the option values, making them faster, more reliable than the tests  
originally proposed by Shihao, and they also provide more coverage.  
This part can only be backpatched down to v17.  
  
Reported-by: Shihao Zhong <zhong950419@gmail.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAGRkXqTo+aK=GTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw@mail.gmail.com  
Backpatch-through: 13  

commit   : 82015fd9bdc0827c33245a0eef620f854d53b720    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jun 2025 09:02:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jun 2025 09:02:31 +0900    

The documentation previously described the type of the io_workers GUC  
parameter as "int". However, the documentation consistently uses "integer"  
for parameters of this type.  
  
This commit updates the type description of io_workers to "integer"  
for consistency with other GUC parameter descriptions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/e95c899a-2aeb-45b7-8fd3-7a27dcdb475b@oss.nttdata.com  

commit   : a9c2bde9295574fc79ce0dea1a2b481c8804c1a5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jun 2025 09:01:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jun 2025 09:01:13 +0900    

The documentation for track_cost_delay_timing describes where cost-based  
vacuum delay timing information is displayed when the setting is enabled.  
While this information is also shown in the output of ANALYZE VERBOSE,  
that was previously omitted from the list.  
  
This commit updates the documentation to include ANALYZE VERBOSE in the list,  
clarifying that it also reports cost-based delay timing information.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/e95c899a-2aeb-45b7-8fd3-7a27dcdb475b@oss.nttdata.com  

commit   : 84c4e10e130f411a89a2f9fd9184075ef02b0eaf    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jun 2025 08:59:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jun 2025 08:59:25 +0900    

For parameters that exist as both configuration and storage options,  
the documentation typically includes secondary index entries to  
help users distinguish and locate the relevant references easily.  
  
However, such index entries were missing for vacuum_truncate and  
vacuum_max_eager_freeze_failure_rate, both introduced in v18.  
  
This commit adds appropriate secondary index terms for these parameters  
to ensure consistency with other parameters and improve usability of  
the documentation index.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/e95c899a-2aeb-45b7-8fd3-7a27dcdb475b@oss.nttdata.com  

commit   : fd519419c9484a47f068cc04e2db81a4ec661669    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Jun 2025 14:14:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Jun 2025 14:14:04 -0400    

The logical replication launcher process would sometimes sleep  
for as much as 3 minutes before noticing that it is supposed  
to launch a new worker.  This could happen if  
(1) WaitForReplicationWorkerAttach absorbed a process latch wakeup  
that was meant to cause ApplyLauncherMain to do work, or  
(2) logicalrep_worker_launch reported failure, either because of  
resource limits or because the new worker terminated immediately.  
  
In case (2), the expected behavior is that we retry the launch after  
wal_retrieve_retry_interval, but that didn't reliably happen.  
  
It's not clear how often such conditions would occur in the field,  
but in our subscription test suite they are somewhat common,  
especially in tests that exercise cases that cause quick worker  
failure.  That causes the tests to take substantially longer than  
they ought to do on typical setups.  
  
To fix (1), make WaitForReplicationWorkerAttach re-set the latch  
before returning if it cleared it while looping.  To fix (2), ensure  
that we reduce wait_time to no more than wal_retrieve_retry_interval  
when logicalrep_worker_launch reports failure.  In passing, fix a  
couple of perhaps-hypothetical race conditions, e.g. examining  
worker->in_use without a lock.  
  
Backpatch to v16.  Problem (2) didn't exist before commit 5a3a95385  
because the previous code always set wait_time to  
wal_retrieve_retry_interval when launching a worker, regardless of  
success or failure of the launch.  That behavior also greatly  
mitigated problem (1), so I'm not excited about adapting the remainder  
of the patch to the substantially-different code in older branches.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/817604.1750723007@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : c2da1a5d6325a92d834c9cb036f65d362e4bfc3e    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 24 Jun 2025 19:36:32 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 24 Jun 2025 19:36:32 +0200    

Commit 62d712ecfd94 made query jumbling squash lists of Consts as a  
single element, but there's no reason not to treat PARAM_EXTERN  
parameters the same.  For these purposes, these values are indeed  
constants for any particular execution of a query.  
  
In particular, this should make list squashing more useful for  
applications using extended query protocol, which would use parameters  
extensively.  
  
A complication arises: if a query has both external parameters and  
squashable lists, then the parameter number used as placeholder for the  
squashed list might be inconsistent with regards to the parameter  
numbers used by the query literal.  To reduce the surprise factor, all  
parameters are renumbered starting from 1 in that case.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Author: Dmitry Dolgov <9erthalion6@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAA5RZ0tRXoPG2y6bMgBCWNDt0Tn=unRerbzYM=oW0syi1=C1OA@mail.gmail.com  

commit   : debad29d22152d7fe4c4e671090e20238647c460    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 24 Jun 2025 19:36:12 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 24 Jun 2025 19:36:12 +0200    

There's no principled reason for query jumbling to only remove the first  
layer of RelabelType and CoerceViaIO.  Change it to see through as many  
layers as there are.  

commit   : 303ba0573ce656b98620133cd17418dcd217318f    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Tue, 24 Jun 2025 09:20:16 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Tue, 24 Jun 2025 09:20:16 -0400    

If vacuum fails to prune a tuple killed before OldestXmin, it will  
decide to freeze its xmax and later error out in pre-freeze checks.  
  
Add a test reproducing this scenario to the recovery suite which creates  
a table on a primary, updates the table to generate dead tuples for  
vacuum, and then, during the vacuum, uses a replica to force  
GlobalVisState->maybe_needed on the primary to move backwards and  
precede the value of OldestXmin set at the beginning of vacuuming the  
table.  
  
This test is coverage for a case fixed in 83c39a1f7f3. The test was  
originally committed to master in aa607980aee but later reverted in  
efcbb76efe4 due to test instability.  
  
The test requires multiple index passes. In Postgres 17+, vacuum uses a  
TID store for the dead TIDs that is very space efficient. With the old  
minimum maintenance_work_mem of 1 MB, it required a large number of dead  
rows to generate enough dead TIDs to force multiple index  
vacuuming passes. Once the source code changes were made to allow a  
minimum maintenance_work_mem value of 64kB, the test could be made much  
faster and more stable.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAAKRu_ZJBkidusDut6i%3DbDCiXzJEp93GC1%2BNFaZt4eqanYF3Kw%40mail.gmail.com  
Backpatch-through: 17  

commit   : 054beebb7c9fb94ed17bda9381dbd204f32adf42    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 24 Jun 2025 11:49:37 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 24 Jun 2025 11:49:37 +0200    

The link returns 404 and no replacement is available in the project  
on Sourceforge where the content once was. Since we already link to  
resources for both beginner and experienced docs hackers, remove the  
the dead link.  
  
Backpatch to all supported versions as the link was added in 8.1.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Magnus Hagander <magnus@hagander.net>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reported-by: jian he <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CACJufxH=YzQPDOe+2WuYZ7seD-BOyjCBmP6JiErpoSiVZWDRnw@mail.gmail.com  
Backpatch-through: 13  

commit   : 49fe1c83ecf3474776ea9d0db47ae5644d29b67b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Jun 2025 11:30:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Jun 2025 11:30:49 +0200    

Virtual generated columns have some special checks in  
CheckAttributeType(), mainly to check that domains are not used.  But  
this check was only applied during CREATE TABLE, not during ALTER  
TABLE.  This fixes that.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CACJufxE0KHR__-h=zHXbhSNZXMMs4LYo4-dbj8H3YoStYBok1Q@mail.gmail.com  

commit   : 0cb5145a32c1a867a157e18493e24930338f5d6f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Jun 2025 14:21:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Jun 2025 14:21:10 +0900    

Previously, the UUID functions documentation defined the "UUID" index entry  
to link to the UUID data type page, even though that entry already exists there.  
Instead, the UUID functions page should define its own index entry linking  
to itself.  
  
This commit updates the UUID index entry in the UUID functions documentation  
to point to the correct section, improving navigation and avoiding duplication.  
  
Back-patch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/f33e0493-5773-4296-87c5-7ce459054cfe@oss.nttdata.com  
Backpatch-through: 13  

commit   : 6531f36283f05219464dd2084a17aab5747f7de8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jun 2025 09:51:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jun 2025 09:51:07 +0530    

Remove the part of comment that says we don't allow toggling two_phase  
option as that is supported in commit 1462aad2e4.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB1496656725F3951AEE8749EBDF579A@OSCPR01MB14966.jpnprd01.prod.outlook.com  

commit   : fc39b286ad7262a4aac8ff9a34f244763bed7a53    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Jun 2025 13:12:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Jun 2025 13:12:46 +0900    

\close has been introduced in d55322b0da60 to be able to close a  
prepared statement using the extended protocol in psql.  Per discussion,  
the name "close" is ambiguous.  At the SQL level, CLOSE is used to close  
a cursor.  At protocol level, the close message can be used to either  
close a statement or a portal.  
  
This patch renames \close to \close_prepared to avoid any ambiguity and  
make it clear that this is used to close a prepared statement.  This new  
name has been chosen based on the feedback from the author and the  
reviewers.  
  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://postgr.es/m/3e694442-0df5-4f92-a08f-c5d4c4346b85@eisentraut.org  

commit   : f3ed72ca0765bdd726a31b7fa20219e96baf312c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 23 Jun 2025 21:33:50 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 23 Jun 2025 21:33:50 +0300    

This new test was intended to check the handling of the replication slot's  
restart lsn fixed in ca307d5cec90.  However, it also reveals another issue  
related to logical decoding.  This commit temporarily removes this test to  
keep the buildfarm and CFbot green and avoid distorting others' work.  This  
test will be restored once we investigate and fix the issue.  
  
Discussion: https://postgr.es/m/CAAKRu_ZCOzQpEumLFgG_%2Biw3FTa%2BhJ4SRpxzaQBYxxM_ZAzWcA%40mail.gmail.com  

commit   : 70d8a91f82f19d270facd25bb6292a949773dfce    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 23 Jun 2025 21:27:42 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 23 Jun 2025 21:27:42 +0300    

ca307d5cec90 introduced keeping WAL segments by slot's last saved restart LSN.  
It also added an assertion that the slot's restart LSN never goes backward.  
However, situations when the restart LSN goes backward have been spotted by  
buildfarm animals and investigated in the thread.  
  
When pg_receivewal starts the replication, it sets the last replayed LSN to  
the beginning of the segment, which is older than what  
ReplicationSlotReserveWal() set for the slot.  A similar situation can happen  
to pg_basebackup.  When standby reconnects to the primary, it sends the last  
replayed LSN, which might be older than the last confirmed flush LSN.  In  
both these situations, a concurrent checkpoint may trigger an assert trap.  
  
Based on ideas from Vitaly Davydov <v.davydov@postgrespro.ru>,  
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>,  
Vignesh C <vignesh21@gmail.com>,  
Amit Kapila <amit.kapila16@gmail.com>.  
  
Reported-by: Vignesh C <vignesh21@gmail.com>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CALDaNm3s-jpQTe1MshsvQ8GO%3DTLj233JCdkQ7uZ6pwqRVpxAdw%40mail.gmail.com  
Reviewed-by: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  

commit   : ccd5bc93fdfeae22c935f405b0687be5cfa9caa4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Jun 2025 11:50:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Jun 2025 11:50:21 -0400    

Commit 43da39430 added a dependency on this intrinsic to our  
AVX-512 CRC code.  It turns out this intrinsic was added to  
gcc later than the other ones we were using, so that there  
are platforms where the new code fails to compile.  Since only  
relatively old (pre-gcc-10) compilers are affected, it doesn't  
seem worth trying to make the AVX-512 CRC code actually work  
on these platforms.  Just add the new intrinsic to the configure  
probe, so that we'll conclude the code can't be built.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/3350336.1750690281@sss.pgh.pa.us  

commit   : 43da394304fba820830da2cef2c0214fe292c037    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Mon, 23 Jun 2025 18:03:56 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Mon, 23 Jun 2025 18:03:56 +0700    

The problem that led to the workaround in f83f14881c7 was not in fact  
a compiler bug, but a failure to zero the upper bits of the vector  
register containing the initial scalar CRC value. Fix that and revert  
the workaround.  
  
Diagnosed-by: Nathan Bossart <nathandbossart@gmail.com>  
Diagnosed-by: Raghuveer Devulapalli <raghuveer.devulapalli@intel.com>  
Tested-by: Andy Fan <zhihuifan1213@163.com>  
Tested-by: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Raghuveer Devulapalli <raghuveer.devulapalli@intel.com>  
Discussion: https://postgr.es/m/PH8PR11MB82866B07AA6758D12F699C00FB70A@PH8PR11MB8286.namprd11.prod.outlook.com  

commit   : 2c0d8b95080e1d51c60d9c6f6a2e4460d6dfaf77    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 22 Jun 2025 14:13:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 22 Jun 2025 14:13:46 +0200    

    WARNING: You should add the boolean check kwarg to the run_command call.  
             It currently defaults to false,  
             but it will default to true in meson 2.0.  
  
Introduced by commit bc46104fc9a.  
  
(This only happens in the msvc branch.  All the other run_command  
calls are ok.)  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/flat/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org  

commit   : ea06263c4aa5abadc97a6928c6b2aff0e29698ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jun 2025 12:52:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jun 2025 12:52:37 -0400    

Specify whether the bucket bounds are inclusive or exclusive,  
and improve some other vague language.  Explain the behavior that  
occurs when the "low" bound is greater than the "high" bound.  
Make width_bucket_numeric's comment more like that for  
width_bucket_float8, in particular noting that infinite  
bounds are rejected (since they became possible in v14).  
  
Reported-by: Ben Peachey Higdon <bpeacheyhigdon@gmail.com>  
Author: Robert Treat <rob@xzilla.net>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/2BD74F86-5B89-4AC1-8F13-23CED3546AC1@gmail.com  
Backpatch-through: 13  

commit   : fa638edc74ee4be90e94a45f8489f3be9a926d7e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Jun 2025 23:53:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Jun 2025 23:53:15 -0400    

commit   : d21cf31f7c3f2657d9396913c5cea91f01a88105    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Jun 2025 23:37:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Jun 2025 23:37:30 -0400    

commit   : fed7aa8f56064e3e492c9e145a3197128d6abdf7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Jun 2025 22:44:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 20 Jun 2025 22:44:18 -0400    

commit   : a16ef313f2c21225e89ddb9168f30601f21c7d07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jun 2025 15:55:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jun 2025 15:55:12 -0400    

Commit 85e5e222b, which added (a forerunner of) this logic,  
argued that  
  
    Adding the necessary complexity to make this work doesn't seem like  
    it would be repaid in significantly better plans, because in cases  
    where such a PHV exists, there is probably a corresponding join order  
    constraint that would allow a good plan to be found without using the  
    star-schema exception.  
  
The flaw in this claim is that there may be other join-order  
restrictions that prevent us from finding a join order that doesn't  
involve a "dangerous" PHV.  In particular we now recognize that  
small join_collapse_limit or from_collapse_limit could prevent it.  
Therefore, let's bite the bullet and make the case work.  
  
We don't have to extend the executor's support for nestloop parameters  
as I thought at the time, because we can instead push the evaluation  
of the placeholder's expression into the left-hand input of the  
NestLoop node.  So there's not really a lot of downside to this  
solution, and giving the planner more join-order flexibility should  
have value beyond just avoiding failure.  
  
Having said that, there surely is a nonzero risk of introducing  
new bugs.  Since this failure mode escaped detection for ten years,  
such cases don't seem common enough to justify a lot of risk.  
Therefore, let's put this fix into master but leave the back branches  
alone (for now anyway).  
  
Bug: #18953  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Diagnosed-by: Richard Guo <guofenglinux@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18953-1c9883a9d4afeb30@postgresql.org  

commit   : 5861b1f343b52ac358912707788214fb8dc981e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jun 2025 13:41:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jun 2025 13:41:11 -0400    

While choosing an autogenerated name for an index, look for  
pre-existing relations using a SnapshotDirty snapshot, instead of the  
previous behavior that considered only committed-good pg_class rows.  
This allows us to detect and avoid conflicts against indexes that are  
still being built.  
  
It's still possible to fail due to a race condition, but the window  
is now just the amount of time that it takes DefineIndex to validate  
all its parameters, call smgrcreate(), and enter the index's pg_class  
row.  Formerly the race window covered the entire time needed to  
create and fill an index, which could be very long if the table is  
large.  Worse, if the conflicting index creation is part of a larger  
transaction, it wouldn't be visible till COMMIT.  
  
So this isn't a complete solution, but it should greatly ameliorate  
the problem, and the patch is simple enough to be back-patchable.  
  
It might at some point be useful to do the same for pg_constraint  
entries (cf. ChooseConstraintName, ConstraintNameExists, and related  
functions).  However, in the absence of field complaints, I'll leave  
that alone for now.  The relation-name test should be good enough for  
index-based constraints, while foreign-key constraints seem to be okay  
since they require exclusive locks to create.  
  
Bug: #18959  
Reported-by: Maximilian Chrzan <maximilian.chrzan@here.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/18959-f63b53b864bb1417@postgresql.org  
Backpatch-through: 13  

commit   : 2f6e240d7ac930698995ac608695cb0368f504f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jun 2025 12:12:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jun 2025 12:12:29 -0400    

We never create regress.def, and if we did this code would fail to  
delete it, because "win" is not the correct PORTNAME for Windows.  
  
This thinko seems to have originated in commit 7a6b562fd from 1999,  
although it got moved around multiple times since then.  
  
Author: Christoph Berg <myon@debian.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aFVR7R7VDX7y2ruc@msg.df7cb.de  

commit   : 4464fddf7b50abe3dbb462f76fd925e10eedad1c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Jun 2025 01:41:28 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Jun 2025 01:41:28 +0300    

The TAP tests that verify logical and physical replication slot behavior  
during checkpoints (046_checkpoint_logical_slot.pl and  
047_checkpoint_physical_slot.pl) inserted two batches of 2 million rows each,  
generating approximately 520 MB of WAL.  On slow machines, or when compiled  
with '-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE', this caused the  
tests to run for 8-9 minutes and occasionally time out, as seen on the  
buildfarm animal prion.  
  
This commit modifies the mentioned tests to utilize the $node->advance_wal()  
function, thereby reducing runtime. Once we do not use the generated data,  
the proposed function is a good alternative, which cuts the total wall-clock  
run time.  
  
While here, remove superfluous '\n' characters from several note() calls;  
these appeared literally in the build-farm logs and looked odd.  Also, remove  
excessive 'shared_preload_libraries' GUC from the config and add a check for  
'injection_points' extension availability.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Alexander Korotkov <aekorotkov@gmail.com>  
Author: Vitaly Davydov <v.davydov@postgrespro.ru>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/fbc5d94e-6fbd-4a64-85d4-c9e284a58eb2%40gmail.com  
Backpatch-through: 17  

commit   : a8360f074cc03a7cb73a4aaa6d8caab0e0bf0a0f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Jun 2025 17:13:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Jun 2025 17:13:58 -0400    

commit   : 6c29088fc6e269b7d64797bb62533b82afe03d93    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 19 Jun 2025 12:43:27 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 19 Jun 2025 12:43:27 -0700    

In version 17 we added support for cross-partition EXCLUDE  
constraints, as long as they included all partition key columns and  
compared them with equality (see 8c852ba9a4). I updated the docs for  
exclusion constraints, but I missed that the docs for CREATE TABLE  
still said that they were not supported. This commit fixes that.  
  
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Co-authored-by: Jeff Davis <pgsql@j-davis.com>  
Discussion: https://postgr.es/m/c955d292-b92d-42d1-a2a0-1ec6715a2546@illuminatedcomputing.com  
Backpatch-through: 17  

commit   : ed117c4c6c4feb1362abbb417ac6e6525dd8789b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Jun 2025 11:59:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Jun 2025 11:59:00 -0400    

commit   : d8aa21b74ff4e3d767c3344484c3cb22b9f0ec0d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Jun 2025 11:50:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Jun 2025 11:50:50 -0400    

to be used for PG 18 release notes  

commit   : dec6643487bbed8f5d771e9b9aff772e5c711d4d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Jun 2025 13:53:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Jun 2025 13:53:12 +0200    

Increase consistency of --help and man page synopses between pg_dump  
and pg_dumpall.  These should now be very similar, as pg_dumpall can  
now also produce non-text dump output.  But actually, they had drifted  
further apart.  
  
- Use verb "export" consistently, instead of "dump" or "extract".  
- Use "SQL script" instead of just "script" or "text file".  
- Maintain consistent distinction between SQL script and other  
  formats/archives (which is relevant for pg_restore).  
  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://www.postgresql.org/message-id/flat/3f71d8a7-095b-4829-9b0b-fce09e9866b3%40eisentraut.org  

commit   : 1546e17f9d067e714e066fcdd57d5f56c14f4174    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Jun 2025 09:48:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Jun 2025 09:48:08 +0530    

Improve the clarity of LOG messages when a failover logical slot  
synchronization fails, making the reasons more explicit for easier  
debugging.  
  
Update the documentation to outline scenarios where slot synchronization  
can fail, especially during the initial sync, and emphasize that  
pg_sync_replication_slot() is primarily intended for testing and  
debugging purposes.  
  
We also discussed improving the functionality of  
pg_sync_replication_slot() so that it can be used reliably, but we would  
take up that work for next version after some more discussion and review.  
  
Reported-by: Suraj Kharage <suraj.kharage@enterprisedb.com>  
Author: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/CAF1DzPWTcg+m+x+oVVB=y4q9=PYYsL_mujVp7uJr-_oUtWNGbA@mail.gmail.com  

commit   : a03805920b36b79b7ddf97c6804117f3296b2900    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 18 Jun 2025 21:19:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 18 Jun 2025 21:19:42 -0400    

commit   : db0c93f172a41515734a774f0412ff9557eca8ed    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Jun 2025 09:12:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Jun 2025 09:12:34 +0900    

Commit 8492feb98f6 added support for parallel CREATE INDEX on GIN indexes.  
However, previously two places in the documentation and two in the source  
code comments still stated that only B-tree and BRIN indexes support  
parallel builds.  
  
This commit updates those references to correctly include GIN indexes.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/7d27d068-90e2-4022-9bd7-09b0fd3d4f47@oss.nttdata.com  

commit   : b57d707708181f988fd1fa697976059510fc4f76    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Jun 2025 09:07:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Jun 2025 09:07:19 +0900    

Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE.  
In this feature, since indexes are not created for foreign tables,  
comments on indexes are not copied either.  
  
However, the documentation incorrectly stated that index comments  
would be copied when using INCLUDING COMMENTS. This commit  
corrects that by removing the mention of index comments.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/f86cd84f-a6a3-4451-bae7-5cca9e63b06d@oss.nttdata.com  

commit   : d0d1bcb1e8b2e324bc243d69ccfce55b25a79f8c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 18 Jun 2025 16:48:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 18 Jun 2025 16:48:26 -0400    

I thought underscores wouldn't even work in "id"s, so I never checked to  
see if anything referenced it, but it seems it does work, so adjust the  
calling site for the dash syntax.  

commit   : 09f7d36ba16e9665bb25d2c097e71c7439485fd7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 18 Jun 2025 16:43:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 18 Jun 2025 16:43:27 -0400    

Change "id"s of file_copy_method and enable_self_join_elimination for  
consistency with the rest of the guc "id"s.  These are new entries for  
PG 18.  

commit   : c2e2589ab969eb802493191c79de844bf7dc3a6e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Jun 2025 14:53:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Jun 2025 14:53:55 +0900    

Commit 1fd1bd87101 introduced support for dumping statistics with  
pg_dump and pg_dumpall, covering tables, materialized views, and indexes.  
However, it overlooked foreign tables, even though functions like  
pg_restore_relation_stats() support them.  
  
This commit fixes that oversight by allowing pg_dump and pg_dumpall  
to include statistics for foreign tables.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Corey Huinker <corey.huinker@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/3772e4e4-ef39-4deb-bb76-aa8165f33fb6@oss.nttdata.com  

commit   : 9e1183953f0aee6b8040cd782a8af9996f5ca942    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Jun 2025 11:03:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Jun 2025 11:03:21 +0900    

This parameter has been introduced in 325f2ec5557f, and it was not  
documented contrary to all the other arguments of  
heap_create_with_catalog().  
  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Steven Niu <niushiji@gmail.com>  
Discussion: https://postgr.es/m/aE--bmEv-gJUTH5v@paquier.xyz  

commit   : 428a87607b58949cfc35eeab94825e2de0d541a5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Jun 2025 09:18:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Jun 2025 09:18:40 +0900    

Commit 285613c60a7 introduced the min_protocol_version and  
max_protocol_version connection options for libpq, but their descriptions  
were placed in the middle of the unrelated ssl_min_protocol_version and  
ssl_max_protocol_version entries.  
  
This commit moves the min_protocol_version and max_protocol_version  
descriptions to appear after the SSL-related options. This improves  
the logical order and makes it easier for users to locate the relevant  
settings in the libpq documentation.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://postgr.es/m/a3391f36-30f5-4d4a-825b-232476819de8@oss.nttdata.com  

commit   : bb43c97babdf09efbd97bb535d2acb522678f977    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 17 Jun 2025 20:00:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 17 Jun 2025 20:00:38 -0400    

commit   : 917c00d761fa9ba3b2bc365804ef38fc60ec023e    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 17 Jun 2025 22:42:38 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 17 Jun 2025 22:42:38 +0200    

The memory allocation for cancelConn->be_cancel_key was accidentally  
checking the be_cancel_key member in the conn object instead of the  
one in cancelConn.  
  
Author: Ranier Vilela <ranier.vf@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAEudQAq4ySDR6dsg9xwurBXwud02hX7XCOZZAcZx-JMn6A06nA@mail.gmail.com  

commit   : 0cf205e122ae0fe9333ccf843c2269f13ddc32fc    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 16:48:09 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 16:48:09 +0200    

Fix two issues in parent_key validation in posting trees:  
  
* It's not enough to check stack->parentblk is valid to determine if the  
  parentkey is valid. It's possible parentblk is set to a valid block  
  number, but parentkey is invalid. So check parentkey directly.  
  
* We don't need to invalidate parentkey for all child pages of the  
  rightmost page. It's enough to invalidate it for the rightmost child  
  only, which means we can check more cases (less false negatives).  
  
Issues reported by Arseniy Mukhin, along with a proposed patch. Review  
by Andrey M. Borodin, cleanup and improvements by me.  
  
Author: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com  

commit   : cdd1a431f21dbd2b7b675a9db1c24b97d713f38b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 15:46:26 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 15:46:26 +0200    

The checks introduced by commit 14ffaece0fb5 did not get the parent key  
checks quite right, missing some data corruption cases. In particular:  
  
* The "rightlink" check was not working as intended, because rightlink  
  is a BlockNumber, and InvalidBlockNumber is 0xFFFFFFFF, so  
  
    !GinPageGetOpaque(page)->rightlink  
  
  almost always evaluates to false (except for rightlink=0). So in most  
  cases parenttup was left NULL, preventing any checks against parent.  
  
* Use GinGetDownlink() to retrieve child blkno to avoid triggering  
  Assert, same as the core GIN code.  
  
Issues reported by Arseniy Mukhin, along with a proposed patch. Review  
by Andrey M. Borodin, cleanup and improvements by me.  
  
Author: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com  

commit   : 0b54b392334b255abeac7c2718de7071600444ad    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 14:55:27 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 14:55:27 +0200    

This tightens a couple checks in checking GIN indexes, which might have  
resulted in incorrect results (false positives/negatives).  
  
* The code skipped ordering checks if the entries were for different  
  attributes (for multi-column GIN indexes), possibly missing some cases  
  of data corruption. But the attribute number is part of the ordering,  
  so we can check that.  
  
* The root page was skipped when checking entry order, but that is  
  unnecessary. The root page is subject to the same ordering rules, we  
  can process it just like any other page.  
  
* The high key on the right-most page was not checked, but that is  
  needed only for inner pages (we don't store the high key for those).  
  For leaf pages we can check the high key just fine.  
  
* Correct the detection of split pages. If the page gets split, the  
  cached parent key is greater than the current child key (not less, as  
  the code incorrectly expected).  
  
Issues reported by Arseniy Mukhin, along with a proposed patch. Review  
by Andrey M. Borodin, cleanup and improvements by me.  
  
Author: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com  

commit   : 8dd41c0bff5b6944fb536cf8f2627d5f542581cd    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 14:16:35 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 14:16:35 +0200    

The field was introduced by commit 14ffaece0fb5, but is unused and  
unnecessary. So remove it.  
  
Issues reported by Arseniy Mukhin, along with a proposed patch. Review  
by Andrey M. Borodin, cleanup and minor improvements by me.  
  
Author: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com  

commit   : c89d6b889ce958dcab27b0342eca36634c0fefaf    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 14:14:36 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 17 Jun 2025 14:14:36 +0200    

Adds a regression test with gin_index_check() on a multicolumn index,  
to verify it's handled correctly and improve test coverage for code  
introduced by 14ffaece0fb5.  
  
Author: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CAE7r3MJ611B9TE=YqBBncewp7-k64VWs+sjk7XF6fJUX77uFBA@mail.gmail.com  

commit   : 6f55fb741147c49dc20dd2e4597363b2cc04acb4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Jun 2025 07:39:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Jun 2025 07:39:43 +0200    

It was previously not documented.  
  
Author: Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ZR0P278MB04279CB0C1D8F49DE68F168ED2AF2%40ZR0P278MB0427.CHEP278.PROD.OUTLOOK.COM  

commit   : 23c67e8a839441c9d6a307b531a3369b677c91eb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Jun 2025 21:04:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Jun 2025 21:04:14 -0400    

Needed to run src/tools//add_commit_links.pl.  

commit   : d87d07b7ad3b782cb74566cd771ecdb2823adf6a    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:36:01 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:36:01 -0700    

Commit 4909b38af0 introduced logic to distribute invalidation messages  
from catalog-modifying transactions to all concurrent in-progress  
transactions. However, since each transaction distributes not only its  
original invalidation messages but also previously distributed  
messages to other transactions, this leads to an exponential increase  
in allocation request size for invalidation messages, ultimately  
causing memory allocation failure.  
  
This commit fixes this issue by tracking distributed invalidation  
messages separately per decoded transaction and not redistributing  
these messages to other in-progress transactions. The maximum size of  
distributed invalidation messages that one transaction can store is  
limited to MAX_DISTR_INVAL_MSG_PER_TXN (8MB). Once the size of the  
distributed invalidation messages exceeds this threshold, we  
invalidate all caches in locations where distributed invalidation  
messages need to be executed.  
  
Back-patch to all supported versions where we introduced the fix by  
commit 4909b38af0.  
  
Note that this commit adds two new fields to ReorderBufferTXN to store  
the distributed transactions. This change breaks ABI compatibility in  
back branches, affecting third-party extensions that depend on the  
size of the ReorderBufferTXN struct, though this scenario seems  
unlikely.  
  
Additionally, it adds a new flag to the txn_flags field of  
ReorderBufferTXN to indicate distributed invalidation message  
overflow. This should not affect existing implementations, as it is  
unlikely that third-party extensions use unused bits in the txn_flags  
field.  
  
Bug: #18938 #18942  
Author: vignesh C <vignesh21@gmail.com>  
Reported-by: Duncan Sands <duncan.sands@deepbluecap.com>  
Reported-by: John Hutchins <john.hutchins@wicourts.gov>  
Reported-by: Laurence Parry <greenreaper@hotmail.com>  
Reported-by: Max Madden <maxmmadden@gmail.com>  
Reported-by: Braulio Fdo Gonzalez <brauliofg@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/680bdaf6-f7d1-4536-b580-05c2760c67c6@deepbluecap.com  
Discussion: https://postgr.es/m/18942-0ab1e5ae156613ad@postgresql.org  
Discussion: https://postgr.es/m/18938-57c9a1c463b68ce0@postgresql.org  
Discussion: https://postgr.es/m/CAD1FGCT2sYrP_70RTuo56QTizyc+J3wJdtn2gtO3VttQFpdMZg@mail.gmail.com  
Discussion: https://postgr.es/m/CANO2=B=2BT1hSYCE=nuuTnVTnjidMg0+-FfnRnqM6kd23qoygg@mail.gmail.com  
Backpatch-through: 13  

commit   : 33b06a20016d8dd8dbdc1f6d6a9d79477c1104c5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 17 Jun 2025 10:49:36 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 17 Jun 2025 10:49:36 +1200    

Sometimes the TupleDesc used in verify_compact_attribute() is shared  
among backends, and since CompactAttribute.attcacheoff gets updated  
during tuple deformation, it was possible that another backend would  
set attcacheoff on a given CompactAttribute in the small window of time  
from when the attcacheoff from the live CompactAttribute was being set  
in the 'tmp' CompactAttribute and before the Assert verifying that the  
live and tmp CompactAttributes matched.  
  
Here we adjust the code to make a copy of the live CompactAttribute so  
that we're not trying to Assert against a shared copy of it.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/7195e408-758c-4031-8e61-4f842c716ac0@gmail.com  

commit   : e9a3615a5224236917af161d9b6a55ba8f129b4d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 16 Jun 2025 12:36:01 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 16 Jun 2025 12:36:01 -0400    

Previously there was no memory barrier enforcing correct memory ordering when  
waiting for a free IO handle. However, in the much more common case of waiting  
for IO to complete, memory barriers already were present.  
  
On strongly ordered architectures like x86 this had no negative consequences,  
but on some armv8 hardware (observed on Apple hardware), it was possible for  
the update, in the IO worker, to PgAioHandle->state to become visible before  
->distilled_result becoming visible, leading to rather confusing assertion  
failures. The failures were rare enough that the bug sometimes took days to  
reproduce when running 027_stream_regress in a loop.  
  
Once finally debugged, it was easy enough to come up with a much quicker  
repro: Trigger a lot of very fast IO by limiting io_combine_limit to 1 and  
ensure that we always have to wait for a free handle by setting  
io_max_concurrency to 1. Triggering lots of concurrent seqscans in that setup  
triggers the issue within seconds.  
  
One reason this was hard to debug was that the assertion failure most commonly  
happened in WaitReadBuffers(), rather than in the AIO subsystem itself. The  
assertions added in this commit make problems like this easier to understand.  
  
Also add a comment to the IO worker explaining that we rely on the lwlock  
acquisition for correct memory ordering.  
  
I think it'd be good to add a tap test that stress tests buffer IO, but that's  
material for a separate patch.  
  
Thanks a lot to Alexander and Konstantin for all the debugging help.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Investigated-by: Andres Freund <andres@anarazel.de>  
Investigated-by: Alexander Lakhin <exclusion@gmail.com>  
Investigated-by: Konstantin Knizhnik <knizhnik@garret.ru>  
Discussion: https://postgr.es/m/2dkz7azclpeiqcmouamdixyn5xhlzy4rvikxrbovyzvi6rnv5c@pz7o7osv2ahf  

commit   : ee685c9baf987984dbd2194d74576422996d95f4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jun 2025 11:43:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jun 2025 11:43:52 +0200    

commit   : f24fdf985561e7166d7d54459b764daae8efda44    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jun 2025 11:16:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jun 2025 11:16:52 +0200    

commit   : a876464abc73eccc04543da6a12eb5b1ffcd6dfd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jun 2025 11:14:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jun 2025 11:14:39 +0200    

Some message style improvements in new code, and some small  
refactorings to make translations easier.  

commit   : f83f14881c7a09198863cb46033af8959a462d8b    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Mon, 16 Jun 2025 09:27:15 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Mon, 16 Jun 2025 09:27:15 +0700    

At optimization level -O0, builds on recent clang fail to produce the  
correct CRC32C with our AVX-512 implementation. For now, just disable  
the runtime check for clang at -O0. When this is fixed upstream and we  
know the extent of the breakage, we can adjust to be version-specific.  
  
Reported-by: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>  
Reported-by: Andy Fan <zhihuifan1213@163.com>  
Tested-by: Andy Fan <zhihuifan1213@163.com>  
Discussion: https://postgr.es/m/CAE-ML%2B-OV6p9uvCFBcSQjZUEh__y0h-KjN%2BBseyGJHt7u8EP%2Bw%40mail.gmail.com  
Discussion: https://postgr.es/m/87o6uqd3iv.fsf%40163.com  

commit   : fd385c4c62d1762c88c0cdb145f354c834875dce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jun 2025 13:11:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jun 2025 13:11:04 -0400    

commit   : b27644bade0348d0dafd3036c47880a349fe9332    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jun 2025 13:04:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jun 2025 13:04:24 -0400    

Our maintenance of typedefs.list has been a little haphazard  
(and apparently we can't alphabetize worth a darn).  Replace  
the file with the authoritative list from our buildfarm, and  
run pgindent using that.  
  
I also updated the additions/exclusions lists in pgindent where  
necessary to keep pgindent from messing things up significantly.  
Notably, now that regex_t and some related names are macros not real  
typedefs, we have to whitelist them explicitly.  The exclusions list  
has also drifted noticeably, presumably due to changes of system  
headers on the buildfarm animals that contribute to the list.  
  
Unlike in prior years, I've not manually added typedef names that  
are missing from the buildfarm's list because they are not used to  
declare any variables or fields.  So there are a few places where  
the typedef declaration itself is formatted worse than before,  
e.g. typedef enum IoMethod.  I could preserve the names that were  
manually added to the list previously, but I'd really prefer to find  
a less manual way of dealing with these cases.  A quick grep finds  
about 75 such symbols, most of which have never gotten any special  
treatment.  
  
Per discussion among pgsql-release, doing this now seems appropriate  
even though we're still a week or two away from making the v18 branch.  

commit   : 6d6480066c1a96c7130b97b1139fdada9d484f80    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 15 Jun 2025 10:59:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 15 Jun 2025 10:59:30 +0200    

Commit bba2fbc6238 introduced a new implementation of the \conninfo  
command in psql.  That new code uses the term "TLS" while the rest of  
PostgreSQL, including the rest of psql, consistently uses "SSL".  This  
is uselessly confusing.  This changes the new code to use "SSL" as  
well.  
  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/f4ff9294-b491-4053-83f5-11c10ab8c999@eisentraut.org  

commit   : 2f98f967fa78fd36279989ecdd5fbf74ab332fa9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 14 Jun 2025 17:18:31 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 14 Jun 2025 17:18:31 +1200    

Here we provide a bit more detail on why TidRangeEval() does return false  
when trss_mintid is greater than trss_maxtid.  
  
Reported-by: Junwang Zhao <zhjwpku@gmail.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/CAEG8a3KUbUUqQgfK5X8Sj-%2BppPtGNTU%2BZiep0Rxr7SLjoR%2BB6w%40mail.gmail.com  

commit   : 0fe50417eca46d6993da350845dc09d7e899c6d6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 14 Jun 2025 10:39:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 14 Jun 2025 10:39:26 +0900    

In the \conninfo psql command, the "Client User" column shows the user who  
established the connection, while the "Superuser" column reflects whether  
the current user in the current execution context is a superuser. This means  
the users referred to in these columns can differ, for example, if the current  
user was changed with the SET ROLE command.  
  
This commit adds a note to the \conninfo documentation to clarify  
this behavior and avoid potential confusion.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/685961b8-b6ce-40bb-b2d5-c2ff135d3388@oss.nttdata.com  

commit   : be37ac20fc23511c49b9c56567c7c707b73d10b0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 14 Jun 2025 10:37:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 14 Jun 2025 10:37:12 +0900    

Commit bba2fbc6238 modified \conninfo to display the protocol version  
used by the current connection, but it only showed the major version (e.g., 3).  
  
This commit updates \conninfo to display the full protocol version (e.g., 3.2).  
Since support for new version 3.2 was added in v18, and the server supports  
both 3.0 and 3.2, showing the complete version helps users understand  
exactly which protocol version the current session is using.  
  
Although this is a minor behavior change, it's considered a fix for  
an oversight in the original patch and is included in v18.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/685961b8-b6ce-40bb-b2d5-c2ff135d3388@oss.nttdata.com  

commit   : eb124c3d6deb5d0c7a588d847e3840bcc2cd0dcc    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 14 Jun 2025 03:35:27 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 14 Jun 2025 03:35:27 +0300    

The new tests verify that logical and physical replication slots are still  
valid after an immediate restart on checkpoint completion when the slot was  
advanced during the checkpoint.  
  
This commit introduces two new injection points to make these tests possible:  
  
* checkpoint-before-old-wal-removal - triggered in the checkpointer process  
  just before old WAL segments cleanup;  
* logical-replication-slot-advance-segment - triggered in  
  LogicalConfirmReceivedLocation() when restart_lsn was changed enough to  
  point to the next WAL segment.  
  
Discussion: https://postgr.es/m/flat/1d12d2-67235980-35-19a406a0%4063439497  
Author: Vitaly Davydov <v.davydov@postgrespro.ru>  
Author: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 17  

commit   : ca307d5cec90a4fde62a50fafc8ab607ff1d8664    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 14 Jun 2025 03:36:04 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 14 Jun 2025 03:36:04 +0300    

The patch fixes the issue with the unexpected removal of old WAL segments  
after checkpoint, followed by an immediate restart.  The issue occurs when  
a slot is advanced after the start of the checkpoint and before old WAL  
segments are removed at the end of the checkpoint.  
  
The patch introduces a new in-memory state for slots: last_saved_restart_lsn,  
which is used to calculate the oldest LSN for removing WAL segments. This  
state is updated every time with the current restart_lsn at the moment when  
the slot is saved to disk.  
  
This fix changes the shared memory layout.  It's applied to HEAD only because  
we don't have to preserve ABI compatibility during the beta stage.  Another  
fix that doesn't affect the ABI is committed to back branches.  
  
Discussion: https://postgr.es/m/1d12d2-67235980-35-19a406a0%4063439497  
Author: Vitaly Davydov <v.davydov@postgrespro.ru>  
Author: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  

commit   : c45a1dba0d85c7a44f29f1841afd877ba4f4c683    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 13 Jun 2025 19:58:47 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 13 Jun 2025 19:58:47 -0400    

_bt_readnextpage expects so->currPos.buf to be InvalidBuffer (and for  
the position's page to be unlocked) when called.  However, it does not  
expect there to be no pins held on any page.  In particular, so->markPos  
might hold a separate pin, both before and after the call.  Fix some  
comments that seemed to suggest otherwise.  
  
Follow-up commit to commit 7c319f54, which made _bt_killitems drop pins  
it acquired itself.  

commit   : a0c7b765372d949cec54960dafcaadbc04b3204e    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jun 2025 10:02:24 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jun 2025 10:02:24 -0700    

Reported-by: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CAHut+PspbHQmRCBL1c-opoJeTUKUaFFfUQJd2rhDZqwUrWCi7w@mail.gmail.com  

commit   : 29aaeceee2f3420fb6ecb8e6aae311076c17f687    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Jun 2025 15:13:09 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Jun 2025 15:13:09 +0200    

Reword the documentation around the default value to make interaction  
between WATCH_INTERVAL and the \watch command clearer.  While there,  
also remove a stray parenthesis left over from a previous version of  
the patch.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/c34a650b-6f8b-4da7-9ebb-b6df03ce009d@eisentraut.org  

commit   : 6e951f279beab566efa267151d028c3684f6095e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Jun 2025 10:15:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Jun 2025 10:15:17 +0900    

Running COPY within a pipeline can break protocol synchronization in  
multiple ways.  psql is limited in terms of result processing if mixing  
COPY commands with normal queries while controlling a pipeline with the  
new meta-commands, as an effect of the following reasons:  
- In COPY mode, the backend ignores additional Sync messages and will  
not send a matching ReadyForQuery expected by the frontend.  Doing a  
\syncpipeline just after COPY will leave the frontend waiting for a  
ReadyForQuery message that won't be sent, leaving psql out-of-sync.  
- libpq automatically sends a Sync with the Copy message which is not  
tracked in the command queue, creating an unexpected synchronisation  
point that psql cannot really know about.  While it is possible to track  
such activity for a \copy, this cannot really be done sanely with plain  
COPY queries.  Backend failures during a COPY would leave the pipeline  
in an aborted state while the backend would be in a clean state, ready  
to process commands.  
  
At the end, fixing those issues would require modifications in how libpq  
handles pipeline and COPY.  So, rather than implementing workarounds in  
psql to shortcut the libpq internals (with command queue handling for  
one), and because meta-commands for pipelines in psql are a new feature  
with COPY in a pipeline having a limited impact compared to other  
queries, this commit forbids the use of COPY within a pipeline to avoid  
possible break of protocol synchronisation within psql.  If there is a  
use-case for COPY support within pipelines in libpq, this could always  
be added in the future, if necessary.  
  
Most of the changes of this commit impacts the tests for psql pipelines,  
removing the tests related to COPY.  Some TAP tests still exist for COPY  
TO/FROM and \copy to/from, to check that that connections are aborted  
when this operation is attempted.  
  
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Discussion: https://postgr.es/m/AC468509-06E8-4E2A-A4B1-63046A4AC6AB@postgrespro.ru  

commit   : 2c76c6ac470fb0b5bcaec095c1ed90e45cebba75    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Jun 2025 08:59:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Jun 2025 08:59:47 +0900    

This is a continuation of 15a79c73111f, cleaning up the AIO io_uring  
code that has been committed after that while still using %llu.  
  
The code changed here is new in v18, so cleaning things now means less  
conflicts if this area of the code changes on backpatch once the 18  
stable branch is created.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/aEZcGCnYFq642q8k@paquier.xyz  

commit   : 84914e964b447a63c5208ca2ec11ec3abfda0879    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 12 Jun 2025 23:25:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 12 Jun 2025 23:25:21 +0900    

Commit bde2fb797aa added the --with-schema, --with-data, and --with-statistics  
options to pg_restore. These options control whether to restore schema, data,  
or statistics if present in the archive. However, the help message and  
documentation incorrectly described them as affecting what gets dumped.  
  
This commit corrects those descriptions to clarify that the options control  
restoration, not dumping.  
  
Bug: #18952  
Reported-by: TAKATSUKA Haruka <harukat@sraoss.co.jp>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: TAKATSUKA Haruka <harukat@sraoss.co.jp>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/18952-be40a620f8b1e755@postgresql.org  

commit   : 0f65f3eec478db8ac4f217a608b4478fed023bac    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 12 Jun 2025 14:21:21 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 12 Jun 2025 14:21:21 +0200    

The algorithm to squash lists of constants added by commit 62d712ecfd94  
was a bit too simplistic; we wanted to avoid adding unnecessary  
complexity, but cases like direct function calls of typecasting  
functions (and others) were missed, and bogus SQL syntax was being shown  
in pg_stat_statements normalized query text field.  To fix normalization  
for those cases, we need the parser to transmit information about were  
each list of constant values starts and ends, so add that to a couple of  
nodes.  Also add a few more test cases to make sure we're doing the  
right thing.  
  
The patch initially submitted by Sami added a new private struct in  
gram.y to carry the start/end information for A_Expr, but I (Álvaro)  
decided that a better fix was to remove the parser indirection via the  
in_expr production, and instead create separate components in the a_expr  
rule.  I'm surprised that this works and doesn't require more changes,  
but I assume (without checking) that the grammar used to be more complex  
and got simplified at some point.  
  
Bump catversion.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Author: Dmitry Dolgov <9erthalion6@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAA5RZ0tRXoPG2y6bMgBCWNDt0Tn=unRerbzYM=oW0syi1=C1OA@mail.gmail.com  

commit   : f7b11414e939a00faa63e27feae69ceef5bf4b02    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 12 Jun 2025 14:53:32 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 12 Jun 2025 14:53:32 +0900    

Database object statistics manipulation functions were introduced  
in PostgreSQL 18 and are permitted under the MAINTAIN privilege.  
However, the documentation previously did not mention these functions  
in the list of allowed operations.  
  
This commit updates the MAINTAIN privilege documentation to  
explicitly include statistics manipulation functions, clarifying  
what the privilege covers.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/7c7e1ad5-fdf9-486f-bc63-40ac99b0461d@oss.nttdata.com  

commit   : f85f6ab051b7cf6950247e5fa6072c4130613555    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jun 2025 10:08:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jun 2025 10:08:55 +0900    

This commit reverts the two following commits:  
- 499edb09741b, track more precisely query locations for nested  
statements.  
- 06450c7b8c70, a follow-up fix of 499edb09741b with query locations.  
The test introduced in this commit is not reverted.  This is proving  
useful to track a problem that only pgaudit was able to detect.  
  
These prove to have issues with the tracking of SELECT statements, when  
these use multiple parenthesis which is something supported by the  
grammar.  Incorrect location and lengths are causing pg_stat_statements  
to become confused, failing its job in query normalization with  
potential out-of-bound writes because the location and the length may  
not match with what can be handled.  A lot of the query patterns  
discussed when this issue was reported have no test coverage in the main  
regression test suite, or the recovery test 027_stream_regress.pl would  
have caught the problems as pg_stat_statements is loaded by the node  
running the regression tests.  A first step would be to improve the test  
coverage to stress more the query normalization logic.  
  
A different portion of this work was done in 45e0ba30fc40, with the  
addition of tests for nested queries.  These can be left in the tree.  
They are useful to track the way inner queries are currently tracked by  
PGSS with non-top-level entries, and will be useful when reconsidering  
in the future the work reverted here.  
  
Reported-by: Alexander Kozhemyakin <a.kozhemyakin@postgrespro.ru>  
Discussion: https://postgr.es/m/18947-cdd2668beffe02bf@postgresql.org  

commit   : dd2ce3792754e0705884aed15d1fd2ae43cc1500    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 18:16:15 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 18:16:15 -0400    

This reverts commit 54c6ea8c81db718508eeea50991d3c1c5dff54a5.  
  
Further analysis has shown that the forcenonrequired row compare  
behavior is in fact necessary, despite the new restrictions on  
RowCompares imposed by _bt_set_startikey following commit 5f4d98d4.  
  
Discussion: https://postgr.es/m/CAH2-Wzm3bKcz3TbHGem3_+SinEyG=VZVPbApQghp7YiZj+MM3g@mail.gmail.com  

commit   : e1458f2f1b56cfe07b3e8fc99b223ea8c852d7ce    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 11 Jun 2025 15:03:52 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 11 Jun 2025 15:03:52 -0700    

- 4c787a24e7e220a60022e47c1776f22f72902899  
- 78bd364ee39ca70a8f9cb8719282389866a08e14  
- 7a6880fadc177873d5663961ec3a02d67e34dcbe  
- 8898082a5d3e94eef073f0e08124137e096e78ef  
  
Suggested-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CA+TgmoZ=J=PVNZUNKaxULu+KUVSt3Y-aJ1DZ9Y3Co6mu0z62jA@mail.gmail.com  
Discussion: https://postgr.es/m/60e8c6d0a6c08e67f15dbbe9e53df0119c710065.camel@j-davis.com  

commit   : b774ad49336764aef063b9dbc1e7b7eb11c36e11    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 11 Jun 2025 11:44:25 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 11 Jun 2025 11:44:25 -0700    

This addresses an oversight in commit 4ac2a9bec, which introduced the  
REJECT_LIMIT option to the COPY command.  
  
Author: Atsushi Torikoshi <torikoshia@oss.nttdata.com>  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/ac23e824d1d602f113a89c91ee56fb23@oss.nttdata.com  

commit   : 7c319f54917faf564b660fe9027c4835a422bad6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:35 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:35 -0400    

Teach nbtree's _bt_killitems to leave the so->currPos page that it sets  
LP_DEAD items on in whatever state it was in when _bt_killitems was  
called.  In particular, make sure that so->dropPin scans don't acquire a  
pin whose reference is saved in so->currPos.buf.  
  
Allowing _bt_killitems to change so->currPos.buf like this is wrong.  
The immediate consequence of allowing it is that code in _bt_steppage  
(that copies so->currPos into so->markPos) will behave as if the scan is  
a !so->dropPin scan.  so->markPos will therefore retain the buffer pin  
indefinitely, even though _bt_killitems only needs to acquire a pin  
(along with a lock) for long enough to mark known-dead items LP_DEAD.  
  
This issue came to light following a report of a failure of an assertion  
from recent commit e6eed40e.  The test case in question involves the use  
of mark and restore.  An initial call to _bt_killitems takes place that  
leaves so->currPos.buf in a state that is inconsistent with the scan  
being so->dropPin.  A subsequent call to _bt_killitems for the same  
position (following so->currPos being saved in so->markPos, and then  
restored as so->currPos) resulted in the failure of an assertion that  
tests that so->currPos.buf is InvalidBuffer when the scan is so->dropPin  
(non-assert builds got a "resource was not closed" WARNING instead).  
  
The same problem exists on earlier releases, though the issue is far  
more subtle there.  Recent commit e6eed40e introduced the so->dropPin  
field as a partial replacement for testing so->currPos.buf directly.  
Earlier releases won't get an assertion failure (or buffer pin leak),  
but they will allow the second _bt_killitems call from the test case to  
behave as if a buffer pin was consistently held since the original call  
to _bt_readpage.  This is wrong; there will have been an initial window  
during which no pin was held on the so->currPos page, and yet the second  
_bt_killitems call will neglect to check if so->currPos.lsn continues to  
match the page's now-current LSN.  
  
As a result of all this, it's just about possible that _bt_killitems  
will set the wrong items LP_DEAD (on release branches).  This could only  
happen with merge joins (the sole user of nbtree mark/restore support),  
when a concurrently inserted index tuple used a recently-recycled TID  
(and only when the new tuple was inserted onto the same page as a  
distinct concurrently-removed tuple with the same TID).  This is exactly  
the scenario that _bt_killitems' check of the page's now-current LSN  
against the LSN stashed in currPos was supposed to prevent.  
  
A follow-up commit will make nbtree completely stop conditioning whether  
or not a position's pin needs to be dropped on whether the 'buf' field  
is set.  All call sites that might need to drop a still-held pin will be  
taught to rely on the scan-level so->dropPin field recently introduced  
by commit e6eed40e.  That will make bugs of the same general nature as  
this one impossible (or make them much easier to detect, at least).  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/545be1e5-3786-439a-9257-a90d30f8b849@gmail.com  
Backpatch-through: 13  

commit   : 361499538c9d3640e1ed5522e08fdf81b08e76ae    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Jun 2025 09:27:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Jun 2025 09:27:28 +0900    

CREATE UNLOGGED TABLE was still being recommended by psql's tab  
completion as a possible pattern, but the backend is rejecting this  
option since e2bab2d79204.  
  
Reported-by: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>  
Discussion: https://postgr.es/m/CAOzEurQZ1a+6d1K8b=+Ww1NFQVwAt9KSCQsBWXYBaPnYCenK3g@mail.gmail.com  

commit   : 137935bd1167a94b0bfea7239033f1ba1a1d95bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jun 2025 18:39:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jun 2025 18:39:34 -0400    

Traditionally, libpq's pqPutMsgEnd has rounded down the amount-to-send  
to be a multiple of 8K when it is eagerly writing some data.  This  
still seems like a good idea when sending through a Unix socket, as  
pipes typically have a buffer size of 8K or some fraction/multiple of  
that.  But there's not much argument for it on a TCP connection, since  
(a) standard MTU values are not commensurate with that, and (b) the  
kernel typically applies its own packet splitting/merging logic.  
  
Worse, our SSL and GSSAPI code paths both have API stipulations that  
if they fail to send all the data that was offered in the previous  
write attempt, we mustn't offer less data in the next attempt; else  
we may get "SSL error: bad length" or "GSSAPI caller failed to  
retransmit all data needing to be retried".  The previous write  
attempt might've been pqFlush attempting to send everything in the  
buffer, so pqPutMsgEnd can't safely write less than the full buffer  
contents.  (Well, we could add some more state to track exactly how  
much the previous write attempt was, but there's little value evident  
in such extra complication.)  Hence, apply the round-down only on  
AF_UNIX sockets, where we never use SSL or GSSAPI.  
  
Interestingly, we had a very closely related bug report before,  
which I attempted to fix in commit d053a879b.  But the test case  
we had then seemingly didn't trigger this pqFlush-then-pqPutMsgEnd  
scenario, or at least we failed to recognize this variant of the bug.  
  
Bug: #18907  
Reported-by: Dorjpalam Batbaatar <htgn.dbat.95@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18907-d41b9bcf6f29edda@postgresql.org  
Backpatch-through: 13  

commit   : 8898082a5d3e94eef073f0e08124137e096e78ef    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:23:20 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:23:20 -0700    

Avoid dependence on setlocale(). No behavior change.  
  
Discussion: https://postgr.es/m/9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  

commit   : 7a6880fadc177873d5663961ec3a02d67e34dcbe    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:23:11 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:23:11 -0700    

Avoid dependence on setlocale(). No behavior change.  
  
Discussion: https://postgr.es/m/9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  

commit   : 78bd364ee39ca70a8f9cb8719282389866a08e14    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:23:05 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:23:05 -0700    

Avoid dependence on setlocale(). No behavior change.  
  
Discussion: https://postgr.es/m/9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  

commit   : 4c787a24e7e220a60022e47c1776f22f72902899    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:22:57 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 10 Jun 2025 11:22:57 -0700    

Avoid dependence on setlocale(). No behavior change.  
  
Discussion: https://postgr.es/m/9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  

commit   : 3feff3916ee106c084eca848527dc2d2c3ef4e89    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Jun 2025 07:04:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Jun 2025 07:04:43 +0200    

On macOS, when building with the make system, the exported symbols  
list $(SHLIB_EXPORTS) was ignored.  This was probably not intentional,  
it was probably just forgotten, since that combination has never  
actually been used until now (for libpq-oauth).  
  
The meson build system handles this correctly.  Also, other platforms  
have been doing this correctly.  
  
This fixes it.  It also does a bit of refactoring to make the code  
match the layout for other platforms.  
  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/c70ca32e-b109-460d-9810-6e23ebb4473f%40eisentraut.org  

commit   : 166b4f4560d68e2bcf0f82eb898ac5ee15147b82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Jun 2025 17:06:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Jun 2025 17:06:39 -0400    

pg_restore failed to restore large objects (blobs) out of  
directory-format dumps made by versions before PG v12.  
That's because, due to a bug fixed in commit 548e50976, those  
old versions put the wrong filename into the BLOBS TOC entry.  
Said bug was harmless before v17, because we ignored the  
incorrect filename field --- but commit a45c78e32 assumed it  
would be correct.  
  
Reported-by: Pavel Stehule <pavel.stehule@gmail.com>  
Author: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFj8pRCrZ=_e1Rv1N+6vDaH+6gf=9A2mE2J4RvnvKA1bLiXvXA@mail.gmail.com  
Backpatch-through: 17  

commit   : 7d4667c6203d0174903a53de9d1730fbec26576b    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 8 Jun 2025 17:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 8 Jun 2025 17:30:00 +0900    

We concluded that commit e5a3c9d9b is a feature rather than a fix; since  
it was added after feature freeze, revert it.  
  
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/ed2296f1-1a6b-4932-b870-5bb18c2591ae%40oss.nttdata.com  

commit   : 73e26cbeb5927053eea4e209e5eda34a30c353f1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 7 Jun 2025 11:25:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 7 Jun 2025 11:25:17 -0400    

Reported-by: Noah Misch  
  
Discussion: https://postgr.es/m/20250603172123.5f.nmisch@google.com  

commit   : 37e5f0b61fa8aad82a0b06438ed95c282ace994a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 7 Jun 2025 11:06:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 7 Jun 2025 11:06:25 -0400    

And move to the top of the incompatibility list.  This will impact users  
more than any other incompatibility item because of pg_upgrade.  

commit   : 1a857348e47dc4f1bbf104e746abe542c99004e8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Jun 2025 09:03:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Jun 2025 09:03:11 +0200    

Move plpython_error_5.out to plpython_error.out, since the pre-3.5  
version is no longer needed, since we raised the Python requirement to  
3.6 (commit 45363fca637).  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/d620e7c6-becc-4a8e-9b43-eea0da55faf2@eisentraut.org  

commit   : 5b40feab594c3019fd6b09e46f97f5b367050cf9    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 6 Jun 2025 15:28:51 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 6 Jun 2025 15:28:51 -0700    

Discussion: https://postgr.es/m/73959a14-267b-49c1-8293-291b175682cb@manitou-mail.org  
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>  

commit   : a31767fc0935bf8dce884ed35dbe644516d0115e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 6 Jun 2025 12:08:17 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 6 Jun 2025 12:08:17 -0500    

Commit 5fe08c006c fixed this for calls to dshash_create().  This  
commit fixes calls to dshash_attach() and dsa_create_in_place().  
  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aECi_gSD9JnVWQ8T%40nathan  

commit   : 304862973e9a77c31cbf05d10b8b71c1a2870e59    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 6 Jun 2025 11:40:52 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 6 Jun 2025 11:40:52 -0500    

Oversight in commit 8b2bcf3f28.  
  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/aECi_gSD9JnVWQ8T%40nathan  
Backpatch-through: 17  

commit   : e6eed40e44419e3268d01fe0d2daec08a7df68f7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 6 Jun 2025 10:19:44 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 6 Jun 2025 10:19:44 -0400    

Delay calling BufferGetLSNAtomic() until we finish reading a page that  
actually contains items that btgettuple will return to the executor.  
This reduces the number of calls during plain index scans (we'll only  
call BufferGetLSNAtomic() when _bt_readpage returns true), and totally  
eliminates calls during index-only scans, bitmap index scans, and plain  
index scans of an unlogged relation.  
  
Currently, when checksums (or wal_log_hints) are enabled, acquiring a  
page's LSN in BufferGetLSNAtomic() involves locking the buffer header  
(which involves the use of spinlocks).  Testing has shown that enabling  
page-level checksums causes large regressions with certain workloads,  
especially on larger multi-socket systems.  
  
The regression isn't tied to any Postgres 18 commit.  However, Postgres  
18 commit 04bec894 made initdb use checksums by default, so it seems  
prudent to address the problem now.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/941f0190-e3c6-4622-9ac7-c04e936e5fdb@vondra.me  
Discussion: https://postgr.es/m/CAH2-Wzk-Dg5XWs_jDuiHt4_7ryrSY+n=vxmHY51EVqPDFsKXmg@mail.gmail.com  

commit   : 016e407f4ba10b230f5094c9ba36a1df3d34fb22    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:27 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:27 -0400    

Reported-by: Daria Shanina <vilensipkdm@gmail.com>  
Author: Daria Shanina <vilensipkdm@gmail.com>  
Author: Robert Haas <robertmhaas@gmail.com>  
Backpatch-through: 13  

commit   : c37be39a74b25cc9c7b052ddae43061a6a2c6019    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2025 15:24:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2025 15:24:15 -0400    

Refine wording from commit 01463e1cc.  
  
Author: Noah Misch <noah@leadboat.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20250605163441.2f.nmisch@google.com  

commit   : 54c6ea8c81db718508eeea50991d3c1c5dff54a5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 5 Jun 2025 14:50:43 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 5 Jun 2025 14:50:43 -0400    

Use of a RowCompare key makes nbtree index scans ineligible to use  
pstate.forcenonrequired following recent bugfix commit 5f4d98d4.  
There's no longer any need for _bt_check_rowcompare to accept a  
forcenonrequired argument, so remove it.  

commit   : e6f98d8848f1803fda32011998c786a1bf4eb87c    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 5 Jun 2025 18:39:06 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 5 Jun 2025 18:39:06 +0200    

Similar to commit cc733ed164c5: when an unenforced foreign key that  
references a partitioned table is altered to be enforced, we scan  
the constrained table based on each partition on the referenced  
partitioned table.  This is bogus and likely to cause the ALTER TABLE to  
fail: we must only scan the constrained table as pointing to the  
top-level partitioned table.  Oversight in commit eec0040c4bcd.  Fix by  
eliding those scans.  
  
Author: Amul Sul <sulamul@gmail.com>  
Reported-by: jian he <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CACJufxF1e_gPOLtsDoaE4VCgQPC8KZW_kPAjPR5Rvv4Ew=fb2A@mail.gmail.com  

commit   : 04acad82b0f912e779795a4661f7d63f5e35b9da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2025 11:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2025 11:29:24 -0400    

For some reason this wasn't mentioned before.  
  
Author: Patrick Stählin <me@packi.ch>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/931e012a-57ba-41ba-9b88-24323a46dec5@packi.ch  
Backpatch-through: 13  

commit   : cc733ed164c5b57fdf34d16e4cc8e9bbdc171699    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 5 Jun 2025 17:17:13 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 5 Jun 2025 17:17:13 +0200    

Validating an unvalidated foreign key that references a partitioned  
table would try to queue validations for each individual partition of  
the referenced table, but this is wrong: each individual partition would  
not necessarily have all the referenced rows, so errors would be raised.  
Avoid doing that.  The pg_constraint rows that cause this to happen are  
only there to support the action triggers that implement the DELETE/  
UPDATE actions of the FK, so no validating scan is necessary.  
  
This was an oversight in commit b663b9436e75.  
  
An equivalent oversight exists for NOT ENFORCED constraints, which is  
not fixed in this commit.  
  
Author: Amul Sul <sulamul@gmail.com>  
Reported-by: Antonin Houska <ah@cybertec.at>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/26983.1748418675@localhost  

commit   : 4b05ebf0957bc796b9ea8f4d2ab5985714ef3252    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2025 11:05:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2025 11:05:53 -0400    

The choices made in commit 01463e1cc might pose copyright hazards,  
and are more cutesy than informative anyway.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20250415155850.9b.nmisch@google.com  

commit   : 112e40b867b3351ecc49b86a4fa07ec182b82e65    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 5 Jun 2025 09:54:16 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 5 Jun 2025 09:54:16 +0200    

Commit d696406a9b2 added a new join to the query for extensions, but did  
so in the wrong place, causing the AND clause to be applied to the wrong  
join.  
  
Author:	Suraj Kharage <suraj.kharage@enterprisedb.com>  
Reviewed-By: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/CAF1DzPVBrN-cmPB2zb7ZU=2J4vEF2fNdArGCG9w+9fnKq4v8tg@mail.gmail.com  

commit   : b87163e5f3847730ee5f59718d215c6e63e13bff    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jun 2025 09:39:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jun 2025 09:39:24 +0900    

This commit replaces the formula used for "TotalProcs" with a call to  
pgaio_uring_procs() in pgaio_uring_shmem_init() for the shared memory  
initialization, which is exactly the same, removing a duplication.  
  
pgaio_uring_procs() is used for shared memory sizing and a sanity check,  
and it has some documentation explaining some reasoning behind the  
formula.  
  
Author: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/ME0P300MB044521067A1EDDA9EDEC3793B66DA@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : f9b1192190aac56a319a1e3e93cf3c29d9f722dd    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 4 Jun 2025 09:47:25 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 4 Jun 2025 09:47:25 -0500    

The documentation for the pg_authid system catalog and the  
pg_shadow system view indicates that passwords might be stored in  
cleartext, but that hasn't been possible for some time.  
  
Oversight in commit eb61136dc7.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aD2yKkZro4nbl5ol%40nathan  
Backpatch-through: 13  

commit   : 30c15987d9b7ecc93674cf8ade0ad53ac265ec3b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Jun 2025 15:27:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Jun 2025 15:27:44 +0200    

The previous description listed the constraint types that this column  
was used for, but that was outdated, since not-valid not-null  
constraints are now possible.  So just remove that qualification,  
rather than trying to keep it updated.  
  
Author: jian he <jian.universality@gmail.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://www.postgresql.org/message-id/flat/CACJufxFo4yTwzbSZrP%2BzQiR6_M00skoZMFaUnNJCdY6he%3DuQfA%40mail.gmail.com  

commit   : 48814415d5aa0baa31622dd1ede9012e66232ca0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Jun 2025 12:03:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Jun 2025 12:03:25 +0200    

Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://www.postgresql.org/message-id/flat/CAKAnmmKwiMHik5AHmBEdf5vqzbOBbcwEPHo4-PioWeAbzwcTOQ%40mail.gmail.com  

commit   : f777d773878ddda3388bb18dbcb93e97a0fb52e2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Jun 2025 11:21:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Jun 2025 11:21:24 +0200    

Commit 4f7f7b03758 implemented the extension_control_path GUC, and to  
make it work it was decided that we should strip the $libdir/ on  
module_pathname from .control files, so that extensions don't need to  
worry about this change.  
  
This strip logic was implemented on expand_dynamic_library_name()  
which works fine when executing the SQL functions from extensions, but  
this function is also called when the LOAD command is executed, and  
since the user may explicitly pass the $libdir prefix on LOAD  
parameter, we should not strip in this case.  
  
This commit fixes this issue by moving the strip logic from  
expand_dynamic_library_name() to load_external_function() that is  
called when the running the SQL script from extensions.  
  
Reported-by: Evan Si <evsi@amazon.com>  
Author: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Rahila Syed <rahilasyed90@gmail.com>  
Bug: #18920  
Discussion: https://www.postgresql.org/message-id/flat/18920-b350b1c0a30af006%40postgresql.org  

commit   : 7f3381c7ee661e552634f06509a3452988a15845    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Jun 2025 09:01:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Jun 2025 09:01:29 +0900    

When the backend reads COPY data, it ignores all sync messages, as per  
c01641f8aed0.  With psql pipelines, it is possible to manually send sync  
messages with \sendpipeline which leaves the frontend in an  
unrecoverable state as the backend will not send the necessary  
ReadyForQuery message that is expected to feed psql result consumption  
logic.  
  
It could be possible to artificially reduce the piped_syncs and  
requested_results, however libpq's state would still have queued sync  
messages in its command queue, and the only way to consume those without  
directly calling pqCommandQueueAdvance() is to process ReadyForQuery  
messages that won't be sent since the backend ignores these.  Perhaps  
this could be improved in the future, but I am not really excited about  
introducing this amount of complications in libpq to manipulate the  
message queues without a better use case to support it.  
  
Hence, this patch aborts the connection if we detect excessive sync  
messages after a COPY in a pipeline to avoid staying in an inconsistent  
protocol state, which is the best thing we can do with pipelines in  
psql for now.  Note that this change does not prevent wrapping a set  
of queries inside a block made of \startpipeline and \endpipeline, only  
the use of \syncpipeline for a COPY.  
  
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Discussion: https://postgr.es/m/18944-8a926c30f68387dd@postgresql.org  

commit   : 58fbfde152b28ca119fef4168550a1a4fef61560    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Jun 2025 21:38:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Jun 2025 21:38:04 +0200    

commit   : 0e164eb9f43626dc9e31f4bae26eeb3e8422584a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 3 Jun 2025 11:18:52 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 3 Jun 2025 11:18:52 -0700    

POSIX allows such platforms.  Given the lack of complaints, we may not  
currently test on such a platform.  This is new in v18 (commit  
7d5c83b4e90c7156655f98b7312a30ae5eeb4d27), so no back-patch.  

commit   : 73bdcfab35ec0a7eff1a5dd630cbad8e77054547    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Jun 2025 10:02:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Jun 2025 10:02:55 +0900    

This commit renames the GUC log_lock_failure to log_lock_failures  
to align with the existing similar setting log_lock_waits, which uses  
the plural form. This improves naming consistency across related GUCs.  
  
Suggested-by: Peter Eisentraut <peter@eisentraut.org>  
Author: Fujii Masao <masao.fujii@gmail.com  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/7a8198b6-d5b8-4910-b41e-8d3efcbb015d@eisentraut.org  

commit   : aa87f69c009a062685f0c984dbcc18e60c02920d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jun 2025 15:22:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jun 2025 15:22:44 -0400    

We store values for these options as array elements with the syntax  
"name=value", hence a name containing "=" confuses matters when  
it's time to read the array back in.  Since validation of the  
options is often done (long) after this conversion to array format,  
that leads to confusing and off-point error messages.  We can  
improve matters by rejecting names containing "=" up-front.  
  
(Probably a better design would have involved pairs of array  
elements, but it's too late now --- and anyway, there's no  
evident use-case for option names like this.  We already  
reject such names in some other contexts such as GUCs.)  
  
Reported-by: Chapman Flack <jcflack@acm.org>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Chapman Flack <jcflack@acm.org>  
Discussion: https://postgr.es/m/6830EB30.8090904@acm.org  
Backpatch-through: 13  

commit   : 31a7e175fd8f6079555f2bba95c7cc118236bb20    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 2 Jun 2025 10:54:07 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 2 Jun 2025 10:54:07 -0400    

052026c9b9 mistakenly reordered setup steps in heap_vacuum_rel(),  
incorrectly moving RelationGetNumberOfBlocks() before  
vacuum_get_cutoffs().  
  
OldestXmin must be determined before RelationGetNumberOfBlocks()  
calculates the number of blocks in the relation that will be vacuumed.  
Otherwise tuples older than OldestXmin may be inserted into the end of  
the relation into blocks that are not vacuumed. If additional tuples  
newer than those inserted into unscanned blocks but older than  
OldestXmin are inserted into free space earlier in the relation, the  
result could be advancing pg_class.relfrozenxid to a newer value than an  
unfrozen XID in one of the unscanned heap pages.  
  
Assigning an incorrect relfrozenxid can lead to data loss, so it is  
imperative that it correctly reflect the oldest unfrozen xid.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-WzntqvVEdbbpqG5JqSZGuLWmy4PBfUO-OswfivKchr2gvw%40mail.gmail.com  

commit   : fc32be3c941f9d98dd9f549153a5fcea6c3e9b8b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Jun 2025 10:12:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Jun 2025 10:12:58 +0200    

Fixes for return type of dclist_count().  

commit   : 32edf732e8dc9eb3e7a923aeb67d49246744a20a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Jun 2025 08:33:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 2 Jun 2025 08:33:04 +0200    

Commit 7406ab623fe added a gist support function that we internally  
refer to by the symbol GIST_STRATNUM_PROC.  This translated from  
"well-known" strategy numbers to opfamily-specific strategy numbers.  
However, we later (commit 630f9a43cec) changed this to fit into  
index-AM-level compare type mapping, so this function actually now  
maps from compare type to opfamily-specific strategy numbers.  So this  
name is no longer fitting.  
  
Moreover, the index AM level also supports the opposite, a function to  
map from strategy number to compare type.  This is currently not  
supported in gist, but one might wonder what this function is supposed  
to be called when it is added.  
  
This patch changes the naming of the gist-level functionality to be  
more in line with the index-AM-level functionality.  This makes sense  
because these are essentially the same thing on different levels.  
This also changes the names of the externally visible functions that  
are provided for use as such a support function.  
  
Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://www.postgresql.org/message-id/37ebb1d9-9036-485f-a215-e55435689917%40eisentraut.org  

commit   : 5231ed8262c94936a69bce41f64076630bbd99a2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Jun 2025 12:03:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Jun 2025 12:03:59 +0900    

A cascading WAL sender doing logical decoding (as known as doing its  
work on a standby) has been using as flush LSN the value returned by  
GetStandbyFlushRecPtr() (last position safely flushed to disk).  This is  
incorrect as such processes are only able to decode changes up to the  
LSN that has been replayed by the startup process.  
  
This commit changes cascading logical WAL senders to use the replay LSN,  
as returned by GetXLogReplayRecPtr().  This distinction is important  
particularly during shutdown, when WAL senders need to send any  
remaining available data to their clients, switching WAL senders to a  
caught-up state.  Using the latest flush LSN rather than the replay LSN  
could cause the WAL senders to be stuck in an infinite loop preventing  
them to shut down, as the startup process does not run when WAL senders  
attempt to catch up, so they could keep waiting for work that would  
never happen.  
  
Backpatch down to v16, where logical decoding on standbys has been  
introduced.  
  
Author: Alexey Makhmutov <a.makhmutov@postgrespro.ru>  
Reviewed-by: Ajin Cherian <itsajin@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/52138028-7246-421c-9161-4fa108b88070@postgrespro.ru  
Backpatch-through: 16  

commit   : c98975ba85f64ad95368575cf419813bfb8027b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jun 2025 14:58:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jun 2025 14:58:42 -0400    

commit   : 4672b6223910687b2aab075bcd2dd54ce90d5171    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jun 2025 14:55:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jun 2025 14:55:24 -0400    

Clean up after rearranging PG_TRY blocks.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2954090.1748723636@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : c6f7f11d8f4cd28a83c638c3bc3758c1c091657b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jun 2025 14:48:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jun 2025 14:48:35 -0400    

PLy_elog_impl and its subroutine PLy_traceback intended to avoid  
leaking any PyObject reference counts, but their coverage of the  
matter was sadly incomplete.  In particular, out-of-memory errors  
in most of the string-construction subroutines could lead to  
reference count leaks, because those calls were outside the  
PG_TRY blocks responsible for dropping reference counts.  
  
Fix by (a) adjusting the scopes of the PG_TRY blocks, and  
(b) moving the responsibility for releasing the reference counts  
of the traceback-stack objects to PLy_elog_impl.  This requires  
some additional "volatile" markers, but not too many.  
  
In passing, fix an ancient thinko: use of the "e_module_o" PyObject  
was guarded by "if (e_type_s)", where surely "if (e_module_o)"  
was meant.  This would only have visible consequences if the  
"__name__" attribute were present but the "__module__" attribute  
wasn't, which apparently never happens; but someday it might.  
  
Rearranging the PG_TRY blocks requires indenting a fair amount  
of code one more tab stop, which I'll do separately for clarity.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2954090.1748723636@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : e5a3c9d9b5ce535151d3a7e3173e8d27d2d8cd58    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 1 Jun 2025 17:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 1 Jun 2025 17:30:00 +0900    

Previously, postgres_fdw always 1) opened a remote transaction in READ  
WRITE mode even when the local transaction was READ ONLY, causing a READ  
ONLY transaction using it that references a foreign table mapped to a  
remote view executing a volatile function to write in the remote side,  
and 2) opened the remote transaction in NOT DEFERRABLE mode even when  
the local transaction was DEFERRABLE, causing a SERIALIZABLE READ ONLY  
DEFERRABLE transaction using it to abort due to a serialization failure  
in the remote side.  
  
To avoid these, modify postgres_fdw to open a remote transaction in the  
same access/deferrable modes as the local transaction.  This commit also  
modifies it to open a remote subtransaction in the same access mode as  
the local subtransaction.  
  
Although these issues exist since the introduction of postgres_fdw,  
there have been no reports from the field.  So it seems fine to just fix  
them in master only.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAPmGK16n_hcUUWuOdmeUS%2Bw4Q6dZvTEDHb%3DOP%3D5JBzo-M3QmpQ%40mail.gmail.com  

commit   : b006bcd5310eb2dad0828a286b79babce4953143    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:12:58 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:12:58 +0100    

When a MERGE's target table is the parent of an inheritance tree, any  
INSERT actions insert into the parent table using ModifyTableState's  
rootResultRelInfo. However, there are two bugs in the way is  
initialized:  
  
1. ExecInitMerge() incorrectly uses a different ResultRelInfo entry  
from ModifyTableState's resultRelInfo array to build the insert  
projection, which may not be compatible with rootResultRelInfo.  
  
2. ExecInitModifyTable() does not fully initialize rootResultRelInfo.  
Specifically, ri_WithCheckOptions, ri_WithCheckOptionExprs,  
ri_returningList, and ri_projectReturning are not initialized.  
  
This can lead to crashes, or incorrect query results due to failing to  
check WCO's or process the RETURNING list for INSERT actions.  
  
Fix both these bugs in ExecInitMerge(), noting that it is only  
necessary to fully initialize rootResultRelInfo if the MERGE has  
INSERT actions and the target table is a plain inheritance parent.  
  
Backpatch to v15, where MERGE was introduced.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Jian He <jian.universality@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/4rlmjfniiyffp6b3kv4pfy4jw3pciy6mq72rdgnedsnbsx7qe5@j5hlpiwdguvc  
Backpatch-through: 15  

commit   : e050af28686e796bdf22cb53fe3fdf1c6655f315    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 31 May 2025 09:40:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 31 May 2025 09:40:45 +0900    

uint64 was chosen to be consistent with the type used by the query ID,  
but the conclusion of a recent discussion for the query ID is that int64  
is a better fit as the signed form is shown to the user, for PGSS or  
EXPLAIN outputs.  
  
This commit changes the plan ID to use int64, following c3eda50b0648  
that has done the same for the query ID.  
  
The plan ID is new to v18, introduced in 2a0cd38da5cc.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/aCvzJNwetyEI3Sgo@paquier.xyz  

commit   : 706054b11b959c865c0c7935c34d92370d7168d4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 30 May 2025 15:17:28 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 30 May 2025 15:17:28 -0500    

A few places that access system catalogs don't set up an active  
snapshot before potentially accessing their TOAST tables.  To fix,  
push an active snapshot just before each section of code that might  
require accessing one of these TOAST tables, and pop it shortly  
afterwards.  While at it, this commit adds some rather strict  
assertions in an attempt to prevent such issues in the future.  
  
Commit 16bf24e0e4 recently removed pg_replication_origin's TOAST  
table in order to fix the same problem for that catalog.  On the  
back-branches, those bugs are left in place.  We cannot easily  
remove a catalog's TOAST table on released major versions, and only  
replication origins with extremely long names are affected.  Given  
the low severity of the issue, fixing older versions doesn't seem  
worth the trouble of significantly modifying the patch.  
  
Also, on v13 and v14, the aforementioned strict assertions have  
been omitted because commit 2776922201, which added  
HaveRegisteredOrActiveSnapshot(), was not back-patched.  While we  
could probably back-patch it now, I've opted against it because it  
seems unlikely that new TOAST snapshot issues will be introduced in  
the oldest supported versions.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/18127-fe54b6a667f29658%40postgresql.org  
Discussion: https://postgr.es/m/18309-c0bf914950c46692%40postgresql.org  
Discussion: https://postgr.es/m/ZvMSUPOqUU-VNADN%40nathan  
Backpatch-through: 13