PostgreSQL 16.10 commit log

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

commit   : 18d01671ef2576f7f950c2797a467370bc1a654d    
  
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   : 7ad8e790988d3a49010ec00e0cec0dace4c7416f    
  
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   : 850caae60c49c15ed021f8051dc39c6e24f2a380    
  
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   : 192634292384ea385abd2c320c0810fc7621b325    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:42:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:42:47 +0200    

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

commit   : 7e86da539d18bc29377a3882b9945dfbeb375f9c    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:10:17 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:10:17 +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   : 94c067376d5395fff7bf3e7980d11fcd2482b2be    
  
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   : 216683296101895f32d73908caa863cead7a54ac    
  
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   : a3906b44c5b920cd7beb569a097660f487adf883    
  
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   : 3863c6fb696cf57718483a3bf0abbf05e382abe1    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 17:35:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 17:35:02 +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   : 9cca445dfd2c39c1dbc031bb1596c67594b54668    
  
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   : f770006928d0a697e0fe0463cdb3e052b86ef940    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Aug 2025 09:07:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Aug 2025 09:07:54 +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   : 06f44481646a669b43a19a2c501a164459d194f1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 00:27:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 00:27:14 +0200    

The backport of commit f295494d338 introduced a format string using  
%m.  This is not wrong, since those have been supported since commit  
d6c55de1f99a, but only commit 2c8118ee5d9 later introduced their use  
in this file.  This use introduces a gratuitously different  
translatable string and also makes it inconsistent with the rest of  
the file.  To avoid that, switch this back to the old-style strerror()  
route in the appropriate backbranches  

