PostgreSQL 14.19 commit log

commit   : 4e9da016ade3e75400f6fdc22ed1fed7fdd32f7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:09:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Aug 2025 17:09:37 -0400    

commit   : 2e19ad79e1a14e5dacd0ad3a3ec959fff928ca17    
  
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   : 8967c33c67b85a33fee5ffb9bf16a67b640bacb8    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 Aug 2025 12:37:00 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 11 Aug 2025 12:37:00 -0500    

In the back-branch versions of commit 71ea0d6795, I missed updating  
this test to use --restrict-key so that the generated dump output  
is comparable.  
  
Per buildfarm member hamerkop.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Security: CVE-2025-8714  
Backpatch-through: 13-14  

commit   : e4998d089d903da6114209ae36da747b195375ca    
  
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   : 0f583843840638d5a8ee13e1b6e20e38723cc5d9    
  
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   : 14f193beb27766082d4efacff240568c459fd377    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:45:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Aug 2025 14:45:12 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 37a7b08d01b7b5af07a56872e16ac91a7f14a9b9  

commit   : afe38fb6abb8ef364191201f577a5a638ba55509    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:12:09 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 11 Aug 2025 09:12:09 +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   : e21c9823d387a31d9efe452fff60a88f3c4a7e19    
  
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   : 7846f470964c1858b5f6178028d18dee32d23dd0    
  
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   : 64dec8060c84b9b08c85fe5a757f10a4480ec484    
  
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   : 73eb6afa13605d9bb619752180b739fd3c4ba168    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 17:35:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 17:35:03 +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   : bef2c2a4ebefe5023368c7423ff8e06c98f6d32a    
  
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   : e94fc1a8ad0fdbe797cc4ae18d48919a0cb87240    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 10:50:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Aug 2025 10:50:04 +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   : ed2bb0cdda7764a95d6e1e4019417a7857b6f002    
  
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   : f9f6595e31c41cdc958b828f04c509acf777bec6    
  
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   : fe966e886ce844fda21839d711b0029a46836177    
  
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   : c5d66fc12b0891fd5f2a830ab9fa9feb8df94171    
  
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   : 0edaaa8f2978e9cce964d9815e6b2fbad9d76bd0    
  
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   : a4f891b962359225fb51ba12e62e4d7432e9792e    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:16:00 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 7 Aug 2025 17:16:00 +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   : a00eb374cd2fba9ee0c0e3d408e84288448f5de5    
  
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   : 5b0c8e32894987712759e0ff7bd8577f0c6cae51    
  
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   : 0c27d80d5f0f877a8eec333626348f947f4b6597    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:24:39 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 4 Aug 2025 16:24:39 +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   : 2ea8a37f27847ddc0828a84ab9ebea72df1eaf91    
  
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   : b49cb0b8df5e208c9f1c62675190c704b2630ba3    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:04 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 2 Aug 2025 18:30:04 +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   : 41fb3f51cb74eca1ba959ccd2fb1c0d7fe0bf11b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 07:16:30 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Aug 2025 07:16:30 +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   : 7ee7c1cd389e32599c56ad88a4e74c625ab65d52    
  
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   : 25388fb2cb842bb62d9bf2a884924bd7cb35b5ba    
  
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   : 60953d4cba7cce4a8672b1930d173077ac1130fc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jul 2025 11:55:53 +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   : 2dee95bd0cf18d99e4d4778f18a794160a8dcaba    
  
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   : cdcdabce5b701ffd2e276214ac3cafddc21a72e2    
  
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   : 276b022ec05bbd5a9639fa71e1197d53bac20075    
  
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   : 0395464aff02fd4e18089b904ae826387cabeffb    
  
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   : 50026136cc86c9d8c95135b7d1eebeda516e31ec    
  
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   : 868b39a544edf4fcf15c9dd55859de9dcbbb6717    
  
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   : 408fe659a890e54a303d7f25d9f381ea36754856    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Jul 2025 14:00:10 +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   : 7efaf0a1b3e2ce58f4e4cddaa9afe6a60a978bcf    
  
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   : bedfdb85b0a344c84b04c234339075d676b7b608    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 19 Jul 2025 14:13:40 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 19 Jul 2025 14:13:40 +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   : d5cba774626f3c09df536aeddbf2f8c08a3cecc7    
  
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   : b9a89682846f0dc47fef9d80219ba8fe0d9779c7    
  
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   : 01d1c45c0a8e79f9749292ede89b163f89fabf83    
  
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   : e04aca1c4d33020527dd343b48d9ffe575f3bbd7    
  
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   : 0490d6efd2daede5305fb3c274d11f12e1eda732    
  
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   : 6f7d016e917e7960e791bd2fb9d7c3d53f08b9a4    
  
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   : 8254b7e33be9cebe99286d99940fbe0dde79b970    
  
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   : 209a22d794d5257cd57d001a1a456be444d7f42d    
  
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   : ac8cdb2495d580d6ff08aa624e7851453d3cc2da    
  
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   : 0514616f0e282e8962322fd72c68104ad0c44267    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:20 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:20 -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   : 602c91cf2ef7745bdecac2d3a644a343c7c0a17d    
  
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   : ac166b19a1712126003efb8c2ac9cc334fd3bee1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:54:43 +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   : 94dc2b37baee204c378a7137287fe652285b766e    
  
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   : ea3386cc784a5325f8567542e902287a1379b036    
  
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   : b61ddcaf41cfd19bee8df7096fd8ca2029f89088    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:10:24 +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   : e902f818191fb7adce9d3d14150f56e528662fa9    
  
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   : f062e43484b0a6f8e1c0a2c2ea8b87b367e89f53    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 16:06:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 16:06:26 +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   : e35a0174a9d29c4dac0f2f6f72ee804e83e31825    
  
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   : 71d71ac4d1bbb34a9814f010812e059c29c9472e    
  
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   : 326f2aaee6472c43b8eb3f5528c825ecfdf540a1    
  
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   : 25cab4473525cd3705fc8ee524b85721db967b65    
  
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   : e2f06282124b86a8ab7604c51de2dad749266fee    
  
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   : 5a24c20c8442168fd75ff878eb6f99026a31b58b    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:10 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Thu, 26 Jun 2025 15:03:10 -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   : c079ba3fc2a4ed4801a0adf55cbbf69c961b1ba4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jun 2025 10:03:54 +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   : af2c08671bc55649301d11f5e221b9cead8386ca    
  
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   : 5fbaf0ffb579fff85cecd7ab9233bb76034541a8    
  
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   : 9bd588f87de8ff3949b00d4f544abb4db4bb7e54    
  
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   : 27af8b9be8c05d96d4e8207a93230ef0412bf149    
  
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   : 983b3636259b1502121cbae99d8a2f0d0515d87d    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:50 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 16 Jun 2025 17:35:50 -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   : e2832bd961103a17e281919de7151f80f518cf24    
  
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   : 7c7c0a77dc8a48ba4f88863d8138abd5fbac6cec    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:27 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 11 Jun 2025 09:17:27 -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   : 0703c9385ba0ff435efec0673ca9f15bda941317    
  
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   : a4b9707c417666841733fe4f5bec9b18e184028e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Jun 2025 08:18:20 -0400    

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

