PostgreSQL 15.14 commit log

commit   : 0ab43b548237b3791261480d6a023f6b95b53942    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:08:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:08:18 -0400    

commit   : 4eb9733b2b76aeaca84e450be8c7653012ab215a    
  
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   : 42404050685de4047a7b57b13f8ec4959666328a    
  
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   : 9751f934aa80f855f742425e16f669c44f6d0b9b    
  
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   : a4f513b5a8cade4fbf2115e3250d56dc7f83166e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:43:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:43:54 +0200    

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

commit   : 415badc138189a6ecfe3b664dc900af741342258    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:11:02 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:11:02 +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   : dfe189ecdf8709b332439ae72693d10b2640234b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Aug 2025 16:31:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Aug 2025 16:31:54 -0400    

commit   : 70637d7ae0a20caffe88559a689a2a00cb1a1d2b    
  
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   : f0d55b68ef920b5ed22c3788a5dfc15fe1f70be7    
  
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   : f39a7f32aefcd424bdbe001f08718eaad5170d6b    
  
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   : 18d2d8ae42af4d3a73b6ae067dead8663f92afb8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 08:47:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 08:47:10 +0200    

This came from the backport of commit f295494d338, but older branches  
require the explicit newline in messages (see commit 7652353d87a).  

commit   : d642d23064ea1bf29137336e2a17d1bba988cb41    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 10:50:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 10:50:03 +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   : 769be67a3c7adc733f31239474a08e6da9ed0145    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Aug 2025 09:07:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Aug 2025 09:07:55 +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   : a8b31b160bf643a4a7f590a4375d5d268152bda6    
  
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   : 22d7833505a50840d0c2f45030408ce827452dc4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 00:11:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Aug 2025 00:11:33 +0200    

This came from the backport of commit f295494d338, but older branches  
require the explicit newline in messages (see commit 7652353d87a).  

commit   : 186bc0dfdcb0d4376ffe575bc75a8caf020abbfc    
  
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   : 73f897ba5836c1341bec460c618ac76264d986c8    
  
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   : 098c27dee4c15222daeb9c15a3db8ec18d24a26f    
  
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   : baacfb9e609cbd7b210225fa25bfc94e518aaabf    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:15:09 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:15:09 +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   : 63c79a6fc23f0cd1220524fe120e7942b90f53bf    
  
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   : 835c9374d630dad82a50052388df8333a8c5bc94    
  
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   : 8748148d610223b1926ea0cfaba60011c88c8c76    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:23:28 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:23:28 +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   : 2f600115a5a95e94f4085a5114ace0116314c4a4    
  
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   : 6914a330f019feab9fb90fc7d79c93e24ca3193f    
  
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   : 23dc277590a9208859408a6907eaed182a18d1e2    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:03 +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   : f79ca73d75cb551f46b37b14407ae42a50b6d38c    
  
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   : 434d2d147b589206c58b4cdae366f353fe63f4eb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 07:23:37 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 07:23:37 +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   : 22f126da6ccebdafea77908a4a80d73d7735dcf1    
  
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   : e99010cbd8e27d4074646f508e9a273fd0e9322e    
  
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   : d6ffc43f95b215fbedba102d343cd31cdd3a5ca7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:51 +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   : 19857437b07353908c7daac8e9aac86eda35051b    
  
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   : 0928e18eb85a98c0772d1c1f3f6a8f246ea97ca1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jul 2025 12:47:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jul 2025 12:47:20 -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   : 9af075c4e27ebe8d18e9b4f4bbd6b88ae73bd61a    
  
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   : 0ffbd345e43dfb556072d72c918f0fd2b7f02332    
  
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   : b248a3ba4e51328f6289c28b30d5145bdde0a937    
  
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   : b252ce31116f5acc7bd9fe6f3795d6e8537570ff    
  
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   : 0123922f82d2b5349917ecbd4ec197ee6acfa388    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:08 +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   : f4a67e52b2a1a4f74297efdf3b3613b420d852f9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sun, 20 Jul 2025 12:00:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sun, 20 Jul 2025 12:00:46 +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   : 9f270f48f3fed358d62e13ec8c090124d47d86a0    
  
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   : a372a64db794611e916a8281ee8269a4441713b0    
  
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   : c2720ac6010a06427330b3b21ac5d3d012835da5    
  
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   : 6242497bb402f3fa40bab4459443374039137f31    
  
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   : 5a261c135d43857b3d614399bd6dd0c058dc6bbe    
  
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   : 4349206cc3c389ac36b0e40819674a1ef0d931ce    
  
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   : 2132ced7dc976bd83addf7d62acde5e2540342d7    
  
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   : f32e456414601a6cbf48eb33560f5074fa0a2d4b    
  
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   : 5ea9d9ac0c332b79dc4d51e093e1daef46ddcf61    
  
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   : de73cb3ed6cc9d51350ac54528c5ffc688aab6ce    
  
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   : e3584e457db2dc9fa0310bfd8d9d07fe65a281d3    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:23 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:23 -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   : c65c36ab51952059c362807d7c353c9c19355bc0    
  
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   : 75c1eb60b2ccae893cf05eaab04668bdb4655864    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:41 +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   : bd48455d88a8e69a85f040018e9dd8c7d129ea0e    
  
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   : 0f49586850a905ec61220f6045d2a8480877414e    
  
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   : dcbbd43317c0c089c24952782a30f1717f6f99be    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:22 +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   : e6dd6e6ee6e1443441088173231fe9085ce4b912    
  
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   : 8a010df41e0248dc945efde26bc7c9d152ac24b7    
  
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   : d44efe87ea753f9e5c764f8577cd131b74eb6e21    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:48 +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   : 37b1fce858672bcd0350c24a9c5e4689de3a6cb7    
  
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   : a167e654d06fa2ae7ba7e0f635b384cead8f6b7c    
  
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   : 0fb496c704fce0daeb01cb3736a827ec009f382e    
  
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   : 8f456630ce9354a96f20c00a1339a59f33da2930    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 10:36:27 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 10:36:27 -0500    

