PostgreSQL 17.6 commit log

commit   : 7885b94dd81b98bbab9ed878680d156df7bf857f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:04:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:04:51 -0400    

commit   : 86ad5a84c76b0ed1cf9ddb1d88f7204a9a076051    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 15:37:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 15:37:32 -0400    

Security: CVE-2025-8713, CVE-2025-8714, CVE-2025-8715  

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

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

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

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

commit   : ac4c0d3451093d339327aeca4e5b8f89622c6265    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:40:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:40:51 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 4f9af069289c30fc32337b844fb1db25d7b11e9b  

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

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

commit   : 024123a0d38e3f3fdcbab411eb01cba4b36adc86    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Aug 2025 16:31:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Aug 2025 16:31:53 -0400    

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

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

commit   : b70d9de77f337828ca3a0a3064a6827b1ce68977    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Aug 2025 13:47:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Aug 2025 13:47:04 -0400    

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

commit   : be26c77ef9b8613a2583853b9dd7097c5d373f48    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Aug 2025 13:27:32 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Aug 2025 13:27:32 +0200    

Backpatch of the relevant parts of commit 50fd428b2b9 for consistency.  

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

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

commit   : 21ae8fc5fd8698fc47ac1aa9c82e32713d6669be    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:13:55 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:13:55 +0700    

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

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

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

commit   : 753177604b33df4cb9f32dd9db6f829ae733c41f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Aug 2025 16:48:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Aug 2025 16:48:47 +0900    

ALTER TABLE ... SET EXPRESSION AS removes statistics for the target column,  
so running ANALYZE afterward is recommended. But this was previously not  
documented, even though a similar recommendation exists for  
ALTER TABLE ... SET DATA TYPE, which also clears the column's statistics.  
This commit updates the documentation to include the ANALYZE recommendation  
for SET EXPRESSION AS.  
  
Since v18, virtual generated columns are supported, and these columns never  
have statistics. Therefore, ANALYZE is not needed after SET DATA TYPE or  
SET EXPRESSION AS when used on virtual generated columns. This commit also  
updates the documentation to clarify that ANALYZE is unnecessary in such cases.  
  
Back-patch the ANALYZE recommendation for SET EXPRESSION AS to v17  
where the feature was introduced, and the note about virtual generated  
columns to v18 where those columns were added.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/20250804151418.0cf365bd2855d606763443fe@sraoss.co.jp  
Backpatch-through: 17  

commit   : 0b0d3c19bf077e96ac4a175bf7ea7093e0eac416    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Aug 2025 16:51:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Aug 2025 16:51:10 -0400    

The result of "DirectFunctionCall1(numeric_float8, d)" is already in  
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()  
to it.  On machines where float8 is pass-by-reference, this would  
result in complete garbage, since an unpredictable pointer value  
would be treated as an integer and then converted to float.  It's not  
entirely clear how much of a problem would ensue on 64-bit hardware,  
but certainly interpreting a float8 bitpattern as uint64 and then  
converting that to float isn't the intended behavior.  
  
As luck would have it, even the complete-garbage case doesn't break  
BRIN indexes, since the results are only used to make choices about  
how to merge values into ranges: at worst, we'd make poor choices  
resulting in an inefficient index.  Doubtless that explains the lack  
of field complaints.  However, users with BRIN indexes that use the  
numeric_minmax_multi_ops opclass may wish to reindex in hopes of  
making their indexes more efficient.  
  
Author: Peter Eisentraut <peter@eisentraut.org>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2093712.1753983215@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 74dffe5c14ac0c2e1d993968e7baa7d0cb965e8c    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 4 Aug 2025 15:07:08 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 4 Aug 2025 15:07:08 -0400    

Import usleep, which, due to an oversight in oversight in commit  
48796a98d5ae was used but not imported.  
  
Correct the comparison string used in two logfile checks. Previously, it  
was incorrect and thus the test could never have failed.  
  
Also wordsmith a comment to make it clear when hot_standby_feedback is  
meant to be on during the test scenarios.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/flat/CAAKRu_YO2mEm%3DZWZKPjTMU%3DgW5Y83_KMi_1cr51JwavH0ctd7w%40mail.gmail.com  
Backpatch-through: 16  

commit   : 191110b8ff6266af0d690057d7003d1971097d4b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:21:31 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:21:31 +0100    

Introduced by 578b229718e.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAEZATCV_CzRSOPMf1gbHQ7xTmyrV6kE7ViCBD6B81WF7GfTAEA@mail.gmail.com  
Backpatch-through: 13  

commit   : f71fa981c96dc5672b0aca671a9898a36fa6d19b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 4 Aug 2025 20:51:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 4 Aug 2025 20:51:42 +0900    

Previously, enabling sync_replication_slots while wal_level was not set  
to logical could cause the server to shut down. This was because  
the postmaster performed a configuration check before launching  
the slot synchronization worker and raised an ERROR if the settings  
were incompatible. Since ERROR is treated as FATAL in the postmaster,  
this resulted in the entire server shutting down unexpectedly.  
  
This commit changes the postmaster to log that message with a LOG-level  
instead of raising an ERROR, allowing the server to continue running  
even with the misconfiguration.  
  
Back-patch to v17, where slot synchronization was introduced.  
  
Reported-by: Hugo DUBOIS <hdubois@scaleway.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Hugo DUBOIS <hdubois@scaleway.com>  
Reviewed-by: Shveta Malik <shveta.malik@gmail.com>  
Discussion: https://postgr.es/m/CAH0PTU_pc3oHi__XESF9ZigCyzai1Mo3LsOdFyQA4aUDkm01RA@mail.gmail.com  
Backpatch-through: 17  

commit   : a9b4b0665d4599f4cbc441032a01fcfdab741613    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 4 Aug 2025 13:26:45 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 4 Aug 2025 13:26:45 +0200    

It's possible to use a CHECK (col IS NOT NULL) constraint to skip  
scanning a table for nulls when adding a NOT NULL constraint on the same  
column.  However, if the CHECK constraint is dropped on the same command  
that the NOT NULL is added, this fails, i.e., makes the NOT NULL addition  
slow.  The best we can do about it at this stage is to document this so  
that users aren't taken by surprise.  
  
(In Postgres 18 you can directly add the NOT NULL constraint as NOT  
VALID instead, so there's no longer much use for the CHECK constraint,  
therefore no point in building mechanism to support the case better.)  
  
Reported-by: Andrew <psy2000usa@yahoo.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/175385113607.786.16774570234342968908@wrigleys.postgresql.org  

commit   : 398e07162eca184c990c92fb69a50a993a723bb6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sun, 3 Aug 2025 10:49:03 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sun, 3 Aug 2025 10:49:03 +0900    

Previously, when running pgbench in pipeline mode with a custom script  
that triggered retriable errors (e.g., serialization errors),  
an assertion failure could occur:  
  
    Assertion failed: (res == ((void*)0)), function discardUntilSync, file pgbench.c, line 3515.  
  
The root cause was that pgbench incorrectly assumed only a single  
pipeline sync message would be received at the end. In reality,  
multiple pipeline sync messages can be sent and must be handled properly.  
  
This commit fixes the issue by updating pgbench to correctly process  
multiple pipeline sync messages, preventing the assertion failure.  
  
Back-patch to v15, where the bug was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Tatsuo Ishii <ishii@postgresql.org>  
Discussion: https://postgr.es/m/CAHGQGwFAX56Tfx+1ppo431OSWiLLuW72HaGzZ39NkLkop6bMzQ@mail.gmail.com  
Backpatch-through: 15  

commit   : 59a984e637c8dd27ee7dce0aaa0bb06c281cb716    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:01 +0900    

It was not very clear that the triggers are only allowed on plain tables  
(not foreign tables).  Also, rephrase the documentation for better  
readability.  
  
Follow up to commit 9e6104c66.  
  
Reported-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com>  
Discussion: https://postgr.es/m/CAPmGK16XBs9ptNr8Lk4f-tJZogf6y-Prz%3D8yhvJbb_4dpsc3mQ%40mail.gmail.com  
Backpatch-through: 13  

commit   : 9e0b4b1ab5ef3f34013375b16bb6689e33f67aa5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 2 Aug 2025 17:08:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 2 Aug 2025 17:08:50 +0900    

In ReorderBufferProcessTXN(), used to send the data of a transaction to  
an output plugin, INSERT ON CONFLICT changes (INTERNAL_SPEC_INSERT) are  
delayed until a confirmation record arrives (INTERNAL_SPEC_CONFIRM),  
updating the change being processed.  
  
8c58624df462 has added an extra step after processing a change to update  
the progress of the transaction, by calling the callback  
update_progress_txn() based on the LSN stored in a change after a  
threshold of CHANGES_THRESHOLD (100) is reached.  This logic has missed  
the fact that for an INSERT ON CONFLICT change the data is freed once  
processed, hence update_progress_txn() could be called pointing to a LSN  
value that's already been freed.  This could result in random crashes,  
depending on the workload.  
  
Per discussion, this issue is fixed by reusing in update_progress_txn()  
the LSN from the change processed found at the beginning of the loop,  
meaning that for a INTERNAL_SPEC_CONFIRM change the progress is updated  
using the LSN of the INTERNAL_SPEC_CONFIRM change, and not the LSN from  
its INTERNAL_SPEC_INSERT change.  This is actually more correct, as we  
want to update the progress to point to the INTERNAL_SPEC_CONFIRM  
change.  
  