commit   : 09498d2f2c739337f58a4412af9d425cfb3ac950    
  
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   : 49584901ecc4eab7c6de05a2518b65eefcb3fa10    
  
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   : eb423464753f5a853ec47209aab05f74fafa9328    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jun 2025 15:22:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jun 2025 15:22:45 -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   : d4556f592eff4829012e3df72c48b9801a954297    
  
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   : 31a3a15fa49d5a433ed076c687db01affa39f65c    
  
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   : b65be6ef00e2bfad7317cc32e33333e8f3a26642    
  
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   : 4a07c096132c389a6d3e42e4af9078999a6a48e8    
  
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   : a7da7914c35527792d63f43316207e6ca7f9b0d3    
  
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   : 9130d8eeebad201741417490c805b57879eb2205    
  
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   : 7f4261d9da35b90d3feb85ea8ea2c7de18913483    
  
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   : 2cd2222ca5f43949036296996dabc6f8f6f963af    
  
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   : 8a1459f62ad16c5fee792faa83ac7ab70a291939    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 May 2025 11:26:31 +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   : 0c09922c04eaec15e50ef4670fa73be8291cbeb9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 09:43:50 +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   : 1fe15d25e65c5ef4fe3be9efd2927f3e3891f7b1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 May 2025 08:59:27 +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   : 14127818e6a01f2a88055ae46c3ef0517a3bf2b4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 26 May 2025 12:50:01 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 26 May 2025 12:50:01 +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   : a79ede0a4ebff1434d6ffd2a15339a1c574bbf6e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 May 2025 14:39:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 May 2025 14:39:15 +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   : 0420b24fee5e6483e1aa032f75edf340c14d4109    
  
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   : e68459489c206b094a7d418071c4c10abd3274cd    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 May 2025 11:15:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 May 2025 11:15:09 +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   : a1e0e7076585323270681dc9a4f9e1272f24db68    
  
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   : 9a8df96f3b86fb8a4154ea3c89c5f57ef0b909ae    
  
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   : 7f4ca9edb4055680ecad56ae50891f5c1c6ad808    
  
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   : 4bccb09f4b7a1efb36bfa01a364a2edc9c97dd0d    
  
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