commit   : 3a3b1d7ab1809910e51ca19e116080311579d75a    
  
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   : 2ac50f1187c2007f6ed581db6ee7240c5e5a37e6    
  
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   : b862465dba3386c24328c6f7d92499ea32d71a73    
  
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   : aae9aad19d824af72640f4597a812d75ae25e385    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:14:39 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:14:39 +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   : 05b367bea4e36a3b747b7aaf6f3ffe72bb6b825e    
  
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   : b9279058a3ca416e42dd73a54c426c8e43f6c8ca    
  
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   : 3c2c3f2ddb0f27062b73cea500f806e42f01db33    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 4 Aug 2025 15:07:00 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 4 Aug 2025 15:07:00 -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   : 112945a61e2331a70470b7a5c8b68b58065ff34b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:22:29 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:22:29 +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   : 479ebce12d320d23f960428b5221870c3633f1bd    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 4 Aug 2025 13:26:44 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 4 Aug 2025 13:26:44 +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   : 1d3ded521a0be7f46dde132053d876ec1cad2784    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sun, 3 Aug 2025 10:50:22 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sun, 3 Aug 2025 10:50:22 +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   : cd45fef058abc412ee3595cced5b68c4957f0499    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:02 +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   : ec96e88122c88866b1143c75048f28111b4eb344    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 2 Aug 2025 17:08:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 2 Aug 2025 17:08:52 +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   : b998ce3272ab45877f760ff558906a967b6a7da6    
  
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   : adfd8021911a302499187483c93814d24ca5ac44    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 06:40:06 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 06:40:06 +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   : 0ac1581c3f2dd02009f0bfa453854946d56e1fc4    
  
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   : 9affed26349acafb42471de34f37dc06b1a3879e    
  
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   : c1984be23cdc3aa74d1fd7bb28a4acaaa6813687    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:49 +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   : bbc20c8a9ffdefcabd70ea0c325827fe2b8f5960    
  
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   : 762c6d8d26e023afeb36019113ba9f60b811add1    
  
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   : d861b9282261b066a1147d920a27527c22dc499d    
  
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   : 6d5e493b4a15ee54c68b65e5f48feca87291eb79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jul 2025 16:50:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jul 2025 16:50:42 -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   : f0cdc2afd15e51f580e53ebd269bd66ec0aaaa79    
  
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   : e4d58545550927d5d0e36b8b2f9cba886c6748a8    
  
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   : 313d3102facdc61317d1292ab8f2d6cf1f254282    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:07 +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   : 2b09054e4d18acf9bb8aee75c1894be05d98c58b    
  
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   : b485e1c89a6dd210518eb4e26427df64831cf394    
  
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   : 009c20a3da5a960367c007ddb5187034a904705b    
  
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   : 4871c1e9cb6e1a085f68c3c399dc4ba95d108524    
  
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   : 246388618cee6b1005291267424ac67bd83496ac    
  
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   : cef998ef8314ea88db15b66f21ac000c9d0c248c    
  
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   : 738ad9a53891646edcc4333b3918624dcf317028    
  
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   : e92573917a49ce7d8d0cb5f996813500945616ee    
  
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   : ff6783ce526031fe9134f4d2139a78f9fd52d3d5    
  
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   : 5db55e13f2109c578f6fe0fce49574d801eef739    
  
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   : 2e7390928e80fe1e7bfd581724f7dcce3d27197d    
  
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   : 53a936b61f12cd9220340abc1a7843eb003d1abf    
  
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   : d69836b13c467fb64663f8d1f6d0ed976cc7824e    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:26 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:26 -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   : abb517d619c35cedb13e0c593dcd4cc4219f3aff    
  
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   : 3bbc1c4a73384bee6af6ec0c28875d2576c0d2ca    
  
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   : d24a96ce2cdb9260d71d7a655f95758a077e0e9d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:39 +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   : f943e2339f6c13730367ed826f0c496a00953a3e    
  
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   : f63e408e894c855775d1bd3224890cb618fd3894    
  
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   : 7e7059abfd2296b8716d2648baea67c445492cce    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:21 +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   : d36980b7159a343ec56baca40bfe6c67765095b7    
  
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   : db51bdf975e28003f08013a12bc46c0848533edc    
  
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   : 4ef4b9ba77375221c597f590cde1a1adc10453ca    
  
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   : 5c639523f721e9bd6139916200470e151d690728    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:45 +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   : 779f24c0b7be5d66504a30c6d15ab0430bdf59e2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 22:20:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 22:20:13 +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   : d271b04dc64ef34654f7ff2a2bb382c34543ea1e    
  
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   : d25d392e89440f97bfafc0e80dc7737872659d76    
  
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   : 3a2617e4f0be734f58f7219986c323469b502921    
  
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   : d74231839aa34a242e6e2da1efaf5d6c0013c6b3    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:13:04 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:13:04 +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   : c15798cf94c452f057c6b8dd38c904bb30a8864d    
  
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   : 01f26f5c2e4563a2dfc6a32dfe1d309c004bd748    
  
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   : 13a449fc5d4896452958fd4aa5b007aa24c0287f    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:32 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:32 -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   : 5d4033a066151c41939b8dc92a3301e385aaffcc    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:38:42 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:38:42 +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   : a4a1f9ec0aac2714ae9dad765b6259fb9b74e1e1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Jun 2025 10:18:22 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Jun 2025 10:18:22 +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   : d187cabddadcbea2033d172e738edbd65b5a3f8d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:52 +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   : 87c8ed3db16f94250ea4c3698c261294237a4c3b    
  
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   : abb487ad1ecf0e9dd8d64108baa949b752d8c756    
  
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   : e5fcc6d14f35e165f7f8e0a31c3e83ad57cc1f65    
  
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   : 629cc16231683c183c8a024629284aba5a056a28    
  
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   : 7a93bd5986e4b741fc3fdd8406431c77161c6d12    
  
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   : 1e24ea1603505142f63dcc8e7dbbb120312e2fe5    
  
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   : b2ae077205e18ac3e6d7bc5f7a6fa25a39323ec0    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:55 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:55 -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   : cea8f2c3e44b5fac59a7298c6b9045c5cbb0eaeb    
  
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   : c7f25feb3862000a4bc1930aea50ba923be0bdb6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:31 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:31 -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   : 3f37400cfb87002e48ee98d6c0d34a597d0dddf8    
  
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   : 169429264d0638b18e01926977b910ab70457f14    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:23 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:23 -0400    

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