Masahiko Sawada has found a nice trick to reproduce the issue: hardcode  
CHANGES_THRESHOLD at 1 and run test_decoding (test "ddl" being enough)  
on an instance running valgrind.  The bug has been analyzed by Ethan  
Mertz, who also originally suggested the solution used in this patch.  
  
Issue introduced by 8c58624df462, so backpatch down to v16.  
  
Author: Ethan Mertz <ethan.mertz@gmail.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/aIsQqDZ7x4LAQ6u1@paquier.xyz  
Backpatch-through: 16  

commit   : 39ff056365e438b530498def7ef18d588129e8e0    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 1 Aug 2025 16:52:11 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 1 Aug 2025 16:52:11 -0500    

Currently, ALTER DATABASE/ROLE/SYSTEM RESET [ALL] with an unknown  
custom GUC with a prefix reserved by MarkGUCPrefixReserved() errors  
(unless a superuser runs a RESET ALL variant).  This is problematic  
for cases such as an extension library upgrade that removes a GUC.  
To fix, simply make sure the relevant code paths explicitly allow  
it.  Note that we require superuser or privileges on the parameter  
to reset it.  This is perhaps a bit more restrictive than is  
necessary, but it's not clear whether further relaxing the  
requirements is safe.  
  
Oversight in commit 88103567cb.  The ALTER SYSTEM fix is dependent  
on commit 2d870b4aef, which first appeared in v17.  Unfortunately,  
back-patching that commit would introduce ABI breakage, and while  
that breakage seems unlikely to bother anyone, it doesn't seem  
worth the risk.  Hence, the ALTER SYSTEM part of this commit is  
omitted on v15 and v16.  
  
Reported-by: Mert Alev <mert@futo.org>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/18964-ba09dea8c98fccd6%40postgresql.org  
Backpatch-through: 15  

commit   : 8c298324a4f3c26138b3d31248e6bd9d627963b5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 06:53:16 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 06:53:16 +0000    

A deadlock can occur when the DDL command and the apply worker acquire  
catalog locks in different orders while dropping replication origins.  
  
The issue is rare in PG16 and higher branches because, in most cases, the  
tablesync worker performs the origin drop in those branches, and its  
locking sequence does not conflict with DDL operations.  
  
This patch ensures consistent lock acquisition to prevent such deadlocks.  
  
As per buildfarm.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Ajin Cherian <itsajin@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/bab95e12-6cc5-4ebb-80a8-3e41956aa297@gmail.com  

commit   : 1ca1889ea6a31e4b4f128e849c614959090f2c1c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 31 Jul 2025 06:37:56 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 31 Jul 2025 06:37:56 -0700    

pg_dump sorts objects by their logical names, e.g. (nspname, relname,  
tgname), before dependency-driven reordering.  That removes one source  
of logically-identical databases differing in their schema-only dumps.  
In other words, it helps with schema diffing.  The logical name sort  
ignored essential sort keys for constraints, operators, PUBLICATION  
... FOR TABLE, PUBLICATION ... FOR TABLES IN SCHEMA, operator classes,  
and operator families.  pg_dump's sort then depended on object OID,  
yielding spurious schema diffs.  After this change, OIDs affect dump  
order only in the event of catalog corruption.  While pg_dump also  
wrongly ignored pg_collation.collencoding, CREATE COLLATION restrictions  
have been keeping that imperceptible in practical use.  
  
Use techniques like we use for object types already having full sort key  
coverage.  Where the pertinent queries weren't fetching the ignored sort  
keys, this adds columns to those queries and stores those keys in memory  
for the long term.  
  
The ignorance of sort keys became more problematic when commit  
172259afb563d35001410dc6daad78b250924038 added a schema diff test  
sensitive to it.  Buildfarm member hippopotamus witnessed that.  
However, dump order stability isn't a new goal, and this might avoid  
other dump comparison failures.  Hence, back-patch to v13 (all supported  
versions).  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20250707192654.9e.nmisch@google.com  
Backpatch-through: 13  

commit   : 5dd4957b28df92d25508e4d0c950099c52347a75    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Nov 2024 13:30:30 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 4 Nov 2024 13:30:30 -0500    