These functions have been around for some time, but commits  
48b5aa3143 and 15afb7d61c were only back-patched to v16.  Let's  
back-patch them to all supported versions now.  
  
Reported-by: David Rowley <dgrowleyml@gmail.com> (commit 48b5aa3143)  
Author: Bruce Momjian <bruce@momjian.us> (commit 48b5aa3143)  
Co-authored-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> (commit 15afb7d61c)  
Reviewed-by: Michael Paquier <michael@paquier.xyz> (commit 15afb7d61c)  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/aGMCxHxLfeMdQk8m%40nathan  
Backpatch-through: 13-15  

commit   : 614ffb26d1cd9a068e8ba2761a5aad64100f4d6d    
  
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   : 4dc48ad28d96326ff6b56331863b96fff0c9414d    
  
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   : 98dd121fc8fce85da3ad20382fe3deb1586f9cb1    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:19 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:19 -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   : ba33505c5fe47d793aeec25b1b321b6d39dec8fb    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:39:52 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 26 Jun 2025 09:39:52 +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   : 354944663df38a360f8519814658a10cb5c3d04a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:53 +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   : fd94f856a42c20dd107c700a5946bab8f16cea27    
  
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   : 4f3eedc8a3626731f3e1afc1a0772517277095c3    
  
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   : ccfe3dbaa4392ec1cf50224c57eccd0f34ce8d1d    
  
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   : 75b8982eae78f930cc8c1c48cd2d9dc03113d92b    
  
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   : fc0fb77c550fe8289d718c33c7aacf16023d9941    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:53 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:53 -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   : dd9bc1a17d0324448c45c6fc0a2d258b9134bfc3    
  
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   : d2ec671092a1144fcaa6b465b4672e937a68b65f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:29 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:29 -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   : 6a4d93edad4b0afc1c04ffa76c155648c3b35c08    
  
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   : d59ff3be24a336ab080c66fa6ceafbf52e7be1c1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:22 -0400    

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

commit   : 74637fb797778e7ee1111c6f0c40f95680d21768    
  
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   : efb3f16e0d348cb7c6e8a0507a280a6537f580b7    
  
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   : e76097124f7d6679d287701ab108aa20088b13a6    
  
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   : b898bb2a79ae1f2d54f3d21a22382059a2c2e40c    
  
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   : b56a92651ad43fbea087f7659f8d190825be80e2    
  
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   : d6a3f3272ffee792e27c5dd871d7cf1cbf418962    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:21:02 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 May 2025 12:21:02 +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   : ddfcfb7cec686cc768795d025344d412b5fcc673    
  
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   : 3c31594f55cd210bbee4e2ac92c2610b8c260f2c    
  
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   : 39b1d190714a11f98cb35916a7ceb1a998e24062    
  
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   : 405cca9daa422913a83b3b7678f12e745d9c94a6    
  
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   : 4620cd9c1c80984419ff135bfc1a9c79ff16ab6f    
  
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   : 09c9ae8f6d3a3260ad104f09bcdf62920172712f    
  
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   : 130300a1540780a4df91d990763167e9e3568bc7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:29 +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   : 4dc642e75f1c6606c0904894841276c18f1d315d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:48 +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   : b3e99115e44c5040c949c99d081ff3812e6ec4a3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:25 +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   : 6b0d69d34396685dfeadbb288754ce9146955b38    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 May 2025 17:28:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 May 2025 17:28:43 +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   : 0f29022e05919abe51522a9aef4f1a2aeeb766ea    
  
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   : 13d21b48a3a4eef4227339d177a5ce2ed2879447    
  
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   : 0e0174b4973af2982498c33f7911312250b330ca    
  
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   : 009e8a85d32aaea7aa19505fc9023dcb9a80e255    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 May 2025 14:39:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 May 2025 14:39:14 +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   : 72fe74ca533375fa04264f976d4c4971c6804dce    
  
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   : 9d1a6235960697b5dbc5e0b7d56d59c0a6de3b3d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 May 2025 11:28:19 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 May 2025 11:28:19 +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   : 00652b3c9fb7bf2122bb076d63b15bc65e12ff71    
  
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   : 113351ee17230bc1727ea117d53e2ae83fa7e98f    
  
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   : 666103090f1d18e26388aef1ee5840d86cb8604b    
  
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   : 7f1da18d679e125eb454ce31fdd2b69d4da32d68    
  
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   : d2d3cd056dc451f8a7dcd343c9e44a901d177a25    
  
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   : 793aa989f8e411ff91ba501fbc2030062f252d01    
  
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   : 00811a96ac45dc11cf2e144927b5c75645454d28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 12:24:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 12:24:25 -0400    

The previous commit assumed we have a configure probe for  
SSL_CTX_set_cert_cb.  v15 lacks that, so add it now.  
(Details borrowed from 36f40ce2d.)  
  
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 only  

commit   : 1ddb9e14eadf95802c835a3754af5621615ded30    
  
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