commit   : aad8bd69530bd76f94df87c3e043687cbf29ee70    
  
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   : 6e71b7a39646e658ff8ccd55acf8b1d9d29d129b    
  
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   : ab758ec4d30745427e46b51b7b19b3c5483d513d    
  
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   : 5e6d561bc14db260e7456e02f7a15f46b0302f58    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Jun 2025 12:04:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Jun 2025 12:04:08 +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   : ecc8fd2b77635b43c034359c9af52941772ede53    
  
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   : 5c7fd5976284b8aa1f44682f2501b23cbe7bda94    
  
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   : 3611794affb6b52cece75aff58cf49e782a46442    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:19:37 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:19:37 +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   : 24135398f1e18e7779fd5052af8399c9d6bb5ff7    
  
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   : 2b92dc4eeb51a1b66641718e072b96b63659448c    
  
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   : ca70ee6ede1bde959a84eb69a6d9b7ba6f3e49ca    
  
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   : 63fa7caa958874fd6539497c5c765d57c03e312c    
  
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   : db54be898a68b8abccf1d5759dcbde9e23c56195    
  
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   : 8eef55db13fe5b14202729e893eac86ec66ef00d    
  
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   : 7e8b44f4e0e630971d912628f07a38a7d3a6fae8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:27 +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   : 52d08620e48c0c24d1d69179c88e49f9223f309d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:46 +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   : e9e535d611204266a3c2b587afd9ffbe346fc067    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:24 +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   : a7d3e32c8c0390d4ac1bb086d58340715ee32a46    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 May 2025 17:28:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 May 2025 17:28:41 +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   : dac37e3f3ba1758121068af85eb0298afb9b106c    
  
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   : e087b5b79452d4df9bca8e64d321d35b763b41c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 May 2025 14:43:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 May 2025 14:43:44 -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   : ee58de10084b42a24aaa3ab4af7713bb2fe02ab4    
  
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   : 0d2063585876e1333956ae8e3b5efae4b0cff083    
  
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   : 4b53cb493fa3cb7a6c2e32d3d014b754ae548c2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 May 2025 10:55:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 May 2025 10:55:05 -0400    

I missed updating msvc/Solution.pm in one branch in 12eee85e5 et al.  
Per buildfarm.  

commit   : 558ea446aeb0a95494fb781772dbbe1f2cc636d9    
  
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    

Commit 29f7ce6fe7 added another view that needs adjustment in the  
cross-version upgrade test. This should fix the XversionUpgrade  
failures in the buildfarm.  
  
Backpatch-through: 16  
Discussion: https://www.postgresql.org/message-id/18929-077d6b7093b176e2@postgresql.org  

commit   : dbe9804db1517b59e94d663de2661d4e4472be16    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 May 2025 14:39:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 May 2025 14:39:12 +0900    

Invalid indexes are suffixed with "_ccnew" or "_ccold".  The  
documentation missed to mention the initial underscore.  
ChooseRelationName() may also append an extra number if indexes with a  
similar name already exist; let's add a note about that too.  
  
Author: Alec Cozens <acozens@pixelpower.com>  
Discussion: https://postgr.es/m/174733277404.1455388.11471370288789479593@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : 92a9ba3b96c2bb483d53096fbf223501d0b327a2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2025 18:50:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2025 18:50:26 +0300    

In the grammar, <expr> is a c_expr, which accepts only a limited set  
of integer literals and simple expressions without parens. The  
deparsing logic didn't quite match the grammar rule, and failed to use  
parens e.g. for "5::bigint".  
  
To fix, always surround the expression with parens. Would be nice to  
omit the parens in simple cases, but unfortunately it's non-trivial to  
detect such simple cases. Even if the expression is a simple literal  
123 in the original query, after parse analysis it becomes a FuncExpr  
with COERCE_IMPLICIT_CAST rather than a simple Const.  
  
Reported-by: yonghao lee  
Backpatch-through: 13  
Discussion: https://www.postgresql.org/message-id/18929-077d6b7093b176e2@postgresql.org  

commit   : c0f51fde534db988235904849b439e2c6fe53bee    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 May 2025 11:41:22 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 May 2025 11:41:22 +0530    

Prevent moving the confirmed_flush backwards, as this could lead to data  
duplication issues caused by replicating already replicated changes.  
  
This can happen when a client acknowledges an LSN it doesn't have to do  
anything for, and thus didn't store persistently. After a restart, the  
client can send the prior LSN that it stored persistently as an  
acknowledgement, but we need to ignore such an LSN to avoid retreating  
confirm_flush LSN.  
  
Diagnosed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Author: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Tested-by: Nisha Moond <nisha.moond412@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAJpy0uDZ29P=BYB1JDWMCh-6wXaNqMwG1u1mB4=10Ly0x7HhwQ@mail.gmail.com  
Discussion: https://postgr.es/m/OS0PR01MB57164AB5716AF2E477D53F6F9489A@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 253cf661c2260886f261dff0e6b8df41781da8fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 May 2025 12:45:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 May 2025 12:45:55 -0400    