Previously, we sorted rules by schema name and then rule name;  
if that wasn't unique, we sorted by rule OID.  This can be  
problematic for comparing dumps from databases with different  
histories, especially since certain rule names like "_RETURN"  
are very common.  Let's make the sort key schema name, rule name,  
table name, which should be unique.  (This is the same behavior  
we've long used for triggers and RLS policies.)  
  
Andreas Karlsson  
  
This back-patches v18 commit 350e6b8ea86c22c0b95c2e32a4e8d109255b5596 to  
all supported branches.  The next commit will assert that pg_dump  
provides a stable sort order for all object types.  That assertion would  
fail without stabilizing DO_RULE order as this commit did.  
  
Discussion: https://postgr.es/m/b4e468d8-0cd6-42e6-ac8a-1d6afa6e0cf1@proxel.se  
Discussion: https://postgr.es/m/20250707192654.9e.nmisch@google.com  
Backpatch-through: 13-17  

commit   : 8de56323c1396626a9d667a0dfe6e1c3a8ca1637    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:47 +0900    

The configure checks used two incorrect functions when checking the  
presence of some routines in an environment:  
- __get_cpuidex() for the check of __cpuidex().  
- __get_cpuid() for the check of __cpuid().  
This means that Postgres has never been able to detect the presence of  
these functions, impacting environments where these exist, like Windows.  
  
Simply fixing the function name does not work.  For example, using  
configure with MinGW on Windows causes the checks to detect all four of  
__get_cpuid(), __get_cpuid_count(), __cpuidex() and __cpuid() to be  
available, causing a compilation failure as this messes up with the  
MinGW headers as we would include both <intrin.h> and <cpuid.h>.  
  
The Postgres code expects only one in { __get_cpuid() , __cpuid() } and  
one in { __get_cpuid_count() , __cpuidex() } to exist.  This commit  
reshapes the configure checks to do exactly what meson is doing, which  
has been working well for us: check one, then the other, but never allow  
both to be detected in a given build.  
  
The logic is wrong since 3dc2d62d0486 and 792752af4eb5 where these  
checks have been introduced (the second case is most likely a copy-pasto  
coming from the first case), with meson documenting that the configure  
checks were broken.  As far as I can see, they are not once applied  
consistently with what the code expects, but let's see if the buildfarm  
has different something to say.  The comment in meson.build is adjusted  
as well, to reflect the new reality.  
  
Author: Lukas Fittl <lukas@fittl.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aIgwNYGVt5aRAqTJ@paquier.xyz  
Backpatch-through: 13  

commit   : a644f5fc66a36ff7c630b8480901b6057243da2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jul 2025 15:17:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jul 2025 15:17:41 -0400    

For many optional libraries, we extract the -L and -l switches needed  
to link the library from a helper program such as llvm-config.  In  
some cases we put the resulting -L switches into LDFLAGS ahead of  
-L switches specified via --with-libraries.  That risks breaking  
the user's intention for --with-libraries.  
  
It's not such a problem if the library's -L switch points to a  
directory containing only that library, but on some platforms a  
library helper may "helpfully" offer a switch such as -L/usr/lib  
that points to a directory holding all standard libraries.  If the  
user specified --with-libraries in hopes of overriding the standard  
build of some library, the -L/usr/lib switch prevents that from  
happening since it will come before the user-specified directory.  
  
To fix, avoid inserting these switches directly into LDFLAGS during  
configure, instead adding them to LIBDIRS or SHLIB_LINK.  They will  
still eventually get added to LDFLAGS, but only after the switches  
coming from --with-libraries.  
  
The same problem exists for -I switches: those coming from  
--with-includes should appear before any coming from helper programs  
such as llvm-config.  We have not heard field complaints about this  
case, but it seems certain that a user attempting to override a  
standard library could have issues.  
  
The changes for this go well beyond configure itself, however,  
because many Makefiles have occasion to manipulate CPPFLAGS to  
insert locally-desirable -I switches, and some of them got it wrong.  
The correct ordering is any -I switches pointing at within-the-  
source-tree-or-build-tree directories, then those from the tree-wide  
CPPFLAGS, then those from helper programs.  There were several places  
that risked pulling in a system-supplied copy of libpq headers, for  
example, instead of the in-tree files.  (Commit cb36f8ec2 fixed one  
instance of that a few months ago, but this exercise found more.)  
  
The Meson build scripts may or may not have any comparable problems,  
but I'll leave it to someone else to investigate that.  
  
Reported-by: Charles Samborski <demurgos@demurgos.net>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/70f2155f-27ca-4534-b33d-7750e20633d7@demurgos.net  
Backpatch-through: 13  

commit   : 7571e0f6e924d9387a743a615f5c700af9214f6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jul 2025 12:47:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jul 2025 12:47:19 -0400    

When I prepared 71c0921b6 et al yesterday, I was thinking that the  
logic involving explicitly freeing the node_list output was still  
needed to dodge leakage bugs in libxml2.  But I was misremembering:  
we introduced that only because with early 2.13.x releases we could  
not trust xmlParseBalancedChunkMemory's result code, so we had to  
look to see if a node list was returned or not.  There's no reason  
to believe that xmlParseBalancedChunkMemory will fail to clean up  
the node list when required, so simplify.  (This essentially  
completes reverting all the non-cosmetic changes in 6082b3d5d.)  
  
Reported-by: Jim Jones <jim.jones@uni-muenster.de>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/997668.1753802857@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 3c05d4d3433e1bd4097f39fed2a9398cb2e662db    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Jul 2025 10:41:13 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Jul 2025 10:41:13 +0300    

This commit documents differences in the definition of word separators for  
the initcap function between libc and ICU locale providers.  
Backpatch to all supported branches.  
  
Discussion: https://postgr.es/m/804cc10ef95d4d3b298e76b181fd9437%40postgrespro.ru  
Author: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>  
Backpatch-through: 13  

commit   : fd4ad33fe223c17ba90de2d2441b81b6deccc21b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jul 2025 16:50:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jul 2025 16:50:41 -0400    

This mostly reverts commit 6082b3d5d, "Use xmlParseInNodeContext  
not xmlParseBalancedChunkMemory".  It turns out that  
xmlParseInNodeContext will reject text chunks exceeding 10MB, while  
(in most libxml2 versions) xmlParseBalancedChunkMemory will not.  
The bleeding-edge libxml2 bug that we needed to work around a year  
ago is presumably no longer a factor, and the argument that  
xmlParseBalancedChunkMemory is semi-deprecated is not enough to  
justify a functionality regression.  Hence, go back to doing it  
the old way.  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Author: Michael Paquier <michael@paquier.xyz>  
Co-authored-by: Erik Wienhold <ewie@ewie.name>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aIGknLuc8b8ega2X@paquier.xyz  
Backpatch-through: 13  

commit   : 13559de95383b493a6e6384dcb621947bb8bcc23    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 27 Jul 2025 15:10:01 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 27 Jul 2025 15:10:01 +0300    

If the number of sync requests is big enough, the palloc() call in  
AbsorbSyncRequests() will attempt to allocate more than 1 GB of memory,  
resulting in failure.  This can lead to an infinite loop in the checkpointer  
process, as it repeatedly fails to absorb the pending requests.  
  
This commit limits the checkpointer requests queue size to 10M items. In  
addition to preventing the palloc() failure, this change helps to avoid long  
queue processing time.  
  
Also, this commit is for backpathing only.  The master branch receives  
a more invasive yet comprehensive fix for this problem.  
  
Discussion: https://postgr.es/m/db4534f83a22a29ab5ee2566ad86ca92%40postgrespro.ru  
Backpatch-through: 13  

commit   : 967309116f0d2cda20228229b2fd212948fd0385    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jul 2025 08:36:31 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jul 2025 08:36:31 +0000    

Previously, the tool could replay the same transaction twice, once during  
recovery, then again during replication after the subscriber was set up.  
  
This occurred because the same recovery_target_lsn was used both to  
finalize recovery and to start replication. If  
recovery_target_inclusive = true, the transaction at that LSN would be  
applied during recovery and then sent again by the publisher leading to  
duplication.  
  
To prevent this, we now set recovery_target_inclusive = false. This  
ensures the transaction at recovery_target_lsn is not reapplied during  
recovery, avoiding duplication when replication begins.  
  
Bug #18897  
Reported-by: Zane Duffield <duffieldzane@gmail.com>  
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/18897-d3db67535860dddb@postgresql.org  

commit   : 635a856279ef55074dfc7a2a96c7fd686b5ff015    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jul 2025 15:44:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jul 2025 15:44:29 -0400    

Solaris has never bothered to add "const" to the second argument  
of PAM conversation procs, as all other Unixen did decades ago.  
This resulted in an "incompatible pointer" compiler warning when  
building --with-pam, but had no more serious effect than that,  
so we never did anything about it.  However, as of GCC 14 the  
case is an error not warning by default.  
  
To complicate matters, recent OpenIndiana (and maybe illumos  
in general?) *does* supply the "const" by default, so we can't  
just assume that platforms using our solaris template need help.  
  
What we can do, short of building a configure-time probe,  
is to make solaris.h #define _PAM_LEGACY_NONCONST, which  
causes OpenIndiana's pam_appl.h to revert to the traditional  
definition, and hopefully will have no effect anywhere else.  
Then we can use that same symbol to control whether we include  
"const" in the declaration of pam_passwd_conv_proc().  
  
Bug: #18995  
Reported-by: Andrew Watkins <awatkins1966@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18995-82058da9ab4337a7@postgresql.org  
Backpatch-through: 13  

commit   : d331243dc95dbae2474ef42492307c63b7eea2a2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:34:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:34:22 +0900    

This index AM callback has been introduced in c1ec02be1d79 and it is  
optional, currently only being used by BRIN.  Optional callbacks are  
documented with NULL as possible value in amapi.h and indexam.sgml, but  
this callback has missed this part of the description.  
  
Reported-by: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/CAHut+PvgYcPmPDi1YdHMJY5upnyGRpc0N8pk1xNB11xDSBwNog@mail.gmail.com  
Backpatch-through: 17  

commit   : 2805e1c1edd5f5c59d40f85f8a32d26f9ccb10a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:05 +0900    

ECPGconnect() caches established connections to the server, supporting  
the case of a NULL connection name when a database name is not specified  
by its caller.  
  
A follow-up call to ECPGget_PGconn() to get an established connection  
from the cached set with a non-NULL name could cause a NULL pointer  
dereference if a NULL connection was listed in the cache and checked for  
a match.  At least two connections are necessary to reproduce the issue:  
one with a NULL name and one with a non-NULL name.  
  
Author:  Aleksander Alekseev <aleksander@tigerdata.com>  
Discussion: https://postgr.es/m/CAJ7c6TNvFTPUTZQuNAoqgzaSGz-iM4XR61D7vEj5PsQXwg2RyA@mail.gmail.com  
Backpatch-through: 13  

commit   : 6b755d8d70b2ceffeb4798cbb6907d2704c2e6c4    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 21 Jul 2025 11:34:10 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 21 Jul 2025 11:34:10 +0200    

Commit e5da0fe3c22b introduced catalog entries for not-null constraints  
on domains; but because commit b0e96f311985 (the original work for  
catalogued not-null constraints on tables) forgot to teach pg_dump to  
process the comments for them, this one also forgot.  Add that now.  
  
We also need to teach repairDependencyLoop() about the new type of  
constraints being possible for domains.  
  
Backpatch-through: 17  
Co-authored-by: jian he <jian.universality@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: jian he <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CACJufxF-0bqVR=j4jonS6N2Ka6hHUpFyu3_3TWKNhOW_4yFSSg@mail.gmail.com  

commit   : 227d0ce18af90f89a9e886ddbc0bb8aaf2ec2750    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sun, 20 Jul 2025 11:58:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sun, 20 Jul 2025 11:58:31 +0900    

When pg_recvlogical receives a SIGHUP signal, it closes the current  
output file and reopens a new one. This is useful since it allows us to  
rotate the output file by renaming the current file and sending a SIGHUP.  
  
This behavior was previously undocumented. This commit adds  
the missing documentation.  
  
Back-patch to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>  
Discussion: https://postgr.es/m/0977fc4f-1523-4ecd-8a0e-391af4976367@oss.nttdata.com  
Backpatch-through: 13  

commit   : c9f4e7520603836b924a218a34633f545c0173f3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 19 Jul 2025 13:44:01 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 19 Jul 2025 13:44:01 +0300    

If a crash occurs while writing a WAL record that spans multiple pages, the  
recovery process marks the page with the XLP_FIRST_IS_OVERWRITE_CONTRECORD  
flag.  However, logical decoding currently attempts to read the full WAL  
record based on its expected size before checking this flag, which can lead  
to an infinite wait if the remaining data is never written (e.g., no activity  
after crash).  
  
This patch updates the logic first to read the page header and check for  
the XLP_FIRST_IS_OVERWRITE_CONTRECORD flag before attempting to reconstruct  
the full WAL record.  If the flag is set, decoding correctly identifies  
the record as incomplete and avoids waiting for WAL data that will never  
arrive.  
  
Discussion: https://postgr.es/m/CAAKRu_ZCOzQpEumLFgG_%2Biw3FTa%2BhJ4SRpxzaQBYxxM_ZAzWcA%40mail.gmail.com  
Discussion: https://postgr.es/m/CALDaNm34m36PDHzsU_GdcNXU0gLTfFY5rzh9GSQv%3Dw6B%2BQVNRQ%40mail.gmail.com  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Backpatch-through: 13  

commit   : fd39c3cf28396d1fbb8b2a2cdb9fe66b6ad87964    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 19 Jul 2025 13:51:07 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 19 Jul 2025 13:51:07 +0300    

Currently, the comments in 047_checkpoint_physical_slot. It shows an  
incomplete intention to wait for checkpoint completion before performing  
an immediate database stop.  However, an immediate node stop can occur both  
before and after checkpoint completion.  Both cases should work correctly.  
But we would like the test to be more stable and deterministic.  This is why  
this commit makes this test explicitly wait for the checkpoint completion  
log message.  
  
Discussion: https://postgr.es/m/CAPpHfdurV-j_e0pb%3DUFENAy3tyzxfF%2ByHveNDNQk2gM82WBU5A%40mail.gmail.com  
Discussion: https://postgr.es/m/aHXLep3OaX_vRTNQ%40paquier.xyz  
Author: Alexander Korotkov <akorotkov@postgresql.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 17  

commit   : 6aefde2a2db826f363891e1cc1157f22a6c30707    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 18 Jul 2025 00:04:52 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 18 Jul 2025 00:04:52 +0300    

This commit improves 046_checkpoint_logical_slot in two aspects:  
- Add one pg_logical_emit_message() call to force the creation of a record  
  that spawns across two pages.  
- Make the logic wait for the checkpoint completion.  
  
Discussion: https://postgr.es/m/CALDaNm34m36PDHzsU_GdcNXU0gLTfFY5rzh9GSQv%3Dw6B%2BQVNRQ%40mail.gmail.com  
Author: Alexander Korotkov <akorotkov@postgresql.org>  
Co-authored-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

commit   : 91ad1bdef8e46983d82d2723c6e1c05e004f74c5    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 18 Jul 2025 10:01:31 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 18 Jul 2025 10:01:31 +0100    

If a MERGE inside a CTE attempts an UPDATE or DELETE on a table with  
BEFORE ROW triggers, and a concurrent UPDATE or DELETE happens, the  
merge code would fail (crashing in the case of an UPDATE action, and  
potentially executing the wrong action for a DELETE action).  
  
This is the same issue that 9321c79c86 attempted to fix, except now  
for a MERGE inside a CTE. As noted in 9321c79c86, what needs to happen  
is for the trigger code to exit early, returning the TM_Result and  
TM_FailureData information to the merge code, if a concurrent  
modification is detected, rather than attempting to do an EPQ  
recheck. The merge code will then do its own rechecking, and rescan  
the action list, potentially executing a different action in light of  
the concurrent update. In particular, the trigger code must never call  
ExecGetUpdateNewTuple() for MERGE, since that is bound to fail because  
MERGE has its own per-action projection information.  
  
Commit 9321c79c86 did this using estate->es_plannedstmt->commandType  
in the trigger code to detect that a MERGE was being executed, which  
is fine for a plain MERGE command, but does not work for a MERGE  
inside a CTE. Fix by passing that information to the trigger code as  
an additional parameter passed to ExecBRUpdateTriggers() and  
ExecBRDeleteTriggers().  
  
Back-patch as far as v17 only, since MERGE cannot appear inside a CTE  
prior to that. Additionally, take care to preserve the trigger ABI in  
v17 (though not in v18, which is still in beta).  
  
Bug: #18986  
Reported-by: Yaroslav Syrytsia <me@ys.lc>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/18986-e7a8aac3d339fa47@postgresql.org  
Backpatch-through: 17  

commit   : 3f10d2b66544bf285d361b956a16de3ed34f488a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Jul 2025 12:46:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Jul 2025 12:46:38 -0400    

This is the documented behavior, and it worked that way before  
v10.  However, addition of the connhost[] array created cases  
where conn->connhost[conn->whichhost].port is NULL.  The rest  
of libpq is careful to substitute DEF_PGPORT[_STR] for a null  
or empty port string, but we failed to do so here, leading to  
possibly returning NULL.  As of v18 that causes psql's \conninfo  
command to segfault.  Older psql versions avoid that, but it's  
pretty likely that other clients have trouble with this,  
so we'd better back-patch the fix.  
  
In stable branches, just revert to our historical behavior of  
returning an empty string when there was no user-given port  
specification.  However, it seems substantially more useful and  
indeed more correct to hand back DEF_PGPORT_STR in such cases,  
so let's make v18 and master do that.  
  
Author: Daniele Varrazzo <daniele.varrazzo@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CA+mi_8YTS8WPZPO0PAb2aaGLwHuQ0DEQRF0ZMnvWss4y9FwDYQ@mail.gmail.com  
Backpatch-through: 13  

commit   : 0c466f5e0b34bb9ddc53a422e9872b726f5f9620    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 17 Jul 2025 17:40:22 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 17 Jul 2025 17:40:22 +0200    

We have an assertion to ensure that a command tag has been assigned by  
the time we're done executing, but if we happen to execute a command  
with no queries, the assertion would fail.  Per discussion, rather than  
contort things to get a tag assigned, just remove the assertion.  
  
Oversight in 2f9661311b83.  That commit also retained a comment that  
explained logic that had been adjacent to it but diffused into various  
places, leaving none apt to keep part of the comment.  Remove that part,  
and rewrite what remains for extra clarity.  
  
Bug: #18984  
Backpatch-through: 13  
Reported-by: Aleksander Alekseev <aleksander@tigerdata.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Michaël Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/18984-0f4778a6599ac3ae@postgresql.org  

commit   : 7c6a3d838bae1b8b8a5a3caff8213855b9009ca2    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 17 Jul 2025 14:30:11 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 17 Jul 2025 14:30:11 +0900    

In 231b7d670b21, while copy-pasting some code into  
ExecEvalJsonCoercionFinish(), I (amitlan) accidentally introduced  
a duplicate line.  Remove it.  
  
Reported-by: Jian He <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHcf=BpmRAJcjgfjOUfV76MwKnyz1x3ErXsWL26EAFmng@mail.gmail.com  

commit   : b3abec0adeb0432a63cc34928fafa62e35efccf7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 17 Jul 2025 09:32:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 17 Jul 2025 09:32:55 +0900    

The terms used in wait_event_names.txt and lwlock.c were inconsistent  
for MultiXactOffsetSLRU and MultiXactMemberSLRU, which could cause joins  
between pg_wait_events and pg_stat_activity to fail.  lwlock.c is  
adjusted in this commit to what the historical name of the event has  
always been, and what is documented.  
  
Oversight in 53c2a97a9266.  08b9b9e043bb has fixed a similar  
inconsistency some time ago.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/aHdxN0D0hKXzHFQG@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 17  

commit   : b06a335eeb0332bec113f05ffd9da04803b0bf9b    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 17 Jul 2025 00:21:18 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 17 Jul 2025 00:21:18 +0200    

The paragraph for introducing INSERT and COPY discussed how a file  
could be used for bulk loading with COPY, without actually showing  
what the file would look like.  This adds a programlisting for the  
file contents.  
  
Backpatch to all supported branches since this example has lacked  
the file contents since PostgreSQL 7.2.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/158017814191.19852.15019251381150731439@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : d07bc7c2b3ca5454a036487f67870fa7fb73491c    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 16 Jul 2025 19:22:53 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 16 Jul 2025 19:22:53 +0200    

We skip dumping constraints together with domains if they are invalid  
('separate') so that they appear after data -- but their comments were  
dumped together with the domain definition, which in effect leads to the  
comment being dumped when the constraint does not yet exist.  Delay  
them in the same way.  
  
Oversight in 7eca575d1c28; backpatch all the way back.  
  
Author: jian he <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CACJufxF_C2pe6J_+nPr6C5jf5rQnbYP8XOKr4HM8yHZtp2aQqQ@mail.gmail.com  

commit   : c0a392c9e0ded5928e2767ae82c56c4760f9d114    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 16 Jul 2025 11:50:34 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 16 Jul 2025 11:50:34 -0500    

This adjusts the wording to match the changes in commits  
5987553fde, a233a603ba, and pgweb commit 2d764dbc08.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/aHVo791guQR6uqwT%40nathan  
Backpatch-through: 13  

commit   : 488c35f958e772fb446a8d90beaaefeb742e84a0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 16 Jul 2025 08:32:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 16 Jul 2025 08:32:52 +0900    

Previously, the documentation described the streaming option as a boolean,  
which is outdated since it's no longer a boolean as of protocol version 4.  
This could confuse users.  
  
This commit updates the description to remove the "boolean" reference and  
clearly list the valid values for the streaming option.  
  
Back-patch to v16, where the streaming option changed to a non-boolean.  
  
Author: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/8d21fb98-5c25-4dee-8387-e5a62b01ea7d@app.fastmail.com  
Backpatch-through: 16  

commit   : b70a2e8a1a0d11d2feaaa8239fd3d38e59a382e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jul 2025 18:53:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jul 2025 18:53:00 -0400    

The grammar was a little shaky and confusing here, so word-smith it  
a bit.  Also, adjust the comments in pg_ident.conf.sample to use the  
same terminology as the SGML docs, in particular "DATABASE-USERNAME"  
not "PG-USERNAME".  
  
Back-patch appropriate subsets.  I did not risk changing  
pg_ident.conf.sample in released branches, but it still seems OK  
to change it in v18.  
  
Reported-by: Alexey Shishkin <alexey.shishkin@enterprisedb.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/175206279327.3157504.12519088928605422253@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : 5a2139a9069043ae97088085b675b4099e520849    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jul 2025 18:11:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jul 2025 18:11:18 -0400    

Because not every path through JsonbIteratorNext() sets val->type,  
some compilers complain that compareJsonbContainers() is comparing  
possibly-uninitialized values.  The paths that don't set it return  
WJB_DONE, WJB_END_ARRAY, or WJB_END_OBJECT, so it's clear by  
manual inspection that the "(ra == rb)" code path is safe, and  
indeed we aren't seeing warnings about that.  But the (ra != rb)  
case is much less obviously safe.  In Assert-enabled builds it  
seems that the asserts rejecting WJB_END_ARRAY and WJB_END_OBJECT  
persuade gcc 15.x not to warn, which makes little sense because  
it's impossible to believe that the compiler can prove of its  
own accord that ra/rb aren't WJB_DONE here.  (In fact they never  
will be, so the code isn't wrong, but why is there no warning?)  
Without Asserts, the appearance of warnings is quite unsurprising.  
  
We discussed fixing this by converting those two Asserts into  
pg_assume, but that seems not very satisfactory when it's so unclear  
why the compiler is or isn't warning: the warning could easily  
reappear with some other compiler version.  Let's fix it in a less  
magical, more future-proof way by changing JsonbIteratorNext()  
so that it always does set val->type.  The cost of that should be  
pretty negligible, and it makes the function's API spec less squishy.  
  
Reported-by: Erik Rijkers <er@xs4all.nl>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/988bf1bc-3f1f-99f3-bf98-222f1cd9dc5e@xs4all.nl  
Discussion: https://postgr.es/m/0c623e8a204187b87b4736792398eaf1@postgrespro.ru  
Backpatch-through: 13  

commit   : bdb052f53b1afc3218f0993cadecdcd4df94f903    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jul 2025 16:35:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jul 2025 16:35:42 -0400    

Minor wordsmithing of the func.sgml paragraph describing  
statement_timestamp() and allied functions: don't switch between  
"statement" and "command" when those are being used to mean about  
the same thing.  
  
Also, add some text to protocol.sgml describing the perhaps-surprising  
behavior these functions have in a multi-statement Query message.  
  
Reported-by: P M <petermittere@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/175223006802.3157505.14764328206246105568@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : 50959f96e7b17c3f225919edbec4072c033aef60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2025 18:50:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2025 18:50:13 -0400    

getid() and putid(), which parse and deparse role names within ACL  
input/output, applied isalnum() to see if a character within a role  
name requires quoting.  They did this even for non-ASCII characters,  
which is problematic because the results would depend on encoding,  
locale, and perhaps even platform.  So it's possible that putid()  
could elect not to quote some string that, later in some other  
environment, getid() will decide is not a valid identifier, causing  
dump/reload or similar failures.  
  
To fix this in a way that won't risk interoperability problems  
with unpatched versions, make getid() treat any non-ASCII as a  
legitimate identifier character (hence not requiring quotes),  
while making putid() treat any non-ASCII as requiring quoting.  
We could remove the resulting excess quoting once we feel that  
no unpatched servers remain in the wild, but that'll be years.  
  
A lesser problem is that getid() did the wrong thing with an input  
consisting of just two double quotes ("").  That has to represent an  
empty string, but getid() read it as a single double quote instead.  
The case cannot arise in the normal course of events, since we don't  
allow empty-string role names.  But let's fix it while we're here.  
  
Although we've not heard field reports of problems with non-ASCII  
role names, there's clearly a hazard there, so back-patch to all  
supported versions.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3792884.1751492172@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 24f6c1bd41d0631a04cc956cc8cafa0b117ab625    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Jul 2025 09:53:34 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Jul 2025 09:53:34 +0530    

Previously, the check_hook functions for max_slot_wal_keep_size and  
idle_replication_slot_timeout would incorrectly raise an ERROR for values  
set in postgresql.conf during upgrade, even though those values were not  
actively used in the upgrade process.  
  
To prevent logical slot invalidation during upgrade, we used to set  
special values for these GUCs. Now, instead of relying on those values, we  
directly prevent WAL removal and logical slot invalidation caused by  
max_slot_wal_keep_size and idle_replication_slot_timeout.  
  
Note: PostgreSQL 17 does not include the idle_replication_slot_timeout  
GUC, so related changes were not backported.  
  
BUG #18979  
Reported-by: jorsol <jorsol@gmail.com>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed by: vignesh C <vignesh21@gmail.com>  
Reviewed by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/219561.1751826409@sss.pgh.pa.us  
Discussion: https://postgr.es/m/18979-a1b7fdbb7cd181c6@postgresql.org  

commit   : e43fae199e5068914c6cc39aff9dbbb65aa896d7    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 10 Jul 2025 15:52:41 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 10 Jul 2025 15:52:41 -0500    

Commit a45c78e328 moved large object metadata from SECTION_PRE_DATA  
to SECTION_DATA but neglected to move PRIO_LARGE_OBJECT in  
dbObjectTypePriorities accordingly.  While this hasn't produced any  
known live bugs, it causes problems for a proposed patch that  
optimizes upgrades with many large objects.  Fixing the priority  
might also make the topological sort step marginally faster by  
reducing the number of ordering violations that have to be fixed.  
  
Reviewed-by: Nitin Motiani <nitinmotiani@google.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aBkQLSkx1zUJ-LwJ%40nathan  
Discussion: https://postgr.es/m/aG_5DBCjdDX6KAoD%40nathan  
Backpatch-through: 17  

commit   : c1c6169eb4f47a839b9ebd1ceb30722e0c9f4699    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:28 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:28 -0700    

Commit c273d9d8ce4 reworked tab-completion of COPY and \copy in psql  
and added support for completing options within WITH clauses. However,  
the same COPY options were suggested for both COPY TO and COPY FROM  
commands, even though some options are only valid for one or the  
other.  
  
This commit separates the COPY options for COPY FROM and COPY TO  
commands to provide more accurate auto-completion suggestions.  
  
Back-patch to v14 where tab-completion for COPY and \copy options  
within WITH clauses was first supported.  
  
Author: Atsushi Torikoshi <torikoshia@oss.nttdata.com>  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/079e7a2c801f252ae8d522b772790ed7@oss.nttdata.com  
Backpatch-through: 14  

commit   : f2e41d9e2fb09ed0df8caf052c661c5281c3fed4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 9 Jul 2025 09:27:59 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 9 Jul 2025 09:27:59 +0530    

Clarified that the failover steps apply to a specific PostgreSQL subscriber  
and added guidance for verifying replication slot synchronization during  
planned failover. Additionally, corrected the standby query to avoid false  
positives by checking invalidation_reason IS NULL instead of conflicting.  
  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Author: Shveta Malik <shveta.malik@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://www.postgresql.org/message-id/CAExHW5uiZ-fF159=jwBwPMbjZeZDtmcTbN+hd4mrURLCg2uzJg@mail.gmail.com  

commit   : 95cf1a1817c992769e38cda7437751af54642ef8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 12:50:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 12:50:19 -0400    

xmltotext_with_options() did not consider the possibility that  
pg_xml_init() could fail --- most likely due to OOM.  If that  
happened, the already-parsed xmlDoc structure would be leaked.  
Oversight in commit 483bdb2af.  
  
Bug: #18981  
Author: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18981-9bc3c80f107ae925@postgresql.org  
Backpatch-through: 16  

commit   : a553a2289dbb7f157234ec08122bb3f54a417a24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jul 2025 14:33:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jul 2025 14:33:20 -0400    

pl/pgsql's notion of an "expression" is very broad, encompassing  
any SQL SELECT query that returns a single column and no more than  
one row.  So there are cases, for example evaluation of an aggregate  
function, where the query involves significant work and it'd be useful  
to run it with parallel workers.  This used to be possible, but  
commits 3eea7a0c9 et al unintentionally disabled it.  
  
The simplest fix is to make exec_eval_expr() pass maxtuples = 0  
rather than 2 to exec_run_select().  This avoids the new rule that  
we will never use parallelism when a nonzero "count" limit is passed  
to ExecutorRun().  (Note that the pre-3eea7a0c9 behavior was indeed  
unsafe, so reverting that rule is not in the cards.)  The reason  
for passing 2 before was that exec_eval_expr() will throw an error  
if it gets more than one returned row, so we figured that as soon  
as we have two rows we know that will happen and we might as well  
stop running the query.  That choice was cost-free when it was made;  
but disabling parallelism is far from cost-free, so now passing 2  
amounts to optimizing a failure case at the expense of useful cases.  
An expression query that can return more than one row is certainly  
broken.  People might now need to wait a bit longer to discover such  
breakage; but hopefully few will use enormously expensive cases as  
their first test of new pl/pgsql logic.  
  
Author: Dipesh Dhameliya <dipeshdhameliya125@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CABgZEgdfbnq9t6xXJnmXbChNTcWFjeM_6nuig41tm327gYi2ig@mail.gmail.com  
Backpatch-through: 13  

commit   : c911e7802e1de2a5a2d70e52b8d2b50ef768c2c1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:37 +0900    

libxml2 has deprecated the members of xmlBuffer, and it is recommended  
to access them with dedicated routines.  We have only one case in the  
tree where this shows an impact: xml2/xpath.c where "content" was  
getting directly accessed.  The rest of the code looked fine, checking  
the PostgreSQL code with libxml2 close to the top of its "2.14" branch.  
  
xmlBufferContent() exists since year 2000 based on a check of the  
upstream libxml2 tree, so let's switch to it.  
  
Like 400928b83bd2, backpatch all the way down as this can have an impact  
on all the branches already released once newer versions of libxml2 get  
more popular.  
  
Reported-by: Walid Ibrahim <walidib@amazon.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aGdSdcR4QTjEHX6s@paquier.xyz  
Backpatch-through: 13  

commit   : bcb8d47cdd5e894ea9625feb11a95901f8358bb4    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 21:30:05 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 21:30:05 +0200    

That was invented in 9.5, and pg_upgrade claims to support back to 9.0.  
But we don't need that with a simple query change, tested by Tom Lane.  
  
Discussion: https://postgr.es/m/202507041645.afjl5rssvrgu@alvherre.pgsql  

commit   : 0807a4656edcfdc2f900bc070a4a8592a0a7f880    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 16:07:11 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 16:07:11 +0200    

Minor oversight in 347758b12063  

commit   : b8b2e60527c67599bb74895fc99d7feb7f97d706    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 18:05:43 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 18:05:43 +0200    

With tables defined like this,  
  CREATE TABLE ip (id int PRIMARY KEY);  
  CREATE TABLE ic (id int) INHERITS (ip);  
  ALTER TABLE ic ALTER id DROP NOT NULL;  
  
pg_upgrade fails during the schema restore phase due to this error:  
  ERROR: column "id" in child table must be marked NOT NULL  
  
This can only be fixed by marking the child column as NOT NULL before  
the upgrade, which could take an arbitrary amount of time (because ic's  
data must be scanned).  Have pg_upgrade's check mode warn if that  
condition is found, so that users know what to adjust before running the  
upgrade for real.  
  
Author: Ali Akbar <the.apaan@gmail.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CACQjQLoMsE+1pyLe98pi0KvPG2jQQ94LWJ+PTiLgVRK4B=i_jg@mail.gmail.com  

commit   : ae20c105f0b20c80a6f57d43cf0ae118d0f53d7f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:19 +0900    

Attempting to use commit timestamps during bootstrapping leads to an  
assertion failure, that can be reached for example with an initdb -c  
that enables track_commit_timestamp.  It makes little sense to register  
a commit timestamp for a BootstrapTransactionId, so let's disable the  
activation of the module in this case.  
  
This problem has been independently reported once by each author of this  
commit.  Each author has proposed basically the same patch, relying on  
IsBootstrapProcessingMode() to skip the use of commit_ts during  
bootstrap.  The test addition is a suggestion by me, and is applied down  
to v16.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Author: Andy Fan <zhihuifan1213@163.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/OSCPR01MB14966FF9E4C4145F37B937E52F5102@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/87plejmnpy.fsf@163.com  
Backpatch-through: 13  

commit   : 6d4395b4021d5f2640f2aadece1dad650b1e7037    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 13:46:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 13:46:07 -0400    

Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup  
contains three calls to ATPostAlterTypeParse, and the other two  
also need protection against passing a relid that we don't yet  
have lock on.  Add similar logic to those code paths, and add  
some test cases demonstrating the need for it.  
  
In v18 and master, the test cases demonstrate that there's a  
behavioral discrepancy between stored generated columns and virtual  
generated columns: we disallow changing the expression of a stored  
column if it's used in any composite-type columns, but not that of  
a virtual column.  Since the expression isn't actually relevant to  
either sort of composite-type usage, this prohibition seems  
unnecessary; but changing it is a matter for separate discussion.  
For now we are just documenting the existing behavior.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Author: jian he <jian.universality@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com  
Backpatch-through: 13  

commit   : ba9201b57b00b8f9a612a3fd1ae22a768556cb3d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 23:07:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 23:07:23 +0900    

The documentation for pg_replication_slots previously mentioned only  
max_slot_wal_keep_size as a condition under which the wal_status column  
could show unreserved or lost. However, since commit be87200,  
replication slots can also be invalidated due to horizon or wal_level,  
and since commit ac0e33136ab, idle_replication_slot_timeout can also  
trigger this state.  
  
This commit updates the description of the wal_status column to  
reflect that max_slot_wal_keep_size is not the only cause of the lost state.  
  
Back-patched to v16, where the additional invalidation cases were introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com  
Backpatch-through: 16  

commit   : 27224e660aca7704e565ff6d7fc1c8f262c2f05c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 16:03:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 16:03:19 +0900    

The documentation previously stated that the wal_status column is NULL  
if restart_lsn is NULL in the pg_replication_slots view. This is incorrect,  
and wal_status can be "lost" even when restart_lsn is NULL.  
  
This commit removes the incorrect description.  
  
Back-patched to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701d89@oss.nttdata.com  
Backpatch-through: 13  

commit   : 445bd37b19c297b56a7e3b24a69b3648918d2c31    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2025 15:47:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2025 15:47:59 -0400    

PQcancelCreate failed to copy struct pg_conn_host's "type" field,  
instead leaving it zero (a/k/a CHT_HOST_NAME).  This seemingly  
has no great ill effects if it should have been CHT_UNIX_SOCKET  
instead, but if it should have been CHT_HOST_ADDRESS then a  
null-pointer dereference will occur when the cancelConn is used.  
  
Bug: #18974  
Reported-by: Maxim Boguk <maxim.boguk@gmail.com>  
Author: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18974-575f02b2168b36b3@postgresql.org  
Backpatch-through: 17  

commit   : 792238c8b4a1943e91485fa7dac1959f23a9ac1d    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 1 Jul 2025 23:25:15 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 1 Jul 2025 23:25:15 -0700    

Commit c120550edb86 optimized the vacuuming of relations without  
indexes (a.k.a. one-pass strategy) by directly marking dead item IDs  
as LP_UNUSED. However, the periodic FSM vacuum was still checking if  
dead item IDs had been marked as LP_DEAD when attempting to vacuum the  
FSM every VACUUM_FSM_EVERY_PAGES blocks. This condition was never met  
due to the optimization, resulting in missed FSM vacuum  
opportunities.  
  
This commit modifies the periodic FSM vacuum condition to use the  
number of tuples deleted during HOT pruning. This count includes items  
marked as either LP_UNUSED or LP_REDIRECT, both of which are expected  
to result in new free space to report.  
  
Back-patch to v17 where the vacuum optimization for tables with no  
indexes was introduced.  
  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoBL8m6B9GSzQfYxVaEgvD7-Kr3AJaS-hJPHC+avm-29zw@mail.gmail.com  
Backpatch-through: 17  

commit   : 074003431895624197230de80217886b186e4208    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:43 +0900    

When decompressing some input data, the calculation for the initial  
starting point and the initial size were incorrect, potentially leading  
to failures when decompressing contents with LZ4.  These initialization  
points are fixed in this commit, bringing the logic closer to what  
exists for gzip and zstd.  
  
The contents of the compressed data is clear (for example backups taken  
with LZ4 can still be decompressed with a "lz4" command), only the  
decompression part reading the input data was impacted by this issue.  
  
This code path impacts pg_basebackup and pg_verifybackup, which can use  
the LZ4 decompression routines with an archive streamer, or any tools  
that try to use the archive streamers in src/fe_utils/.  
  
The issue is easier to reproduce with files that have a low-compression  
rate, like ones filled with random data, for a size of at least 512kB,  
but this could happen with anything as long as it is stored in a data  
folder.  Some tests are added based on this idea, with a file filled  
with random bytes grabbed from the backend, written at the root of the  
data folder.  This is proving good enough to reproduce the original  
problem.  
  
Author: Mikhail Gribkov <youzhick@gmail.com>  
Discussion: https://postgr.es/m/CAMEv5_uQS1Hg6KCaEP2JkrTBbZ-nXQhxomWrhYQvbdzR-zy-wA@mail.gmail.com  
Backpatch-through: 15  

commit   : c6d0ef160e948b43222020e6199977c88969537b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 22:15:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 22:15:26 +0200    

Commit 7a7b3e11e61 added the ii_NullsNotDistinct field, but the  
comment was not updated.  
  
Author: Japin Li <japinli@hotmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ME0P300MB04453E6C7EA635F0ECF41BFCB6832%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : f5551538bce031e0e6d47e25c4f488f0e642a4a6    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:54:38 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:54:38 -0500    

Oversight in commit 0ac5ad5134.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/20150619215231.GT133018%40postgresql.org  
Discussion: https://postgr.es/m/CAA5RZ0sjQDDwJfMRb%3DZ13nDLuRpF13ME2L_BdGxi0op8RKjmDg%40mail.gmail.com  
Backpatch-through: 13  

commit   : 9d14d40ec5ee6c5d1a959995c2c70b82a8898fda    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 20:12:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 20:12:36 +0200    

Commit 78416235713 removed the ii_OpclassOptions field, but the  
comment was not updated.  
  
Author: Japin Li <japinli@hotmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ME0P300MB04453E6C7EA635F0ECF41BFCB6832%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : 0991249d7ab52ed689c1d5f752ae6581506627bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:40:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:40:35 -0400    

We stopped defining IOV_MAX on non-Windows systems in 75357ab94, on  
the assumption that every non-Windows system defines it in <limits.h>  
as required by X/Open.  GNU Hurd, however, doesn't follow that  
standard either.  Put back the old logic to assume 16 if it's  
not defined.  
  
Author: Michael Banck <mbanck@gmx.net>  
Co-authored-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/6862e8d1.050a0220.194b8d.76fa@mx.google.com  
Discussion: https://postgr.es/m/6846e0c3.df0a0220.39ef9b.c60e@mx.google.com  
Backpatch-through: 16  

commit   : 29c54ea7b49ccd2838ee91365d68ff710c38c772    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:08:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:08:20 -0400    

The existing code assumed that O_RDONLY is defined as 0, but this is  
not required by POSIX and is not true on GNU Hurd.  We can avoid  
the assumption by relying on O_ACCMODE to mask the fcntl() result.  
(Hopefully, all supported platforms define that.)  
  
Author: Michael Banck <mbanck@gmx.net>  
Co-authored-by: Samuel Thibault  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/6862e8d1.050a0220.194b8d.76fa@mx.google.com  
Discussion: https://postgr.es/m/68480868.5d0a0220.1e214d.68a6@mx.google.com  
Backpatch-through: 13  

commit   : 98749132e87dea1e79bdddc8c20527697a9992af    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:13:21 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:13:21 +0900    

Commit 19d8e2308bc added enum values with the prefix TU_, but a few  
comments still referred to TUUI_, which was used in development  
versions of the patches committed as 19d8e2308bc.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/20250701110216.8ac8a9e4c6f607f1d954f44a@sraoss.co.jp  
Backpatch-through: 16  

commit   : d32933cea5c9424a26e1d95e6140e1bac2e09845    
  
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   : bbfcbc4cde4a9fb5b1d91acc3d8efc6f868c2684    
  
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   : 07402e370e5b07d342a74025407f37a38fe9f064    
  
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   : 40c9b4d8dafc7e573df1f783d22be292a0ed323b    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:41 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:41 -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   : 457f1a92034b657bd0b5a2b739dfb4a7f0e1b03e    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:37:39 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:37:39 +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   : a0e7e9799c71abdfdebf16219903e1e2d08687cd    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Jun 2025 10:07:03 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Jun 2025 10:07:03 +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   : 2e0b5d252b10b790abdee9dec202a306006037c2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:50 +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   : 9f33300e69b8a926b5168cd9be3cd7cd11396bbd    
  
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   : 2c0bc4765741e2947b2bd651077852935cfecb41    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Tue, 24 Jun 2025 09:21:55 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Tue, 24 Jun 2025 09:21:55 -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   : 805b85027ad7bc4422ef5ea4041fd3de8e175459    
  
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   : 589c5f8356007a198818e17fc04512e224d9f358    
  
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   : 2499c3490b2f4b2048e4d476405dee996026ac0d    
  
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   : 9575e540f6665f0992db8b68b27e152548c75e36    
  
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   : fdd82692230a4ffcc6c382a68401dd8c1bed8250    
  
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   : 5ed50f9386f04d9b8a88af8902b06cb747db7b54    
  
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   : 0f5ac7f321fbe19e666b5c5f19218f6ff5cd8c83    
  
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   : 25505082f0e7aa6dc9cd068b0e5330bb1ca22751    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Jun 2025 09:32:30 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Jun 2025 09:32:30 +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   : 45c357e0e85d2dffe7af5440806150124a725a01    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:58 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:58 -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   : 32ab0fd55da5b667a25e56bd74e258bb8eca6cf3    
  
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   : 2090edc6f32f652a2c995ca5f7e65748ae1e4c5d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 14 Jun 2025 03:33:15 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 14 Jun 2025 03:33:15 +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 idea of the patch is to get the minimal restart_lsn at the beginning  
of checkpoint (or restart point) creation and use this value when calculating  
the oldest LSN for WAL segments removal at the end of checkpoint.  This idea  
was proposed by Tomas Vondra in the discussion.  Unlike 291221c46575, this  
fix doesn't affect ABI and is intended for back branches.  
  
Discussion: https://postgr.es/m/flat/1d12d2-67235980-35-19a406a0%4063439497  
Author: Vitaly Davydov <v.davydov@postgrespro.ru>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 13  

commit   : 40aa5ddea1c02bcd098bf66d2a3e16faeec94aea    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:33 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:33 -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   : 30e0d9ee904d29854c43c15b4ecbe13ceaf2d7d6    
  
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   : 839802792f0132fd8f7fe7f9acc9520114db5ddf    
  
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   : 65145d0955c494d37f71f5a8e219f05aa947a04e    
  
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   : e4b8f925a929fd57570097483a0fcf82dfc141da    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:26 -0400    

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

commit   : 767d38e2c0960658251c356fedbf15c52ecb8637    
  
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   : 002938f15c63a52bfb191dce9496486a4bbfb757    
  
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   : d4046125dd7d876b4930b346c28c588e622667ec    
  
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   : 87be749c716a5d58ca0a92a56f0c1b7ba8e1fae4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Jun 2025 12:04:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Jun 2025 12:04:04 +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   : 6f724fcf8136dc4c229e66122fcf6710a4040d9a    
  
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   : 7559a16e2313e56248bbeb225224b688bbe591cf    
  
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   : ab52f6b5bf4d6aef4a4412bbefb7a3e9ca65017b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:17:30 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:17:30 +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 this 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   : fe8ea7a2a89342ecc36a054b2f328c4d8e56f9ae    
  
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  

commit   : 9339c85afc913752884858b28cca99b8f42a389c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2025 13:45:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2025 13:45:41 -0400    

postgres_fdw tries to use PG_TRY blocks to ensure that it will  
eventually free the PGresult created by the remote modify command.  
However, it's fundamentally impossible for this scheme to work  
reliably when there's RETURNING data, because the query could fail  
in between invocations of postgres_fdw's DirectModify methods.  
There is at least one instance of exactly this situation in the  
regression tests, and the ensuing session-lifespan leak is visible  
under Valgrind.  
  
We can improve matters by using a memory context reset callback  
attached to the ExecutorState context.  That ensures that the  
PGresult will be freed when the ExecutorState context is torn  
down, even if control never reaches postgresEndDirectModify.  
  
I have little faith that there aren't other potential PGresult  
leakages in the backend modules that use libpq.  So I think it'd  
be a good idea to apply this concept universally by creating  
infrastructure that attaches a reset callback to every PGresult  
generated in the backend.  However, that seems too invasive for  
v18 at this point, let alone the back branches.  So for the  
moment, apply this narrow fix that just makes DirectModify safe.  
I have a patch in the queue for the more general idea, but it  
will have to wait for v19.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://postgr.es/m/2976982.1748049023@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 8b0aa7a6b723174cfa6f1a5e2a03217dba9f6e6e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2025 12:55:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2025 12:55:15 -0400    

Our GSSAPI code only allows packet sizes up to 16kB.  However it  
emerges that during authentication, larger packets might be needed;  
various authorities suggest 48kB or 64kB as the maximum packet size.  
This limitation caused login failure for AD users who belong to many  
AD groups.  To add insult to injury, we gave an unintelligible error  
message, typically "GSSAPI context establishment error: The routine  
must be called again to complete its function: Unknown error".  
  
As noted in code comments, the 16kB packet limit is effectively a  
protocol constant once we are doing normal data transmission: the  
GSSAPI code splits the data stream at those points, and if we change  
the limit then we will have cross-version compatibility problems  
due to the receiver's buffer being too small in some combinations.  
However, during the authentication exchange the packet sizes are  
not determined by us, but by the underlying GSSAPI library.  So we  
might as well just try to send what the library tells us to.  
An unpatched recipient will fail on a packet larger than 16kB,  
but that's not worse than the sender failing without even trying.  
So this doesn't introduce any meaningful compatibility problem.  
  
We still need a buffer size limit, but we can easily make it be  
64kB rather than 16kB until transport negotiation is complete.  
(Larger values were discussed, but don't seem likely to add  
anything.)  
  
Reported-by: Chris Gooch <cgooch@bamfunds.com>  
Fix-suggested-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/DS0PR22MB5971A9C8A3F44BCC6293C4DABE99A@DS0PR22MB5971.namprd22.prod.outlook.com  
Backpatch-through: 13  

commit   : 24c5ad5be46dcaa1ba573f520cf366939a6cae77    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 31 May 2025 00:08:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 31 May 2025 00:08:40 +0900    

Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter  
a non-interruptible loop when they successfully acquired a lock on a transaction  
but the transaction still appeared to be running. Since this loop continued  
until the transaction completed, it could result in long, uninterruptible waits.  
  
Although this scenario is generally unlikely since XactLockTableWait() and  
ConditionalXactLockTableWait() can basically acquire a transaction lock  
only when the transaction is not running, it can occur in a hot standby.  
In such cases, the transaction may still appear active due to  
the KnownAssignedXids list, even while no lock on the transaction exists.  
For example, this situation can happen when creating a logical replication  
slot on a standby.  
  
The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS()  
within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions,  
ensuring they can be interrupted safely.  
  
Back-patch to all supported branches.  
  
Author: Kevin K Biju <kevinkbiju@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com  
Backpatch-through: 13  

commit   : 50a8959cd50bb346b2479ac66bb4f0f474409c51    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 30 May 2025 16:18:18 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 30 May 2025 16:18:18 +0200    

Commits 53af9491a043 and 2d5fe514052a fixed a number of problems with  
foreign keys that reference partitioned tables, and a query to detect  
already broken FKs was supplied with the release notes for 17.1, 16.5,  
15.9, 14.14, 13.17.  However, that query has a bug that causes it to  
wrongly report self-referential foreign keys even when they are correct,  
so if the user was to drop and rebuild the FKs as indicated, the query  
would continue to report them as needing to be repaired.  Here we fix  
the query to not have that problem.  
  
Reported-by: Paul Foerster <paul.foerster@gmail.com>  
Discussion: https://postgr.es/m/5456A1D0-CD47-4315-9C65-71B27E7A2906@gmail.com  
Backpatch-through: 13-17  

commit   : e20b3256ae468cb5979e861a1d6886baa4c4d42e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 May 2025 10:39:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 May 2025 10:39:55 -0400    

If we hit out-of-memory between creating the PGconn and inserting  
it into dblink's hashtable, we'd lose track of the PGconn, which  
is quite bad since it represents a live connection to a remote DB.  
Fix by rearranging things so that we create the hashtable entry  
first.  
  
Also reduce the number of states we have to deal with by getting rid  
of the separately-allocated remoteConn object, instead allocating it  
in-line in the hashtable entries.  (That incidentally removes a  
session-lifespan memory leak observed in the regression tests.)  
  
There is an apparently-irreducible remaining OOM hazard, which  
is that if the connection fails at the libpq level (ie it's  
CONNECTION_BAD) then we have to pstrdup the PGconn's error message  
before we can release it, and theoretically that could fail.  However,  
in such cases we're only leaking memory not a live remote connection,  
so I'm not convinced that it's worth sweating over.  
  
This is a pretty low-probability failure mode of course, but losing  
a live connection seems bad enough to justify back-patching.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://postgr.es/m/1346940.1748381911@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : b64c585fde77206ee54747f31035dde56eee6bf9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 29 May 2025 17:50:32 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 29 May 2025 17:50:32 +0900    

An assertion test added in commit 049ef33 could fail when pg_prewarm()  
was called on objects without storage, such as partitioned tables.  
This resulted in the following failure in assert-enabled builds:  
  
    Failed Assert("RelFileNumberIsValid(rlocator.relNumber)")  
  
Note that, in non-assert builds, pg_prewarm() just failed with an error  
in that case, so there was no ill effect in practice.  
  
This commit fixes the issue by having pg_prewarm() raise an error early  
if the specified object has no storage. This approach is similar to  
the fix in commit 4623d7144 for pg_freespacemap.  
  
Back-patched to v17, where the issue was introduced.  
  
Author: Masahiro Ikeda <ikedamsh@oss.nttdata.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/e082e6027610fd0a4091ae6d033aa117@oss.nttdata.com  
Backpatch-through: 17  

commit   : 290e8ab32ac55a27cd3bc14cb80c8e2f3d023901    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:23 +0900    

pg_stat_statements anticipates that certain constant locations may be  
recorded multiple times and attempts to avoid calculating a length for  
these locations in fill_in_constant_lengths().  
  
However, during generate_normalized_query() where normalized query  
strings are generated, these locations are not excluded from  
consideration.  This could increment the parameter number counter for  
every recorded occurrence at such a location, leading to an incorrect  
normalization in certain cases with gaps in the numbers reported.  
  
For example, take this query:  
SELECT WHERE '1' IN ('2'::int, '3'::int::text)  
Before this commit, it would be normalized like that, with gaps in the  
parameter numbers:  
SELECT WHERE $1 IN ($3::int, $4::int::text)  
However the correct, less confusing one should be like that:  
SELECT WHERE $1 IN ($2::int, $3::int::text)  
  
This commit fixes the computation of the parameter numbers to track the  
number of constants replaced with an $n by a separate counter instead of  
the iterator used to loop through the list of locations.  
  
The underlying query IDs are not changed, neither are the normalized  
strings for existing PGSS hash entries.  New entries with fresh  
normalized queries would automatically get reshaped based on the new  
parameter numbering.  
  
Issue discovered while discussing a separate problem for HEAD, but this  
affects all the stable branches.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0tzxvWXsacGyxrixdhy3tTTDfJQqxyFBRFh31nNHBQ5qA@mail.gmail.com  
Backpatch-through: 13  

commit   : a3c6d92f3cb3e49bde59e52268e2d74db05d7789    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:45 +0900    

As written, the test was throwing an error because of an unbalanced  
parenthesis.  The regex used in the test is adjusted to not fail and to  
test the case of an opening parenthesis in a character class after some  
nested square brackets.  
  
Oversight in d46911e584d4.  
  
Discussion: https://postgr.es/m/16ab039d1af455652bdf4173402ddda145f2c73b.camel@cybertec.at  

commit   : e3ffc3e91d04579240fb54a96f9059b246488dce    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:22 +0900    

The code that translates SIMILAR TO pattern matching expressions to  
POSIX-style regular expressions did not consider that square brackets  
can be nested.  For example, in an expression like [[:alpha:]%_], the  
logic replaced the placeholders '_' and '%' but it should not.  
  
This commit fixes the conversion logic by tracking the nesting level of  
square brackets marking character class areas, while considering that  
in expressions like []] or [^]] the first closing square bracket is a  
regular character.  Multiple tests are added to show how the conversions  
should or should not apply applied while in a character class area, with  
specific cases added for all the characters converted outside character  
classes like an opening parenthesis '(', dollar sign '$', etc.  
  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/16ab039d1af455652bdf4173402ddda145f2c73b.camel@cybertec.at  
Backpatch-through: 13  

commit   : 6ea812f4dc634af01feb06fc3da45d53f5a1ec83    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 May 2025 17:28:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 May 2025 17:28:40 +0900    

The test did not wait for all the subscriptions to have caught up when  
dropping the subscription "tab_copy".  In a slow environment, it could  
be possible for the replay of the COMMIT PREPARED transaction "mygid"  
to not be confirmed yet, causing one prepared transaction to be left  
around before moving to the next steps of the test.  
  
One failure noticed is a transaction found in pg_prepared_xacts for the  
cases where copy_data = false and two_phase = true, but there should be  
none after dropping the subscription.  
  
As an extra safety measure, a check is added before dropping the  
subscription, scanning pg_prepared_xacts to make sure that no prepared  
transactions are left once both subscriptions have caught up.  
  
Issue introduced by a8fd13cab0ba, fixing a problem similar to  
eaf5321c3524.  
  
Per buildfarm member kestrel.  
  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CALDaNm329QaZ+bwU--bW6GjbNSZ8-38cDE8QWofafub7NV67oA@mail.gmail.com  
Backpatch-through: 15  

commit   : 90558dbf54830aa632ff880f65c7eb13f0ca7ec6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 26 May 2025 12:47:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 26 May 2025 12:47:33 +0900    