Per the letter of the C11 standard, one must #define  
__STDC_WANT_LIB_EXT1__ as 1 before including <string.h> in order to  
have access to memset_s().  It appears that many platforms are lenient  
about this, because we weren't doing it and yet the code appeared to  
work anyway.  But we now find that with -std=c11, macOS is strict and  
doesn't declare memset_s, leading to compile failures since we try to  
use it anyway.  (Given the lack of prior reports, perhaps this is new  
behavior in the latest SDK?  No matter, we're clearly in the wrong.)  
  
In addition to the immediate problem, which could be fixed merely by  
adding the needed #define to explicit_bzero.c, it seems possible that  
our configure-time probe for memset_s() could fail in case a platform  
implements the function in some odd way due to this spec requirement.  
This concern can be fixed in largely the same way that we dealt with  
strchrnul() in 6da2ba1d8: switch to using a declaration-based  
configure probe instead of a does-it-link probe.  
  
Back-patch to v13 where we started using memset_s().  
  
Reported-by: Lakshmi Narayana Velayudam <dev.narayana.v@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh=FaFQQGOO=nPzA1L8yEA@mail.gmail.com  
Backpatch-through: 13  

commit   : cc112eb8e9fed3eaf6b2d81aece21c3e964a21ae    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 16 May 2025 11:20:07 -0400    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 16 May 2025 11:20:07 -0400    

This aligns the copyright and legal notice wordig with commit  
a233a603bab8 and pgweb commit 2d764dbc083ab8.  Backpatch down  
to all supported versions.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Dave Page <dpage@pgadmin.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/744E414E-3F52-404C-97FB-ED9B3AA37DC8@yesql.se  
Backpatch-through: 13  

commit   : d3716d4b135756e38775a29a5ca26e17bd0efafc    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 15 May 2025 17:09:04 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 15 May 2025 17:09:04 +0900    

In an XMLTABLE expression, columns can be marked NOT NULL, and the  
parser internally fabricates an option named "is_not_null" to  
represent this.  However, the parser also allows users to specify  
arbitrary option names.  This creates a conflict: a user can  
explicitly use "is_not_null" as an option name and assign it a  
non-Boolean value, which violates internal assumptions and triggers an  
assertion failure.  
  
To fix, this patch checks whether a user-supplied name collides with  
the internally reserved option name and raises an error if so.  
Additionally, the internal name is renamed to "__pg__is_not_null" to  
further reduce the risk of collision with user-defined names.  
  
Reported-by: Евгений Горбанев <gorbanyoves@basealt.ru>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/6bac9886-65bf-4cec-96bd-e304159f28db@basealt.ru  
Backpatch-through: 15  

commit   : 9c94d983d67f51cd49be08699f2e35f0e4cb6a63    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 13 May 2025 07:29:14 -0400    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 13 May 2025 07:29:14 -0400    

The documentation for log_check() had the parameters in the wrong  
order.  Also while there, rename %parameters to %params to better  
documentation for similar functions which use %params.  Backpatch  
down to v14 where this was introduced.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/9F503B5-32F2-45D7-A0AE-952879AD65F1@yesql.se  
Backpatch-through: 14  

commit   : 2dac114e2c3fc584a94c4820e27396567faed050    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 09:47:10 -0400    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 09:47:10 -0400    

The comment describes the order in which fields are sent, and it had one  
of the fields in the wrong place.  
  
This has been wrong since e6dbcb72fafa (2008), so backpatch all the way  
back.  
  
Author: Emre Hasegeli <emre@hasegeli.com>  
Discussion: https://postgr.es/m/CAE2gYzzf38bR_R=izhpMxAmqHXKeM5ajkmukh4mNs_oXfxcMCA@mail.gmail.com  

commit   : cad781b3e5de615e8a570950e455bd04cdadeafd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 12:29:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 12:29:01 -0400    

Presently, LibreSSL does not have working support for RSA-PSS,  
so disable that test.  Per discussion at  
https://marc.info/?l=libressl&m=174664225002441&w=2  
they do intend to fix this, but it's a ways off yet.  
  
Reported-by: Thomas Munro <thomas.munro@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com  
Backpatch-through: 15  

commit   : 27fbf7cb63911ee2bffdb3cca40cf14515203b07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 11:50:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 11:50:33 -0400    

Right now there's only one caller, so that this is merely  
an exercise in shoving code from one module to another,  
but there will shortly be another one.  It seems better to  
avoid having two copies of this highly-subject-to-change test.  
  
Back-patch to v15, where we first introduced some tests that  
don't work with LibreSSL.  
  
Reported-by: Thomas Munro <thomas.munro@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com  
Backpatch-through: 15