The documentation for exported snapshots in logical decoding previously  
stated that snapshot creation may fail on a hot standby. This is no longer  
accurate, as snapshot exporting on standbys has been supported since  
PostgreSQL 10. This commit removes the outdated description.  
  
Additionally, the docs referred to the NOEXPORT_SNAPSHOT option to  
suppress snapshot exporting in CREATE_REPLICATION_SLOT. However,  
since PostgreSQL 15, NOEXPORT_SNAPSHOT is considered legacy syntax  
and retained only for backward compatibility. This commit updates  
the documentation for v15 and later to use the modern equivalent:  
SNAPSHOT 'nothing'. The older syntax is preserved in documentation for  
v14 and earlier.  
  
Back-patched to all supported branches.  
  
Reported-by: Kevin K Biju <kevinkbiju@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Kevin K Biju <kevinkbiju@gmail.com>  
Discussion: https://postgr.es/m/174791480466.798.17122832105389395178@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : cd3064f9898c8753bc50983b47dbdc7390cdfb83    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 May 2025 14:43:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 May 2025 14:43:43 -0400    

PgStat_StatTabEntry and AutoVacOpts structs were leaked until  
the end of the autovacuum worker's run, which is bad news if  
there are a lot of relations in the database.  
  
Note: pfree'ing the PgStat_StatTabEntry structs here seems a bit  
risky, because pgstat_fetch_stat_tabentry_ext does not guarantee  
anything about whether its result is long-lived.  It appears okay  
so long as autovacuum forces PGSTAT_FETCH_CONSISTENCY_NONE, but  
I think that API could use a re-think.  
  
Also ensure that the VacuumRelation structure passed to  
vacuum() is in recoverable storage.  
  
Back-patch to v15 where we started to manage table statistics  
this way.  (The AutoVacOpts leakage is probably older, but  
I'm not excited enough to worry about just that part.)  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/285483.1746756246@sss.pgh.pa.us  
Backpatch-through: 15  

commit   : ac3afd1d00795656dc08431d2bbebf7eccfb5823    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 May 2025 11:47:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 May 2025 11:47:33 -0400    

If the inner allocation call returns NULL, we should restore the  
previous state and return NULL.  Previously this code pfree'd  
the old chunk anyway, which is surely wrong.  
  
Also, make it call MemoryContextAllocationFailure rather than  
summarily returning NULL.  The fact that we got control back from the  
inner call proves that MCXT_ALLOC_NO_OOM was passed, so this change  
is just cosmetic, but someday it might be less so.  
  
This is just a latent bug at present: AFAICT no in-core callers use  
this function at all, let alone call it with MCXT_ALLOC_NO_OOM.  
Still, it's the kind of bug that might bite back-patched code pretty  
hard someday, so let's back-patch to v17 where the bug was introduced  
(by commit 743112a2e).  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/285483.1746756246@sss.pgh.pa.us  
Backpatch-through: 17  

commit   : 20bae0690322a00402b84119ddf2f959d24a211a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 May 2025 13:52:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 May 2025 13:52:46 -0400    

xmltotext_with_options sometimes tries to replace the existing  
root node of a libxml2 document.  In that case xmlDocSetRootElement  
will unlink and return the old root node; if we fail to free it,  
it's leaked for the remainder of the session.  The amount of memory  
at stake is not large, a couple hundred bytes per occurrence, but  
that could still become annoying in heavy usage.  
  
Our only other xmlDocSetRootElement call is not at risk because  
it's working on a just-created document, but let's modify that  
code too to make it clear that it's dependent on that.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Discussion: https://postgr.es/m/1358967.1747858817@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 11efaaffac87e7ba4aedbbb612d2eddc37fabfc4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 May 2025 11:55:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 May 2025 11:55:14 +0900    

Since commit 8b1dccd37c7, the PREPARE TRANSACTION WAL record includes  
information about dropped statistics entries. However, the WAL resource  
manager description function for PREPARE TRANSACTION record failed to  
parse this information correctly and always assumed there were  
no such entries.  
  
As a result, for example, pg_waldump could not display the dropped  
statistics entries stored in PREPARE TRANSACTION records.  
  
The root cause was that ParsePrepareRecord() did not set the number of  
statistics entries to drop on commit or abort. These values remained  
zero-initialized and were never updated from the parsed record.  
  
This commit fixes the issue by properly setting those values during parsing.  
With this fix, pg_waldump can now correctly report dropped statistics  
entries in PREPARE TRANSACTION records.  
  
Back-patch to v15, where commit 8b1dccd37c7 was introduced.  
  
Author: Daniil Davydov <3danissimo@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAJDiXgh-6Epb2XiJe4uL0zF-cf0_s_7Lw1TfEHDMLzYjEmfGOw@mail.gmail.com  
Backpatch-through: 15  

commit   : a4da7b0cfabd1c72d2efb0148d9a41f34a9e2b78    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 20 May 2025 10:39:14 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 20 May 2025 10:39:14 +0300