PostgreSQL 18.0 (upcoming) commit log

commit   : 5987553fde2cb22b69cf9c7d71a92573b7a3b7c9    
  
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   : fe29b2a1dab2b3d81e6c350679b7d9b0e1c8c850    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 15 May 2025 17:09:04 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 15 May 2025 17:09:04 +0900    

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

commit   : 2c0ed86d393670c7054d051490063de771f1791e    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 14 May 2025 09:59:31 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 14 May 2025 09:59:31 +0900    

When creating a new PlannerGlobal node in standard_planner(), most  
fields are explicitly initialized, but a few are not.  This doesn't  
cause any functional issues, as makeNode() zeroes all fields by  
default.  However, the inconsistency is undesirable from a clarity and  
maintenance perspective.  
  
This patch explicitly initializes the remaining fields to improve  
consistency and readability.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs4-TgQHNOiouqGcuHoBqbJjWyx4UxGKxUY3FrF4trGbcPA@mail.gmail.com  

commit   : 6e289f2d5da02b450f00fb57f0facc60bd73c0d1    
  
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   : 8ede692de512750ecb6930213e6d78ed90ef06d0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 13 May 2025 09:54:29 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 13 May 2025 09:54:29 +0530    

After executing ALTER SUBSCRIPTION tap_sub SET PUBLICATION, we did not  
wait for the new walsender process to restart. As a result, an INSERT  
executed immediately after the ALTER could be decoded and skipped,  
considering it is not part of any subscribed publication. And, the old  
apply worker could also confirm the LSN of such an INSERT. This could  
cause the replication to resume from a point after the INSERT. In such  
cases, we miss the expected warning about the missing publication.  
  
To fix this, ensure the walsender has restarted before continuing after  
ALTER SUBSCRIPTION.  
  
Reported-by: Tom Lane as per CI  
Author: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/1230066.1745992333@sss.pgh.pa.us  

commit   : dbf42b84ac7b4e1dfd1ac6e618e247100b6aa08b    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 10:16:45 -0400    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 10:16:45 -0400    

We can add tab-completion with "CHECK (" and "NOT NULL" after ALTER  
DOMAIN ADD [CONSTRAINT].  
  
ALTER DOMAIN dom ADD -> CHECK (  
ALTER DOMAIN dom ADD -> NOT NULL  
ALTER DOMAIN dom ADD -> CONSTRAINT  
ALTER DOMAIN dom ADD CONSTRAINT nm -> CHECK (  
ALTER DOMAIN dom ADD CONSTRAINT nm -> NOT NULL  
  
Author: jian he <jian.universality@gmail.com>  
Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Discussion: https://postgr.es/m/CACJufxG_f6LzAT_McC-kKmQWpuWnOYKyNBw8Kv3xzTjPqmeHcA@mail.gmail.com  

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

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

commit   : dc9a2d54fd2571c21c074103cc8ddd93e840b985    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 09:22:12 -0400    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 09:22:12 -0400    

As complained about by Valgrind, in commit a379061a22a8 I failed to  
realize that I was causing rd_att->constr->check to become allocated  
when no CHECK constraints exist; previously it'd remain NULL.  (This was  
my bug, not the mentioned commit author's).  Fix by making the  
allocation conditional, and set ->check to NULL if unallocated.  
  
Reported-by: Yasir <yasir.hussain.shah@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/202505082025.57ijx3qrbx7u@alvherre.pgsql  

commit   : 7b2ad4342603c9796bf28dbe84aca247b2bfa9f8    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 09:15:05 -0400    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sun, 11 May 2025 09:15:05 -0400    

Added by commit 042a66291b04, no backpatch needed.  

commit   : d4a7e4e179f946e12708f758d30a07f931fd5a84    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2025 20:22:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2025 20:22:39 -0400    

This must be "return MemoryContextAllocationFailure(context, size, flags)"  
instead.  The effect of this oversight is that if we got a malloc  
failure right here, the code would act as though MCXT_ALLOC_NO_OOM  
had been specified, whether it was or not.  That would likely lead  
to a null-pointer-dereference crash at the unsuspecting call site.  
  
Noted while messing with a patch to improve our Valgrind leak  
detection support.  Back-patch to v17 where this code came in.  

commit   : 4a4ee0c2c1e53401924101945ac3d517c0a8a559    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 10 May 2025 07:36:27 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 10 May 2025 07:36:27 -0700    

Commit f4ece891fc2f3f96f0571720a1ae30db8030681b added the assertion in  
an attempt to catch some defects even after VACUUM FULL or REINDEX.  
However, IsCatalogTextUniqueIndexOid(tag.relNumber) always returns false  
after a relfilenode change, provoking unintended assertion failures.  
  
Reported-by: Adam Guo <adamguo@amazon.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Bug: #18912  
Discussion: https://postgr.es/m/18912-a41c9bd0e0ad19b1@postgresql.org  

commit   : 99ddf8615c215bb81655574b9a9f7e8ebb2cb89e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 9 May 2025 23:39:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 9 May 2025 23:39:34 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvqJz+Zf7a6abisqoTGottDSRD+YPx=aQSgCsCKD476vGA@mail.gmail.com  

commit   : c259ba881c1098e75b53d5b232600b49e3301058    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 May 2025 12:36:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 May 2025 12:36:57 +0900    

This cleans up the code related to the testing infrastructure of AIO  
that used injection points, switching the test code to use the new  
facility for injection points added by 371f2db8b05e rather than tweaks  
to pass and reset arguments to the callbacks run.  
  
This removes all the dependencies to USE_INJECTION_POINTS in the AIO  
code.  pgaio_io_call_inj(), pgaio_inj_io_get() and pgaio_inj_cur_handle  
are now gone.  
  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/Z_y9TtnXubvYAApS@paquier.xyz  

commit   : 36e5fda6326045f4523568d4c9d682ee5d2f0867    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 May 2025 07:40:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 May 2025 07:40:25 +0900    

This commit provides some test coverage for the runtime arguments of  
injection points, for both INJECTION_POINT_CACHED() and  
INJECTION_POINT(), as extended in 371f2db8b05e.  
  
The SQL functions injection_points_cached() and injection_points_run()  
are extended so as it is possible to pass an optional string value to  
them.  
  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/Z_y9TtnXubvYAApS@paquier.xyz  

commit   : 371f2db8b05e4d46cbf489f05cbfc4d6ed6976d4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 May 2025 06:56:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 May 2025 06:56:26 +0900    

The macros INJECTION_POINT() and INJECTION_POINT_CACHED() are extended  
with an optional argument that can be passed down to the callback  
attached when an injection point is run, giving to callbacks the  
possibility to manipulate a stack state given by the caller.  The  
existing callbacks in modules injection_points and test_aio have their  
declarations adjusted based on that.  
  
da7226993fd4 (core AIO infrastructure) and 93bc3d75d8e1 (test_aio) and  
been relying on a set of workarounds where a static variable called  
pgaio_inj_cur_handle is used as runtime argument in the injection point  
callbacks used by the AIO tests, in combination with a TRY/CATCH block  
to reset the argument value.  The infrastructure introduced in this  
commit will be reused for the AIO tests, simplifying them.  
  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/Z_y9TtnXubvYAApS@paquier.xyz  

commit   : 89372d0aaa4a6f0e560acdf9014c5ad66fdde1b1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 9 May 2025 14:15:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 9 May 2025 14:15:54 -0400    

Reported-by: Steven Niu  
  
Discussion: https://postgr.es/m/CABBtG=ejqK58cFWpw3etVZfQfhjC-qOqV+9GQWRnLO+p9wYMbw@mail.gmail.com  

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

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

commit   : 75d73331d0146871c846e849be626cb220e7e013    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 11:53:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2025 11:53:51 -0400    

With LibreSSL, our test of error logging for cert chain depths > 0  
reports the wrong certificate.  This is almost certainly their bug  
not ours, so just tweak the test to accept their answer.  
  
No back-patch needed, since this test case wasn't enabled before  
e0f373ee4.  
  
Reported-by: Thomas Munro <thomas.munro@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com  

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

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

commit   : bc35adee8d7ad38e7bef40052f196be55decddec    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 9 May 2025 08:55:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 9 May 2025 08:55:05 +0200    

commit   : b28c59a6cd089902e66a91e0d0974da34d1c922b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2025 22:01:25 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2025 22:01:25 +0300    

A 'void *' argument suggests that the caller might pass an arbitrary  
struct, which is appropriate for functions like libc's read/write, or  
pq_sendbytes(). 'uint8 *' is more appropriate for byte arrays that  
have no structure, like the cancellation keys or SCRAM tokens. Some  
places used 'char *', but 'uint8 *' is better because 'char *' is  
commonly used for null-terminated strings. Change code around SCRAM,  
MD5 authentication, and cancellation key handling to follow these  
conventions.  
  
Discussion: https://www.postgresql.org/message-id/61be9e31-7b7d-49d5-bc11-721800d89d64@eisentraut.org  

commit   : 965213d9c56a671086525a65f5427653b4a66350    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2025 22:01:20 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2025 22:01:20 +0300    

The documented max length of a cancel key is 256 bytes, so it fits in  
uint8. It nevertheless seems weird to not just use 'int', like in  
commit 0f1433f053 for the backend.  
  
Discussion: https://www.postgresql.org/message-id/61be9e31-7b7d-49d5-bc11-721800d89d64%40eisentraut.org  

commit   : 9d710a1ac0912244934277a99fe4666df3d2b825    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 May 2025 11:11:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 May 2025 11:11:08 -0400    

Reported-by: jian he  
  
Discussion: https://postgr.es/m/CACJufxFM1avdwu=OrTx_uMAjTDbFOj1Gp7mnNHOofTVj9QtmRw@mail.gmail.com  

commit   : 8fcc6487809efa5508a4b70049402236a53be84d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 8 May 2025 13:53:16 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 8 May 2025 13:53:16 +0200    

The title for AT TIME ZONE and AT LOCAL was accidentally wrapping the  
"and" in the <literal> tag.  Backpatch to v17 where it was introduced  
in 97957fdbaa42.  
  
Author: Noboru Saito <noborusai@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Tatsuo Ishii <ishii@postgresql.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAAM3qn+7QUWW9R6_YwPKXmky0xGE4n63U3EsxZeWE_QtogeU8g@mail.gmail.com  
Backpatch-through: 17  

commit   : c06e909c26f070dee78f73c35565d6f4a4ffdcda    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 8 May 2025 18:21:32 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 8 May 2025 18:21:32 +0900    

When creating an explicit Sort node for the outer path of a mergejoin,  
we need to determine the number of presorted keys of the outer path to  
decide whether explicit incremental sort can be applied.  Currently,  
this is done by repeatedly calling pathkeys_count_contained_in.  
  
This patch caches the number of presorted outer pathkeys in MergePath,  
allowing us to save several calls to pathkeys_count_contained_in.  It  
can be considered a complement to the changes in commit 828e94c9d.  
  
Reported-by: David Rowley <dgrowleyml@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAApHDvqvBireB_w6x8BN5txdvBEHxVgZBt=rUnpf5ww5P_E_ww@mail.gmail.com  

commit   : 773db22269d474fab46d25e9e15b1e55252cf92c    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 8 May 2025 18:20:18 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 8 May 2025 18:20:18 +0900    

When building a ForeignPath for a joinrel, if there's a possibility  
that EvalPlanQual will be executed, we must identify a suitable path  
for EPQ checks.  If the outer or inner path of the chosen path is a  
ForeignPath representing a pushed-down join, we replace it with its  
fdw_outerpath to ensure that the EPQ check path consists entirely of  
local joins.  
  
If the chosen path is a MergePath, and its outer or inner path is a  
ForeignPath that is not already well enough ordered, the MergePath  
will have non-NIL outersortkeys or innersortkeys indicating the  
desired ordering to be created by an explicit Sort node.  If we then  
replace the outer or inner path with its corresponding fdw_outerpath,  
and that path is already sufficiently ordered, we end up in an  
inconsistent state: the MergePath has non-NIL outersortkeys or  
innersortkeys, and its input path is already properly ordered.  This  
inconsistency can result in an Assert failure or the addition of a  
redundant Sort node.  
  
To fix, check if the new outer or inner path of a MergePath is already  
properly sorted, and set its outersortkeys or innersortkeys to NIL if  
so.  
  
Bug: #18902  
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/18902-71c1bed2b9f7c46f@postgresql.org  

commit   : 9fef27a83b3112655509241107834086628f7fa8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 21:11:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 21:11:16 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvrGLBqs_Vm9COMY7uBDvUDMKds7RwC20YjEPf+XRTY9XQ@mail.gmail.com  

commit   : f8d49aa130b213d66beae0f574917c1884f7b2a9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 20:36:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 20:36:21 -0400    

Now zero-based.  
  
Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvqMfTBdfwc0Z-tHXLnBMKJLYEZDApgUzA7x_PUDZsY3GA@mail.gmail.com  

commit   : 69aca072ebf64dcf36958b6958ce4388480fcba2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 16:56:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 16:56:26 -0400    

Also run src/tools/add_commit_links.pl for a previous commit.  
  
Reported-by: Yugo Nagata  
  
Discussion: https://postgr.es/m/20250507195941.c6e1b48c73f062b727f686a8@sraoss.co.jp  

commit   : 3bd5271729c5496e3712c9ffbb002a6bef99a4c3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 16:39:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 May 2025 16:39:26 -0400    

Reported-by: Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs4_asKPqTCt0h9pp=zHc9vmPcnczbHeF6Xkxn1LhLapcTQ@mail.gmail.com  

commit   : 16bf24e0e471c975f0877d6612eacdae7ce4a30e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 7 May 2025 14:47:36 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 7 May 2025 14:47:36 -0500    

A few places that access this catalog don't set up an active  
snapshot before potentially accessing its TOAST table.  However,  
roname (the replication origin name) is the only varlena column, so  
this is only a problem if the name requires out-of-line storage.  
This commit removes its TOAST table to avoid needing to set up a  
snapshot.  It also places a limit on replication origin names so  
that attempts to set long names will fail with a more user-friendly  
error.  Those chosen limit of 512 bytes should be sufficient to  
avoid "row is too big" errors independent of BLCKSZ, but it should  
also be lenient enough for all reasonable use-cases.  
  
Bumps catversion.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/ZvMSUPOqUU-VNADN%40nathan  

commit   : 5f4d98d4f3718cf7a0597c37f3ee4a4485de6ef8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 May 2025 15:20:42 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 May 2025 15:20:42 -0400    

nbtree array index scans could fail to return matching tuples in rare  
cases where the missed tuples cover key space that the scan's arrays  
incorrectly indicate has already been read.  These cases involved nearby  
tuples with NULL values that were evaluated using a skip array key while  
in pstate.forcenonrequired mode.  
  
To fix, prevent forcenonrequired mode from prematurely advancing the  
scan's array keys beyond key space that the scan has yet to read tuples  
from: reset the scan's array keys (to the first elements in the current  
scan direction) before the _bt_checkkeys call for pstate.finaltup.  That  
way _bt_checkkeys starts from a clean slate, which ensures that it will  
call _bt_advance_array_keys (while passing it sktrig_required=true).  
This reliably restores the invariant that the scan's arrays always  
accurately track its progress through the index's key space (at least  
when the scan is "between pages").  
  
Oversight in commit 8a510275, which optimized nbtree search scan key  
comparisons.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/CAH2-WzmodSE+gpTd1CRGU9ez8ytyyDS+Kns2r9NzgUp1s56kpw@mail.gmail.com  

commit   : 7e25c9363a82b6974c1ca2303ae8ded98af3bb24    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 May 2025 15:17:40 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 May 2025 15:17:40 -0400    

Be more conservative when performing a scheduled recheck of an nbtree  
scan's array keys once on the next page, having set so->scanBehind: back  
out of reading the page (perform another primitive scan instead) when  
the next page's high key/finaltup has an untruncated prefix of matching  
values and truncated suffix attributes associated with lower-order keys.  
In other words, stop assuming that the lower-order keys have been  
satisfied by the truncated suffix attributes in this context (only do so  
when considering scheduling a recheck within _bt_advance_array_keys).  
  
The new behavior is more logical: if the next page read after setting  
so->scanBehind can only contain tuples that are themselves "behind the  
scan", that's reason enough to cut our losses.  In general, when we set  
so->scanBehind, we only expect to perform one recheck on the next page  
to make a final decision about whether or not to continue the current  
primitive index scan.  It seems unprincipled for the recheck to allow a  
_bt_readpage to continue unless the scan's arrays will advance/unless  
the page might actually contain relevant tuples.  
  
In practice it is highly unlikely that things will line up like this  
(the untruncated prefix of attribute values from the next page's high  
key is seldom an exact match for their corresponding array's current  
element following array advancement on the original/previous page).  
That gives us all the more reason to keep things simple and consistent.  
  
This was arguably an oversight in commit 9a2e2a285a, which improved  
nbtree array primitive scan scheduling.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-WzkXzJajgyW-pCQ7vaDPhaT3huU+Zw_j448rpCBEsu2YOQ@mail.gmail.com  

commit   : acea3fc49f006a08e6c540ac0bacc2c2577a5ff9    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 7 May 2025 13:36:51 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 7 May 2025 13:36:51 -0500    

I recently added this option to pg_dump, but I forgot to add it to  
pg_dumpall, too.  There's probably little use for it at the moment,  
but we will need it if/when we teach pg_upgrade to use pg_dumpall  
to dump the database schemas.  
  
Oversight in commit 9c49f0e8cd.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aBE8rHFo922xQUwh%40nathan  

commit   : ab42d643c14509cf1345588f55d798284b11a91e    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 May 2025 11:10:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 May 2025 11:10:16 +0300    

fc069a3a6319 implemented Self-Join Elimination (SJE) and put related logic  
to ChangeVarNodes_walker().  This commit provides refactoring to remove the  
SJE-related logic from ChangeVarNodes_walker() but adds a custom callback to  
ChangeVarNodesExtended(), which has a chance to process a node before  
ChangeVarNodes_walker().  Passing this callback to ChangeVarNodesExtended()  
allows SJE-related node handling to be kept within the analyzejoins.c.  
  
Reported-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Author: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : 2448c7a9e00536bac8704bff402bc02c2b2f23de    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 20:38:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 20:38:42 +0200    

commit   : c0cf28255178f1d6e20a26c8df0a4cfdd0ab3b24    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 13:04:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 13:04:46 +0200    

commit   : c11bd5f500f0b774a766ed67b769d63abdbdae91    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 12:43:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 12:43:10 +0200    

Formal tables should generally have an xref in the text that points to  
them.  Add them here.  

commit   : a2c6d84acd72d6c43ab7361fb34fa4f758da7a41    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 12:39:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 4 May 2025 12:39:21 +0200    

commit   : c4c236ab5c416131baa7109cdc25ccaadd4d7158    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 May 2025 14:55:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 May 2025 14:55:57 +0900    

IO workers are treated as auxiliary processes.  The comments fixed in  
this commit stated that there could be only one auxiliary process of  
each BackendType at the same time.  This is not true for IO workers, as  
up to MAX_IO_WORKERS of them can co-exist at the same time.  
  
Author: Cédric Villemain <Cedric.Villemain@data-bene.io>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/e4a3ac45-abce-4b58-a043-b4a31cd11113@Data-Bene.io  

commit   : 09a47c68e2fce446849ce0262eff1bfbf921fa18    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 May 2025 07:01:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 May 2025 07:01:03 +0200    

commit   : b560ce7884a32ba6409adab340b9732dcd210284    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 21:15:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 21:15:44 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvqgK7uqPZAwxsfBiFhvBHHB0txaUxhUrdwG4d5Mik_RnA@mail.gmail.com  

commit   : ada78f9bef2eb47b0711a9eec07529c0da7c5672    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 17:17:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 17:17:46 -0400    

Reported-by: jian he  
  
Discussion: https://postgr.es/m/CACJufxH1jo=hv77AK0HUJYBBMuPmr6+JT+8g-yovuJmHUPGOZQ@mail.gmail.com  

commit   : 575f6003eddbaf0d08195e1e48aee9a741518d6d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 16:03:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 16:03:56 -0400    

Reported-by: Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqE+8Pui_NCCC7zgacnet0Cf3tc_vU+P=nhLDES-8xuCUw@mail.gmail.com  

commit   : 45750c6cfe8d1ba6018366642a35e661b9d6f3af    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 15:45:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2025 15:45:03 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvo+BrVTXMBPjNXBTnAovJWN9+-dYc0kN7rSDqdNvpggZQ@mail.gmail.com  

commit   : caa76b91a60681dff0bf193b64d4dcdc1014e036    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2025 16:25:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2025 16:25:46 -0400    

commit   : c0e6aace02b6c47e7b99d49cc0e88918349ac30a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 15:42:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 15:42:03 -0400    

Reported-by: Jacob Champion  
  
Discussion: https://postgr.es/m/CAOYmi+mEQOqBSJas5V5t__b+6h_MLxyy3JFrVJEq638fnNxi0A@mail.gmail.com  

commit   : 0de2e1c8b5423c07700112f44499a5fdc0ab0991    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 14:56:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 14:56:58 -0400    

This is for WAL statistics.  
  
Reported-by: Bertrand Drouvot  
  
Discussion: https://postgr.es/m/aBjGlj+Yi++fVRQt@ip-10-97-1-34.eu-west-3.compute.internal  

commit   : 092e72a93023fc9cea9cf673ab577ccd8537fb69    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 12:30:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 12:30:35 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvrNmGncNgZMh2oBG5K-+4d1LGJgzrz7180OcHRT1VFojw@mail.gmail.com  

commit   : cf847d6340a6620251315fccae3bd87d2116d308    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 11:59:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 May 2025 11:59:56 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvohfoJ0D9eiUuVyHU_kq2Y7A_jAjWVsUt0Fm7Gw1Q=1cQ@mail.gmail.com  

commit   : 627acc3caa74caa736b2c5587e944d2ea510ea67    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 May 2025 04:52:04 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 May 2025 04:52:04 -0700    

With GB18030 as source encoding, applications could crash the server via  
SQL functions convert() or convert_from().  Applications themselves  
could crash after passing unterminated GB18030 input to libpq functions  
PQescapeLiteral(), PQescapeIdentifier(), PQescapeStringConn(), or  
PQescapeString().  Extension code could crash by passing unterminated  
GB18030 input to jsonapi.h functions.  All those functions have been  
intended to handle untrusted, unterminated input safely.  
  
A crash required allocating the input such that the last byte of the  
allocation was the last byte of a virtual memory page.  Some malloc()  
implementations take measures against that, making the SIGSEGV hard to  
reach.  Back-patch to v13 (all supported versions).  
  
Author: Noah Misch <noah@leadboat.com>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 13  
Security: CVE-2025-4207  

commit   : 5be213caaa1a9a65dfdbbf400b6a53b5e743b8d1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 May 2025 04:52:04 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 May 2025 04:52:04 -0700    

Start the file with static functions not specific to pe_test_vectors  
tests.  This way, new tests can use them without disrupting the file's  
layout.  Change report_result() PQExpBuffer arguments to plain strings.  
Back-patch to v13 (all supported versions), for the next commit.  
  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Backpatch-through: 13  
Security: CVE-2025-4207  

commit   : 18c4fff640b5a5a12efc61fb202355675b9ce904    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 May 2025 12:04:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 May 2025 12:04:49 +0200    

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

commit   : b3754dcc9ff7aba2268e98ecf4b5546353305cd2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 4 May 2025 22:37:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 4 May 2025 22:37:20 -0400    

Reported-by: Atsushi Torikoshi  
  
Discussion: https://postgr.es/m/CAM6-o=CEF6tKAjtGMEOd45YySwNRXPu8d_zyYq=fhnia9hOU6Q@mail.gmail.com  

commit   : d83981c24be76b64205158b59b6c05cf118187c3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 4 May 2025 22:08:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 4 May 2025 22:08:20 -0400    

Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/202505041135.cpo7zgdcya2u@alvherre.pgsql  

commit   : 8c9eec540dc4ba684b74e3ccab8413f358a2f93d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 4 May 2025 21:44:39 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 4 May 2025 21:44:39 -0400    

Reported-by: Jelte Fennema-Nio  
  
Discussion: https://postgr.es/m/CAGECzQQehQrhkNNXvLiBgE3odBbTPG=9PzV8F4Oqq3kOorK0Sw@mail.gmail.com  

commit   : a675149e87706d01e4007150a0124b89bdef08be    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 18:49:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 18:49:40 -0400    

Reported-by: Jelte Fennema-Nio  
  
Discussion: https://postgr.es/m/CAGECzQT4804OLOP+nDBxDpMw3Soq=g+fKOE7NryBHggy4GgEcg@mail.gmail.com  

commit   : 2782f3b8454676c9df408aa0bc960efca0f3eb22    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 3 May 2025 22:42:05 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 3 May 2025 22:42:05 +0300    

This reverts commit 250a718aadad68793e82103282247556a46a3cfc.  
It shouldn't be pushed during the release freeze.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/E1uBIbY-000owH-0O%40gemulon.postgresql.org  

commit   : 250a718aadad68793e82103282247556a46a3cfc    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 3 May 2025 22:30:52 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 3 May 2025 22:30:52 +0300    

fc069a3a6319 implemented Self-Join Elimination (SJE) and put related logic  
to ChangeVarNodes_walker().  This commit provides refactoring to remove the  
SJE-related logic from ChangeVarNodes_walker() but adds a custom callback to  
ChangeVarNodesExtended(), which has a chance to process a node before  
ChangeVarNodes_walker().  Passing this callback to ChangeVarNodesExtended()  
allows SJE-related node handling to be kept within the analyzejoins.c.  
  
Reported-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Author: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : fb21ed6c38da719149443e78048790c0347e2c9b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 14:45:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 14:45:26 -0400    

commit   : 24987c6f0687576da97b593c6dd5740ccdd23277    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 12:57:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 12:57:18 -0400    

With a nod to PG 9.6.  
  
Reported-by: jian he  
  
Discussion: https://postgr.es/m/CACJufxEqs=EXZETwtaOooTFhZrtxvSWg8M2uPfzjNtS3wQ6Dzw@mail.gmail.com  

commit   : 04b269da56db966bd439bf4634a0f33c166eae2e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 12:19:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 3 May 2025 12:19:31 -0400    

Reported-by: Jelte Fennema-Nio  
  
Discussion: https://postgr.es/m/CAGECzQSTBgTsDJPxOHWKo7106-YnnYQGzpzNJdis+xTKGUhu2g@mail.gmail.com  

commit   : 5201bba266d7127397e08a2d954faa5a996c0139    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 3 May 2025 20:00:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 3 May 2025 20:00:00 +0900    

The previous code was allocating more memory and copying more data than  
necessary because it specified the wrong PgStat_KindInfo member as the  
size argument for MemoryContextAlloc and memcpy, respectively.  
  
Although these issues exist since 5891c7a8e, there have been no reports  
from the field.  So for now, it seems sufficient to fix them in master.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Gurjeet Singh <gurjeet@singh.im>  
Discussion: https://postgr.es/m/CAPmGK15eTRCZTnfgQ4EuBNo%3DQLYGFEbXS_7m2dXqtkcT7L8qrQ%40mail.gmail.com  

commit   : 6e91b9c16ff53fadf75a545aabe5907f1c046d2f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 3 May 2025 19:10:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 3 May 2025 19:10:00 +0900    

Also adjust the phrasing in the comments.  
  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Author: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Gurjeet Singh <gurjeet@singh.im>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAPmGK17%3DPHSDZ%2B0G6jcj12buyyE1bQQc3sbp1Wxri7tODT-SDw%40mail.gmail.com  
Backpatch-through: 15  

commit   : 9fd989ff9937966a8c3f28bfb6cce8f8071b3289    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 May 2025 20:10:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 May 2025 20:10:10 -0400    

commit   : 9f8fcadb2087d3178dc01de37e59ba9a0c70dd31    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 May 2025 20:09:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 May 2025 20:09:12 -0400    

Reported-by: Jelte Fennema-Nio  
  
Discussion: https://postgr.es/m/CAGECzQQj0r_JX38fa-_kepp9UaMzCcujRAYaJG2+fPks1b8MVg@mail.gmail.com  

commit   : aa82ebdc297073ab1bb51cfc0322a6f9e81a13f5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 May 2025 19:58:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 May 2025 19:58:54 -0400    

Also move ssl_groups to a more appropriate section.  
  
Reported-by: Jacob Champion (ssl_groups item)  
  
Discussion: https://postgr.es/m/CAOYmi+k_zpGaDOrwV46_j-O-a_hSWxcXM6h8vccq45Y28deP-g@mail.gmail.com  

commit   : 0f08df406822bfa697dbcabef55728a8cb3e7fdb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 2 May 2025 17:50:58 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 2 May 2025 17:50:58 -0400    

Consistently prevent nbtree array advancement from treating a scankey as  
required when operating in pstate.forcenonrequired mode.  Otherwise, we  
risk a NULL pointer dereference.  This was possible in the path where  
_bt_check_compare is called to recheck a tuple that advanced all of the  
scan's arrays to matching values: its continuescan=false handling  
expects _bt_advance_array_keys to have been called with a valid pstate,  
but it'll always be NULL during sktrig_required=false calls (which is  
how _bt_advance_array_keys must be called when pstate.forcenonrequired).  
  
Oversight in commit 8a510275, which optimized nbtree search scan key  
comparisons.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/CAHgHdKsn2W=gPBmj7p6MjQFvxB+zZDBkwTSg0o3f5Hh8rkRrsA@mail.gmail.com  
Discussion: https://postgr.es/m/CAH2-WzmodSE+gpTd1CRGU9ez8ytyyDS+Kns2r9NzgUp1s56kpw@mail.gmail.com  

commit   : 1681a70df3d68b6f9dc82645f97f8d4668edc42f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 2 May 2025 23:04:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 2 May 2025 23:04:39 +0200    

To insert the merged GIN entries in _gin_parallel_merge, the leader  
calls ginEntryInsert(). This may allocate memory, e.g. for a new leaf  
tuple. This was allocated in the PortalContext, and kept until the end  
of the index build. For most GIN indexes the amount of leaked memory is  
negligible, but for custom opclasses with large keys it may cause OOMs.  
  
Fixed by calling ginEntryInsert() in a temporary memory context, reset  
after each insert. Other ginEntryInsert() callers do this too, except  
that the context is reset after batches of inserts. More frequent resets  
don't seem to hurt performance, it may even help it a bit.  
  
Report and fix by Vinod Sridharan.  
  
Author: Vinod Sridharan <vsridh90@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/CAFMdLD4p0VBd8JG=Nbi=BKv6rzFAiGJ_sXSFrw-2tNmNZFO5Kg@mail.gmail.com  

commit   : e83a8ae44729bfdd15d31101bd2c99be98cfc691    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 16:16:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 16:16:20 -0400    

We only need a tuplestore if we're actually going to accumulate  
multiple result tuples.  Obviously then we don't need one for non-set-  
returning functions; but even a SRF doesn't need one if we decide to  
use "lazyEval" (one row at a time) mode.  In these cases, it's  
sufficient to use the junkfilter's result slot to hold the single row  
that's due to be returned.  We just need to "materialize" that slot  
to ensure it holds onto the data past shutdown of the sub-executor.  
  
The original intent of this patch was partially to save a few cycles  
(by not putting tuples into a tuplestore only to pull them back out  
immediately), but mostly to ensure that we don't use a tuplestore  
in non-set-returning functions.  That's because I had concerns  
about whether a tuplestore is safe to keep across queries,  
which was possible for functions invoked via long-lived FmgrInfos  
such as those kept in the typcache.  There are no cases where SRFs  
are called that way, so getting rid of the tuplestore in non-SRFs  
should make things safer.  
  
However, it emerges that running fmgr_sql in a short-lived context  
(as 595d1efed made it do) makes the existing coding unsafe anyway:  
we can end up with a long-lived TupleTableSlot holding a freeable  
reference to a short-lived tuple, resulting in a double-free crash.  
Not trying to pull tuples out of the tuplestore using that slot  
dodges the problem, so I'm going to commit this now rather than  
invent a band-aid solution for v18.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2443532.1744919968@sss.pgh.pa.us  
Discussion: https://postgr.es/m/9f975803-1a1c-4f21-b987-f572e110e860@gmail.com  

commit   : c83a38758d2a9b4a72ec8f7e218f7546457f265d    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 2 May 2025 21:25:50 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 2 May 2025 21:25:50 +0200    

For self-referencing foreign keys in partitioned tables, we weren't  
handling creation of pg_constraint rows during CREATE TABLE PARTITION AS  
as well as ALTER TABLE ATTACH PARTITION.  This is an old bug -- mostly,  
we broke this in 614a406b4ff1 while trying to fix it (so 12.13, 13.9,  
14.6 and 15.0 and up all behave incorrectly).  This commit reverts part  
of that with additional fixes for full correctness, and installs more  
tests to verify the parts we broke, not just the catalog contents but  
also the user-visible behavior.  
  
Backpatch to all live branches.  In branches 13 and 14, commit  
46a8c27a7226 changed the behavior during DETACH to drop a FK  
constraint rather than trying to repair it, because the complete fix of  
repairing catalog constraints was problematic due to lack of previous  
fixes.  For this reason, the test behavior in those branches is a bit  
different.  However, as best as I can tell, the fix works correctly  
there.  
  
In release notes we have to recommend that all self-referencing foreign  
keys on partitioned tables be recreated if partitions have been created  
or attached after the FK was created, keeping in mind that violating  
rows might already be present on the referencing side.  
  
Reported-by: Guillaume Lelarge <guillaume@lelarge.info>  
Reported-by: Matthew Gabeler-Lee <fastcat@gmail.com>  
Reported-by: Luca Vallisa <luca.vallisa@gmail.com>  
Discussion: https://postgr.es/m/CAECtzeWHCA+6tTcm2Oh2+g7fURUJpLZb-=pRXgeWJ-Pi+VU=_w@mail.gmail.com  
Discussion: https://postgr.es/m/18156-a44bc7096f0683e6@postgresql.org  
Discussion: https://postgr.es/m/CAAT=myvsiF-Attja5DcWoUWh21R12R-sfXECY2-3ynt8kaOqjw@mail.gmail.com  

commit   : ac557793d478c34967a862e7104e524820e24cdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 15:12:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 15:12:49 -0400    

It's --auto-features not --auto_features.  
  
Reported-by: Egor Chindyaskin <kyzevan23@mail.ru>  
Discussion: https://postgr.es/m/172465652540.862882.17808523044292761256@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/1979661.1746212726@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 3db68212a39351804b2b4fb70a05cab76be32ce7    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 2 May 2025 10:45:12 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 2 May 2025 10:45:12 -0700    

libpq-oauth.a includes libpq-int.h, which includes OpenSSL headers. The  
Autoconf side picks up the necessary include directories via CPPFLAGS,  
but Meson needs the dependency to be made explicit.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Tested-by: Nathan Bossart <nathandbossart@gmail.com>  
Tested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aBTgjDfrdOZmaPgv%40nathan  

commit   : 81eaaa2c41dd29b06edf8b234753debbd1a581d5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 2 May 2025 16:25:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 2 May 2025 16:25:40 +0200    

The extension_control_path setting (commit 4f7f7b03758) did not  
support extensions that set a custom "directory" setting in their  
control file.  Very few extensions use that and during the discussion  
on the previous commit it was suggested to maybe remove that  
functionality.  But a fix was easier than initially thought, so this  
just adds that support.  The fix is to use the control->control_dir as  
a share dir to return the path of the extension script files.  
  
To make this work more sensibly overall, the directory suffix  
"extension" is no longer to be included in the extension_control_path  
value.  To quote the patch, it would be  
  
-extension_control_path = '/usr/local/share/postgresql/extension:/home/my_project/share/extension:$system'  
+extension_control_path = '/usr/local/share/postgresql:/home/my_project/share:$system'  
  
During the initial patch, there was some discussion on which of these  
two approaches would be better, and the committed patch was a 50/50  
decision.  But the support for the "directory" setting pushed it the  
other way, and also it seems like many people didn't like the previous  
behavior much.  
  
Author: Matheus Alcantara <mths.dev@pm.me>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Reviewed-by: David E. Wheeler <david@justatheory.com>  
Discussion: https://www.postgresql.org/message-id/flat/aAi1VACxhjMhjFnb%40msg.df7cb.de#0cdf7b7d727cc593b029650daa3c4fbc  

commit   : a724c7889f74cc4e76e1979f90808decbc744c79    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 May 2025 22:36:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 May 2025 22:36:58 -0400    

commit   : c6a26e4ccd1bf090ab755df2f597103798284d3a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 1 May 2025 16:51:59 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 1 May 2025 16:51:59 -0700    

SQL "SET search_path = 'pg_catalog, pg_temp'" is silently equivalent to  
"SET search_path = pg_temp, pg_catalog, "pg_catalog, pg_temp"" instead  
of the intended "SET search_path = pg_catalog, pg_temp".  (The intent  
was a two-element search path.  With the single quotes, it instead  
specifies one element with a comma and a space in the middle of the  
element.)  In addition to the SET statement, this affects SET clauses of  
CREATE FUNCTION, ALTER ROLE, and ALTER DATABASE.  It does not affect the  
set_config() SQL function.  
  
Though the documentation did not show an insecure command, remove single  
quotes that could entice a reader to write an insecure command.  
Back-patch to v13 (all supported versions).  
  
Reported-by: Sven Klemm <sven@timescale.com>  
Author: Sven Klemm <sven@timescale.com>  
Backpatch-through: 13  

commit   : 0064020680c1293ec6ce9fe2588e33d6aebdb015    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 May 2025 22:10:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 May 2025 22:10:36 +0200    

The variable is a bit magical in how it requires "postgresql" or  
"pgsql" to be part of the path, and files end up in its "share" and  
"lib" subdirectories.  So mention all that and show an example of  
setting "extension_control_path" and "dynamic_library_path" to use  
those locations.  
  
Author: David E. Wheeler <david@justatheory.com>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Discussion: https://www.postgresql.org/message-id/6B5BF07B-8A21-48E3-858C-1DC22F3A28B4@justatheory.com  

commit   : 4ea1254f35b27ed35a389e720ab2e614fc1e1d4d    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 1 May 2025 12:35:52 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 1 May 2025 12:35:52 -0700    

Oversight in b0635bfda. -lintl is necessary for gettext on Mac, which  
libpq-oauth depends on via pgport/pgcommon. (I'd incorrectly removed  
this change from an earlier version of the patch, where it was suggested  
by Peter Eisentraut.)  
  
Per buildfarm member indri.  

commit   : b0635bfda0535a7fc36cd11d10eecec4e2a96330    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 1 May 2025 09:14:30 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Thu, 1 May 2025 09:14:30 -0700    

The additional packaging footprint of the OAuth Curl dependency, as well  
as the existence of libcurl in the address space even if OAuth isn't  
ever used by a client, has raised some concerns. Split off this  
dependency into a separate loadable module called libpq-oauth.  
  
When configured using --with-libcurl, libpq.so searches for this new  
module via dlopen(). End users may choose not to install the libpq-oauth  
module, in which case the default flow is disabled.  
  
For static applications using libpq.a, the libpq-oauth staticlib is a  
mandatory link-time dependency for --with-libcurl builds. libpq.pc has  
been updated accordingly.  
  
The default flow relies on some libpq internals. Some of these can be  
safely duplicated (such as the SIGPIPE handlers), but others need to be  
shared between libpq and libpq-oauth for thread-safety. To avoid  
exporting these internals to all libpq clients forever, these  
dependencies are instead injected from the libpq side via an  
initialization function. This also lets libpq communicate the offsets of  
PGconn struct members to libpq-oauth, so that we can function without  
crashing if the module on the search path came from a different build of  
Postgres. (A minor-version upgrade could swap the libpq-oauth module out  
from under a long-running libpq client before it does its first load of  
the OAuth flow.)  
  
This ABI is considered "private". The module has no SONAME or version  
symlinks, and it's named libpq-oauth-<major>.so to avoid mixing and  
matching across Postgres versions. (Future improvements may promote this  
"OAuth flow plugin" to a first-class concept, at which point we would  
need a public API to replace this anyway.)  
  
Additionally, NLS support for error messages in b3f0be788a was  
incomplete, because the new error macros weren't being scanned by  
xgettext. Fix that now.  
  
Per request from Tom Lane and Bruce Momjian. Based on an initial patch  
by Daniel Gustafsson, who also contributed docs changes. The "bare"  
dlopen() concept came from Thomas Munro. Many people reviewed the design  
and implementation; thank you!  
  
Co-authored-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Wolfgang Walther <walther@technowledgy.de>  
Discussion: https://postgr.es/m/641687.1742360249%40sss.pgh.pa.us  

commit   : a3ef0b570c56f7bb15e4aa5caf0125fff92a557a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 1 May 2025 09:31:36 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 1 May 2025 09:31:36 -0500    

Oversight in commit cb45dc3afb.  
  
Reported-by: Erik Rijkers <er@xs4all.nl>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://postgr.es/m/7b856277-62ad-80f0-36e1-a134ec3c9cab%40xs4all.nl  

commit   : d73d4cfdfce897bd42ef6466e6cece5d35a91779    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 1 May 2025 11:03:43 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 1 May 2025 11:03:43 +0100    

Add a documentation warning to ts_headline() pointing out that, when  
working with untrusted input documents, the output is not guaranteed  
to be safe for direct inclusion in web pages. This is because, while  
it does remove some XML tags from the input, it doesn't remove all  
HTML markup, and so the result may be unsafe (e.g., it might permit  
XSS attacks).  
  
To guard against that, all HTML markup should be removed from the  
input, making it plain text, or the output should be passed through an  
HTML sanitizer.  
  
In addition, document precisely what the default text search parser  
recognises as valid XML tags, since that's what determines which XML  
tags ts_headline() will remove.  
  
Reported-by: Richard Neill <richard.neill@telos.digital>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 13  

commit   : 06c4f3ae804e6680ff03a09c1f89dfb1ca3d90e9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 May 2025 08:56:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 May 2025 08:56:43 +0200    

Further improvement for commit 11bd8318602.  That commit confused  
identity and generated columns; fix that.  Also, virtual generated  
columns have since been added; add more details about that.  Also some  
small rewordings and reformattings to further improve clarity.  
  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/00e6eb5f5c793b8ef722252c7a519c9a@oss.nttdata.com  

commit   : 9d924dbb37103b647c72a5252ad20770b8bae3a1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 30 Apr 2025 23:15:51 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 30 Apr 2025 23:15:51 -0400    

Make an nbtree array preprocessing assertion account for scans that add  
fewer skip arrays than initially expected due to preprocessing finding  
an unsatisfiable array qual.  
  
Oversight in commit 92fe23d9.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/CAHgHdKtQMhHy5qcB3KqCcGiW-Rp8P7KzUFRa9ZMKUiv6zen7LQ@mail.gmail.com  

commit   : 92ee8a4df5b529efbc2455d7a171054c88b43a33    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 May 2025 08:52:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 May 2025 08:52:19 +0900    

30a6ed0ce4b has added four attributes to pg_stat_all_tables to track the  
cumulative time spent in [auto]vacuum and [auto]analyze.  It was not  
mentioned that the vacuum cost-based delays are included in these  
numbers, which could be confusing now that the delays are included in  
the vacuum progress view (bb8dff9995f2).  
  
This commit adds an extra note about this matter.  
  
Reported-by: Magnus Hagander <magnus@hagander.net>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/CABUevEz9v1ZNToPyD98JnWDGZgG=SmPZKkSNzU9hXQ-nGTQF0g@mail.gmail.com  

commit   : 45e7e8ca9e9382e8f5e51fe0c085ea7f5d408ac8    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 23:00:47 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 23:00:47 +0200    

We try to avoid using strncpy() due to the ease of which it can  
be misused.  Convert this callsite to use strlcpy() instead to  
match similar codepaths in this file.  
  
Suggested-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/2a796830-de2d-4030-b480-d673f6cc5d94@eisentraut.org  

commit   : 2d6745a66b12e980fb12bd06d583a66231b5ed5c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 14:45:54 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 14:45:54 -0500    

Oversight in commit bb8dff9995.  

commit   : 987910502420b77eaf7c3e807f6b0fc1cffced29    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 14:12:59 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 14:12:59 -0500    

Presently, --missing-stats-only skips relations with reltuples set  
to 0 because empty relations don't get optimizer statistics.  
However, before v14, a reltuples value of 0 was ambiguous: it could  
either mean the relation is empty, or it could mean that it hadn't  
yet been vacuumed or analyzed.  (Commit 3d351d916b taught v14 and  
newer to use -1 for the latter case.)  This ambiguity can cause  
--missing-stats-only to inadvertently skip relations that need  
optimizer statistics after upgrades to v18 and newer (since  
reltuples is now transferred from the old cluster).  
  
To fix, simply remove the check for reltuples != 0.  This will  
cause --missing-stats-only to analyze some empty tables, but that  
doesn't seem too terrible a trade-off.  
  
Reported-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Discussion: https://postgr.es/m/aAjyvW5_fRGNr7yF%40msg.df7cb.de  

commit   : d5f1b6a75ba3f55a78959c957c3fd25d9569057c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 14:12:59 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 14:12:59 -0500    

Since pg_upgrade does not transfer the cumulative statistics used  
to trigger autovacuum and autoanalyze, the server may take much  
longer than expected to process them post-upgrade.  Currently, we  
recommend analyzing only relations for which optimizer statistics  
were not transferred by using the --analyze-in-stages and  
--missing-stats-only options.  This commit appends another  
recommendation to analyze all relations to update the relevant  
cumulative statistics by using the --analyze-only option.  This is  
similar to the recommendation for pg_stat_reset().  
  
Reported-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Discussion: https://postgr.es/m/aAfxfKC82B9NvJDj%40msg.df7cb.de  

commit   : f60420cff66a9089a9b431f9c07f4a29aae4990a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 13:07:51 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 30 Apr 2025 13:07:51 -0500    

The current ordering strategy for these pages is to list the short  
options in alphabetical order followed by the long options in  
alphabetical order.  If an option has both a short variant and a  
long variant, the short variant takes precedence.  This commit  
moves a few recently added options to match this style.  We should  
probably adjust all pages and --help output to list the long and  
short options in one combined alphabetical list (with the long  
variants taking precedence), but that is a much larger change, so  
it is left as a future exercise.  
  
Oversights in commits a5cf808be5, 1fd1bd8710, and bde2fb797a.  
  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/aBFBtsltgu3-IU1d%40nathan  

commit   : 368c3fbf9da96787d4e7cae61e11518d72f75071    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Apr 2025 11:13:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Apr 2025 11:13:49 -0400    

DST law changes in Chile: there is a new time zone America/Coyhaique  
for Chile's Aysén Region, to account for it changing to UTC-03  
year-round and thus diverging from America/Santiago.  
  
Historical corrections for Iran.  
  
Backpatch-through: 13  

commit   : f8c115a6cb6531ca86e7b0febd02698135827337    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 11:10:27 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 11:10:27 +0200    

This fixes comment and docs typos as well as a small documentation  
change to make it clearer.  Found via post-commit review.  
  
Author: Rahila Syed <rahilasyed90@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAH2L28vt16C9xTuK+K7QZvtA3kCNWXOEiT=gEekUw3Xxp9LVQw@mail.gmail.com  

commit   : d2a1ed1727a8ef45eab1a8ddb3d375c1ce839aac    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 10:34:08 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 10:34:08 +0200    

When copying the string strncpy won't add nul termination since  
the string length is equal to the length specified.  Explicitly  
set a nul terminator after copying to properly terminate. Found  
via post-commit review.  
  
Author: Rahila Syed <rahilasyed90@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAH2L28vt16C9xTuK+K7QZvtA3kCNWXOEiT=gEekUw3Xxp9LVQw@mail.gmail.com  

commit   : 991407ae86785ef38bb1ebfea679a70bcd76574d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Apr 2025 19:27:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Apr 2025 19:27:56 +1200    

commit   : 918e7287ed20eb1fe280ab6c4056ccf94dcd53a8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Apr 2025 19:18:30 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Apr 2025 19:18:30 +1200    

I forgot to run pgindent in d8555e522.  
  
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://postgr.es/m/156083c9-eac0-418d-9667-92dec4d6d6cd@oss.nttdata.com  

commit   : d8555e522eca00f1b4b6cd0b75269b7176fb7931    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Apr 2025 13:40:46 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Apr 2025 13:40:46 +1200    

Author: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/CAEG8a3+MRwDKc4YSFKKPKq7Y+vMufVC5u94wM5KZPB2CbgCxnQ@mail.gmail.com  

commit   : 810a8b1c8051d4e8822967a96f133692698386de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Apr 2025 17:27:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Apr 2025 17:27:52 -0400    

This reverts commit 38da053463bef32adf563ddee5277d16d2b6c5af, which  
attempted to preserve our ability to start with only 60 semaphores.  
  
Subsequent changes (particularly 55b454d0e) have put that idea pretty  
much permanently out of reach: people wishing to use Postgres v18 on  
OpenBSD or NetBSD will have no choice but to increase those platforms'  
default values of SEMMNI and SEMMNS.  
  
Hence, revert 38da05346's changes in SEMAS_PER_SET and the minimum  
tested value of max_connections.  Adjust a comment from the subsequent  
patch 6d0154196, and tweak the wording in runtime.sgml to make it  
clear that changing SEMMNI/SEMMNS is no longer even a little bit  
optional on these platforms.  
  
Although 38da05346 was later back-patched into v17, leave that branch  
alone: it's still capable of starting with 60 semaphores, and there's  
no reason to break that.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/E1tuZNv-0037Gs-34@gemulon.postgresql.org  
Discussion: https://postgr.es/m/1052019.1745947915@sss.pgh.pa.us  

commit   : e974f1c2164bc677d55f98edaf99f80c0b6b89d9    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 29 Apr 2025 13:08:55 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 29 Apr 2025 13:08:55 -0700    

Tell UIs to hide the value of oauth_client_secret, like the other  
passwords. Due to the previous commit, this does not affect postgres_fdw  
and dblink, but add a comment to try to warn others of the hazard in the  
future.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20250415191435.55.nmisch%40google.com  

commit   : d2e7d2a09d7d17656418f8c859074db690af19ec    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 29 Apr 2025 13:08:24 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 29 Apr 2025 13:08:24 -0700    

A subsequent commit will reclassify oauth_client_secret from dispchar=""  
to dispchar="*", so that UIs will treat it like a secret. For our FDWs,  
this change will move that option from SERVER to USER MAPPING, which we  
need to avoid.  
  
But upon further discussion, we don't really want our FDWs to use our  
builtin Device Authorization flow at all, for several reasons:  
  
- the URL and code would be printed to the server logs, not sent over  
  the client connection  
- tokens are not cached/refreshed, so every single connection has to be  
  manually authorized by a user with a browser  
- oauth_client_secret needs to belong to the foreign server, but options  
  on SERVER are publicly accessible  
- all non-superusers would need password_required=false, which is  
  dangerous  
  
Future OAuth work can use FDWs as a motivating use case. But for now,  
disallow all oauth_* connection options for these two extensions.  
  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20250415191435.55.nmisch%40google.com  

commit   : 45363fca6372a04e90d1c2628c3cbfe8894b811b    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 29 Apr 2025 13:04:19 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 29 Apr 2025 13:04:19 -0700    

Python 3.2 is no longer tested by the buildfarm, and there are only a  
handful of buildfarm animals running versions older than 3.6, which  
itself went end-of-life in 2021. Python 3.6.8 is the default version  
shipped in RHEL8, so that seems like a reasonable baseline for PG18.  
  
Now that we use the Python Limited API as of 0793ab810, older versions  
of Python should continue functioning for users of PL/Python in  
particular, so soften the language from "required" to "supported".  
  
Wording by Tom Lane. Separate from the review of the patch itself,  
several people provided input on the choice of cutoff: Christoph Berg,  
Devrim Gündüz, Florents Tselai, Jelte Fennema-Nio, and Renan Alves  
Fonseca. Thank you!  
  
Suggested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us  

commit   : eec34099c3bfe0ed4b33e77f38cab3b221cd3b37    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 19:08:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 19:08:40 +0200    

commit   : 2b49492eda3f2a30ee41038b3132338d2587f433    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 29 Apr 2025 11:41:42 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 29 Apr 2025 11:41:42 -0500    

Commit 6d01541960 taught initdb to lower the default value of  
autovacuum_worker_slots for systems with very few semaphores.  It  
also added a "fake" report for the chosen value, i.e., initdb  
prints a message about selecting the default, but the value was  
already selected in a previous test.  Per discussion, this is not a  
precedent we want to set, and it seems unnecessary to report  
everything derived from max_connections, so let's remove the "fake"  
report.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Suggested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/de722583-4ba4-4063-bc41-e20684978116%40eisentraut.org  

commit   : faced8e6a40b469bf9603db868beb6604c95df32    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Apr 2025 10:30:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Apr 2025 10:30:08 -0400    

Reported-by: Andres Freund  
  
Discussion: https://postgr.es/m/5yqochswkulckuzzrwgv2nqdrfh4k4coc4uwq4lvgzkfwnbjbd@46igbiwjabn2  

commit   : 9a9e60fed39268bb85b59dde3cdb0b0166c85cc5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Apr 2025 09:45:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Apr 2025 09:45:19 -0400    

commit   : 913c60b067aa1a618420fd0372c4df3cf5501863    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 14:40:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 14:40:49 +0200    

Add a comment character before a line annotation, so that the query  
can be used as presented.  
  
Reported-by: Yaroslav Saburov <y.saburov@gmail.com>  
Author: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://www.postgresql.org/message-id/flat/174393459040.678.17810152410419444783%40wrigleys.postgresql.org  

commit   : 2260c7f6d90ecf76d3806d32890a0890688b41e8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Apr 2025 14:34:44 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Apr 2025 14:34:44 +0300    

This commit fixes two bug in ChangeVarNodes_walker() function.  
  
 * When considering RestrictInfo, walk down to its clauses based on the  
   presense of relid to be deleted not just in clause_relids but also in  
   required_relids.  
  
 * Incrementally adjust num_base_rels based on the change of clause_relids  
   instead of recalculating it using clause_relids, which could contain  
   outer-join relids.  
  
Reported-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : 15b1b4dd3fccfd2576f44841863153c312de011b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 11:32:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 11:32:49 +0200    

The --help synopsis should only be one line.  This rephrases the first  
line a bit to reflect the new functionality of restoring multiple  
databases from pg_dumpall output.  Additional explanations are better  
kept in the man page.  

commit   : dadc58f50ac9697907e04422615d79762533496c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 10:59:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 10:59:05 +0200    

Also make the description a bit more consistent with similar options.  

commit   : 3ff2a1f0c9e8d016f3288f4da3962eb1f1592cd8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 29 Apr 2025 12:52:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 29 Apr 2025 12:52:05 +0530    

The slot synchronization skips updating the confirmed_flush LSN of the  
local slot if the local slot has a newer catalog_xmin or restart_lsn, but  
still allows updating the two_phase and two_phase_at fields of the slot.  
This opens up a window for the prepared transactions between old  
confirmed_flush LSN and two_phase_at to unexpectedly get decoded and sent  
to the downstream after promotion. Then, while decoding the commit  
prepared the assert will fail, which expects that the prepare hasn't been  
sent to the downstream.  
  
The fix is to skip updating the other slot fields when we are skipping to  
update the confirmed_flush LSN of the slot.  
  
We didn't backpatch this commit as two_phase_at was not synced in back  
branches, which means prepared transactions won't be unexpectedly sent to  
downstream.  
  
We discovered this problem while analyzing BF failure reported in the  
discussion link.  
  
Reliably reproducing this issue without a debugger is difficult. Given  
its rarity, adding specific injection point to test it doesn't seem  
worthwhile, so we won't be adding a dedicated test case.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/OS0PR01MB5716B44052000EB91EFAE60E94BC2@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : ef1811ac9a7b9c5accde1652c22fb041cb0f34b3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 09:19:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 09:19:15 +0200    

commit   : c893245ec388499426ac609812ab76a416343c7a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 09:07:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Apr 2025 09:07:53 +0200    

Before commit a0ed19e0a9e there was a cast around these, but the cast  
inadvertently changed the signedness, but that made the format  
placeholder correct.  Commit a0ed19e0a9e removed the casts, so now the  
format placeholders had the wrong signedness.  

commit   : 9807617a9293f3fce867fbde99e0840cb5695a12    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 29 Apr 2025 09:01:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 29 Apr 2025 09:01:43 +0530    

Author: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CAHut+PtnjLiNFFh-3f9cXH0wnwqjdkTjQNbVmZdZ1y+zKt_PPg@mail.gmail.com  

commit   : f132815fd717f26613dcc3888608044eac91a7ac    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 28 Apr 2025 14:19:45 -0400    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 28 Apr 2025 14:19:45 -0400    

Index vacuuming and [auto]prewarm AIO concurrency should be governed by  
maintenance_io_concurrency. As such, pass those read stream users the  
READ_STREAM_MAINTENANCE flag which will calculate their read stream  
distance with maintenance_io_concurrency instead of  
effective_io_concurrency. This was an oversight in the original commits  
making those operations use the read stream API.  
  
Discussion: https://postgr.es/m/flat/CAAKRu_aopDxTo4b41Mt_7Zc-z0_ngocrY8SFCCY6Aph1HgwuNw%40mail.gmail.com  

commit   : ce72e7e02e1c9075f8dd492f55281398d0721eb8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Apr 2025 12:49:17 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Apr 2025 12:49:17 -0400    

Checking if another primitive scan is required after all once the next  
leaf page was moved from _bt_checkkeys to its _bt_readpage caller by  
commit 9a2e2a28.  Update a comment that incorrectly described the  
recheck mechanism as something that takes place in _bt_checkkeys.  
  
Also fix an older typo in related code comments.  

commit   : b75fedcab7916e1c955dbab565b7ad0cee6b37c6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Apr 2025 12:11:08 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Apr 2025 12:11:08 -0400    

_bt_check_compare neglected to handle a case that can arise when the  
scan's keys are temporarily treated as nonrequired, as an optimization:  
whenever a NULL tuple value was encountered that had a skip array whose  
current element wasn't already NULL, _bt_check_compare failed to advance  
the array to the NULL element.  This allowed _bt_check_compare to fail  
to return matching tuples containing a NULL value (though only with an  
array column that came before a skip array column with NULLs, and only  
during _bt_readpage calls that set pstate.forcenonrequired=true on a  
page where the higher-order column also had to advance).  
  
To fix, teach _bt_check_compare to handle this case just like any other  
case where a skip array key is unsatisfied and must be advanced directly  
(due to the key being considered a nonrequired key).  
  
Oversight in commit 8a510275, which optimized nbtree search scan key  
comparisons with skip arrays.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/CAHgHdKtLFWZcjr87hMH0hYDHgcifu4Tj7iHz-xh8qsJREt5cqA@mail.gmail.com  

commit   : 0e13b13d26e870cb18fe6ecf9f8697ddfcf2c740    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 28 Apr 2025 16:25:06 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 28 Apr 2025 16:25:06 +0200    

When a child constraint is validated and the parent constraint it  
derives from isn't, pg_dump must be coerced into printing the child  
constraint; failing to do would result in a dump that restores the  
constraint as not valid, which would be incorrect.  
  
Co-authored-by: jian he <jian.universality@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: jian he <jian.universality@gmail.com>  
Message-id: https://postgr.es/m/CACJufxGHNNMc0E2JphUqJMzD3=bwRSuAEVBF5ekgkG8uY0Q3hg@mail.gmail.com  

commit   : c061000311029d2ef0129ad5eee32e698221d43d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 28 Apr 2025 14:26:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 28 Apr 2025 14:26:49 +0200    

commit   : 73e736137616b86d8bc21ec3cba098e187d883d5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 28 Apr 2025 11:20:22 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 28 Apr 2025 11:20:22 +0300    

This commit restores comments in ChangeVarNodesExtended(), which were  
accidentally removed by fc069a3a6319.  
  
Reported-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com  

commit   : aaf9e95e8764093ab55baf27c35705f406f592f9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Apr 2025 11:35:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Apr 2025 11:35:54 +0530    

During logical decoding, we advance catalog_xmin of logical too early in  
fast_forward mode, resulting in required catalog data being removed by  
vacuum. This mode is normally used to advance the slot without processing  
the changes, but we still can't let the slot's xmin to advance to an  
incorrect value.  
  
Commit f49a80c481 fixed a similar issue where the logical slot's  
catalog_xmin was getting advanced prematurely during non-fast-forward  
mode. During xl_running_xacts processing, instead of directly advancing  
the slot's xmin to the oldest running xid in the record, it allowed the  
xmin to be held back for snapshots that can be used for  
not-yet-replayed transactions, as those might consider older txns as  
running too. However, it missed the fact that the same problem can happen  
during fast_forward mode decoding, as we won't build a base snapshot in  
that mode, and the future call to get_changes from the same slot can miss  
seeing the required catalog changes leading to incorrect reslts.  
  
This commit allows building the base snapshot even in fast_forward mode to  
prevent the early advancement of xmin.  
  
Reported-by: Amit Kapila <amit.kapila16@gmail.com>  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAA4eK1LqWncUOqKijiafe+Ypt1gQAQRjctKLMY953J79xDBgAg@mail.gmail.com  
Discussion: https://postgr.es/m/OS0PR01MB57163087F86621D44D9A72BF94BB2@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : b225c5e76ed1053e505e392423b0dab065a3b813    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Apr 2025 09:08:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Apr 2025 09:08:15 +0900    

wait_event_types.h is generated by the code, and included wait_event.h.  
wait_event.h did the opposite move, including wait_event_types.h,  
causing a circular dependency between both.  
  
wait_event_types.h only needs to now about the wait event classes, so  
this information is moved into its own file, and wait_event_types.h uses  
this new header so as it does not depend anymore on wait_event.h.  
  
Note that such errors can be found with clang-tidy, with commands like  
this one:  
clang-tidy source_file.c --checks=misc-header-include-cycle -- \  
  -I/install/path/include/ -I/install/path/include/server/  
  
Issue introduced by fa88928470b5.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/350192.1745768770@sss.pgh.pa.us  

commit   : 1aa7cf9eb85972aaf2969306e84f5fc794fbef7f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 28 Apr 2025 01:40:42 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 28 Apr 2025 01:40:42 +0300    

fc069a3a6319 implements Self-Join Elimination (SJE), which can remove base  
relations when appropriate.  However, regressions tests for SJE only cover  
the case when placeholder variables (PHVs) are evaluated and needed only  
in a single base rel.  If this baserel is removed due to SJE, its clauses,  
including PHVs, will be transferred to the keeping relation.  Removing these  
PHVs may trigger an error on plan creation -- thanks to the b3ff6c742f6c for  
detecting that.  
  
This commit skips removal of PHVs during SJE.  This might also happen that  
we skip the removal of some PHVs that could be removed.  However, the overhead  
of extra PHVs is small compared to the complexity of analysis needed to remove  
them.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Alena Rybakina <a.rybakina@postgrespro.ru>  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  

commit   : 2f5b05620330baed1648a1a6e2f231c7ba1368d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Apr 2025 16:58:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Apr 2025 16:58:57 -0400    

Per our usual policy, Postgres header files should not include these;  
the decision as to which one to use is to be made in the calling .c  
file instead.  
  
These errors aren't particularly new, but I'm not feeling a need  
to back-patch these changes; it's mostly just neatnik-ism.  

commit   : 94b84a60729e15ee071739c3aec7fdd781123aab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Apr 2025 13:23:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Apr 2025 13:23:19 -0400    

This cleans up some loose ends left by commit e8ca9ed1d.  I hadn't  
looked closely enough at these places before, but now I have.  
  
The use of double-quoted #includes for Perl headers in plperl_system.h  
seems to be simply a mistake introduced in 6c944bf3c and faithfully  
copied forward since then.  (I had thought possibly it was required  
by some weird Windows build setup, but there's no evidence of that in  
our history.)  
  
The occurrences in SectionMemoryManager.h and SectionMemoryManager.cpp  
evidently stem from those files' origin as LLVM code.  It's  
understandable that LLVM would treat their own files as needing  
double-quoted #includes; but they're still system headers to us.  
  
I also applied the same check to *.c files, and found a few other  
random incorrect usages in both directions.  
  
Our ECPG headers and test files routinely use angle brackets to refer  
to ECPG headers.  I left those usages alone, since it seems reasonable  
for an ECPG user to regard those headers as system headers.  

commit   : 2311f193ea7db23f68f5471ae2c35940fc0d4794    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Apr 2025 11:43:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Apr 2025 11:43:02 -0400    

plpython.h included plpy_util.h, simply on the grounds that "it's  
easier to just include it everywhere".  However, plpy_util.h must  
include plpython.h, or it won't pass headerscheck.  While the  
resulting circularity doesn't have any immediate bad effect,  
it's poor design.  We have seen serious messes arise in the past  
from overly-broad inclusion footprints created by such circularities,  
so let's establish a project policy against it.  
  
To fix, just replace *.c files' inclusions of plpython.h with  
plpy_util.h.  They'll pull in plpython.h indirectly; indeed, almost  
all have already done so via inclusions of other plpy_xxx.h headers.  
(Any extensions using plpython.h can do likewise without breaking  
the compatibility of their code with prior Postgres versions.)  
  
Reported-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aAxQ6fcY5QQV1lo3@ip-10-97-1-34.eu-west-3.compute.internal  

commit   : e8ca9ed1d260e214f02f7f5464f125fe86e55597    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Apr 2025 20:30:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Apr 2025 20:30:27 -0400    

While few if any C compilers will complain about this, it's  
inconsistent with our other #include's of the same headers.  
  
There are some other questionable usages in  
src/include/jit/SectionMemoryManager.h and  
src/pl/plperl/plperl_system.h, but perhaps those have a  
reason to be like that.  I can't see that these do.  
  
Noticed while fooling around with a script to do analysis  
of our header cross-inclusions.  

commit   : 936457419d797dfaf37191db53d5efb1279eae6d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 27 Apr 2025 11:53:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 27 Apr 2025 11:53:40 +1200    

c4d5cb71d2 adjusted the fast-path locking code to allow some  
configuration of the number of fast-path locking slots via the  
max_locks_per_transaction GUC.  In that commit the FAST_PATH_REL_GROUP()  
macro used integer division to determine the fast-path locking group slot  
to use for the lock.  
  
The divisor in this case is always a power-of-two value.  Here we swap  
out the divide by a bitwise-AND, which is a significantly faster  
operation to perform.  
  
In passing, adjust the code that's setting FastPathLockGroupsPerBackend  
so that it's more clear that the value being set is a power-of-two.  
  
Also, adjust some comments in the area which contained some magic  
numbers.  It seems better to justify the 1024 upper limit in the  
location where the #define is made instead of where it is used.  
  
Author: David Rowley <drowleyml@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/CAApHDvodr3bcnpxcs7+k-3cFwYR0tP-BYhyd2PpDhe-bCx9i=g@mail.gmail.com  

commit   : 27757677ca4da566ff21f65c58a008818afb5b06    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Sun, 27 Apr 2025 03:03:52 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Sun, 27 Apr 2025 03:03:52 +0700    

Oversight in commit 3c6e8c123.  

commit   : 10e8176950b14ab7710a1ea65cad3179b52edbe3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 26 Apr 2025 11:41:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 26 Apr 2025 11:41:23 -0400    

commit   : 039bfc457e436dc5c6b1d6ef996048ae19ff480d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 25 Apr 2025 12:31:42 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 25 Apr 2025 12:31:42 -0400    

Trying to investigate a bug report by Alexander Lakhin made it apparent that  
the debug logging around waiting for IO completion is insufficient. Fix that.  
  
Discussion: https://postgr.es/m/h4in2db37vepagmi2oz5vvqymjasc5gyb4lpqkunj4eusu274i@37jpd3c2spd3  

commit   : 500b61769fa27e9f00a03c3f544f70da3bf3d679    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 25 Apr 2025 12:18:27 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 25 Apr 2025 12:18:27 -0400    

10f66468475 intended to limit the value of io_combine_limit to the minimum of  
io_combine_limit and io_max_combine_limit. To avoid issues with interdependent  
GUCs, it introduced io_combine_limit_guc and set io_combine_limit in assign  
hooks. That plan was thwarted by guc_tables.c accidentally still referencing  
io_combine_limit, instead of io_combine_limit_guc.  That lead to the GUC  
machinery overriding the work done in the assign hooks, potentially leaving  
io_combine_limit with a too high value.  
  
The consequence of this bug was that when running with io_combine_limit >  
io_combine_limit_guc the AIO machinery would not have reserved large enough  
iovec and IO data arrays, with one IO's arrays overlapping with another IO's,  
leading to total confusion.  
  
To make such a problem easier to detect in the future, add assertions to  
pgaio_io_set_handle_data_* checking the length is smaller than  
io_max_combine_limit (not just PG_IOV_MAX).  
  
It'd be nice to have a few tests for this, but it's not entirely obvious how  
to do so portably.  
  
As remarked upon by Tom, the GUC assignment hooks really shouldn't set the  
underlying variable, that's the job of the GUC machinery. Change that as well.  
  
Discussion: https://postgr.es/m/c5jyqnuwrpigd35qe7xdypxsisdjrdba5iw63mhcse4mzjogxo@qdjpv22z763f  

commit   : 0d9114b7040d7503096e2897f4c856b17d461f6a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 25 Apr 2025 12:03:41 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 25 Apr 2025 12:03:41 -0400    

pgaio_io_reclaim() reset the fields in PgAioHandle before updating the state  
to IDLE or incrementing the generation. For most things that's OK, but for  
pg_get_aios() it is not - if it copied the PgAioHandle while fields were being  
reset, we wouldn't detect that and could call  
pgaio_io_get_target_description() with ioh->target == PGAIO_TID_INVALID,  
leading to a crash.  
  
Fix this issue by incrementing the generation and state earlier, before  
resetting.  
  
Also add an assertion to pgaio_io_get_target_description() for the target to  
be valid - that'd have made this case a bit easier to debug. While at it,  
add/update a few related assertions.  
  
Author: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/062daca9-dfad-4750-9da8-b13388301ad9@gmail.com  

commit   : 76d52e71659149d20d616c8a94c02793cedce066    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Apr 2025 16:49:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Apr 2025 16:49:30 +0200    

Before commit a0ed19e0a9e there was a cast around these, but the cast  
inadvertently changed the signedness, but that made the format  
placeholder correct.  Commit a0ed19e0a9e removed the casts, so now the  
format placeholders had the wrong signedness.  

commit   : 385959bdeafb2e4c4b02adb55b78bde6eac616f7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Apr 2025 16:26:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Apr 2025 16:26:28 +0200    

Should be "bracket" not "brace" for [].  

commit   : 0787646e1dce966395f211fb9475dcab32daae70    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Apr 2025 12:56:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Apr 2025 12:56:40 +0200    

Adjust the way the increment operators are placed to be consistent  
throughout the function.  Fixup for commit commit c1da7281060.  

commit   : 50b8ad30f7541ff48f50a42be9d6bd59b8ce4074    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Apr 2025 12:46:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Apr 2025 12:46:02 +0530    

Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CANhcyEXsObdjkjxEnq10aJumDpa5J6aiPzgTh_w4KCWRYHLw6Q@mail.gmail.com  

commit   : 632f62dcecc78fe66f06a1ce1b0c57d16f32e191    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 25 Apr 2025 14:58:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 25 Apr 2025 14:58:14 +0900    

Previously, config.sgml included secondary index terms for  
max_replication_slots and max_active_replication_origins. These are  
no longer necessary, as each parameter now has a single distinct index entry.  
  
The secondary index terms were originally useful because  
max_active_replication_origins was part of max_replication_slots,  
and separate index entries helped users locate each setting. However,  
commit 04ff636cbce split them into independent parameters,  
making the secondary terms redundant.  
  
This commit removes the unnecessary secondary index entries to  
simplify the documentation.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/e825e7a7-4877-441d-93c1-25377db36c31@oss.nttdata.com  

commit   : 6389db23209a3a9b99759b26fbd26a9da5693116    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 24 Apr 2025 22:02:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 24 Apr 2025 22:02:35 -0400    

commit   : 3631612eae9c2def99151c4f36b1b3771f53cba7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 24 Apr 2025 12:22:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 24 Apr 2025 12:22:53 +0900    

A correct cocktail of COPY FROM, SELECT and/or DML queries and  
\syncpipeline was able to break the logic in charge of discarding  
results of a pipeline, done in discardAbortedPipelineResults().  Such  
sequence make the backend generate a FATAL, due to a protocol  
synchronization loss.  
  
This problem comes down to the fact that we did not consider the case of  
libpq returning a PGRES_FATAL_ERROR when discarding the results of an  
aborted pipeline.  The discarding code is changed so as this result  
status is handled as a special case, with the caller of  
discardAbortedPipelineResults() being responsible for consuming the  
result.  
  
A couple of tests are added to cover the problems reported, bringing an  
interesting gain in coverage as there were no tests in the tree covering  
the case of protocol synchronization loss.  
  
Issue introduced by 41625ab8ea3d.  
  
Reported-by: Alexander Kozhemyakin <a.kozhemyakin@postgrespro.ru>  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/ebf6ce77-b180-4d6b-8eab-71f641499ddf@postgrespro.ru  

commit   : 923ae50cf55986efb5f3feb0f15253a69a5e224c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 24 Apr 2025 09:20:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 24 Apr 2025 09:20:01 +0900    

Not having this check would produce a core dump at startup when running  
pgstat_read_statsfile(), in the case where the information of a stats  
kind for an entry in the dshash could not be found.  The same check  
already happens for fixed-numbered stats and entries that are stored  
with their names.  This issue can be seen with custom stats kinds.  
  
Note that this problem can be reproduced what what is in the core code:  
- Tweak the test module injection_points to not load the fixed-numbered  
stats part, leaving only the variable-numbered stats.  
- Create an instance with injection_points defined in  
shared_preload_libraries.  
- Create a pgstats entry by attaching and running a point.  
- Restart the server without shared_preload_libraries.  The startup  
process detects that something is wrong and reports a WARNING.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aAieZAvM+K1d89R2@ip-10-97-1-34.eu-west-3.compute.internal  

commit   : bc19f63f80109737e2610c81f65d33fc93246b2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Apr 2025 16:04:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Apr 2025 16:04:42 -0400    

One place in hash_create() used DynaHashAlloc() as a convenient  
shorthand for MemoryContextAlloc().  That was fine when it was  
written, but it stopped being fine when 9c911ec06 changed  
DynaHashAlloc() to use MCXT_ALLOC_NO_OOM (mea culpa).  Change  
the code to call plain MemoryContextAlloc() as intended.  
  
I think that this bug may be unreachable in practice, since we now  
always create AllocSets with some space already allocated, so that  
an OOM failure here for a non-shared hash table should be impossible  
(with a hash table name of reasonable length anyway).  And there  
aren't enough shared hash tables to make a crash for one of those  
probable.  Nonetheless it's clearly not operating as designed, so  
back-patch to v16 where 9c911ec06 came in.  
  
Reported-by: Maksim Korotkov <m.korotkov@postgrespro.ru>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/219bdccd460510efaccf90b57e5e5ef2@postgrespro.ru  
Backpatch-through: 16  

commit   : 005ccae0f2d68ad3d44141a748635f3dd4a46c1f    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 23 Apr 2025 11:16:45 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 23 Apr 2025 11:16:45 -0700    

RHEL8 ships a patched 3.6.8 as its base Python version, and I  
accidentally let some newer Python-isms creep into oauth_server.py  
during development.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Tested-by: Renan Alves Fonseca <renanfonseca@gmail.com>  
Tested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us  

commit   : bb78e4267817b5c1f5a8ff5b0b93fe756e514bb0    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 23 Apr 2025 20:14:32 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 23 Apr 2025 20:14:32 +0300    

b85a9d046efd introduced a new RelIdToTypeIdCacheHash, whose entries should  
exist for typecache entries with TCFLAGS_HAVE_PG_TYPE_DATA flag set or any  
of TCFLAGS_OPERATOR_FLAGS set or tupDesc set.  However, TypeCacheOpcCallback(),  
which resets TCFLAGS_OPERATOR_FLAGS, was forgotten to update  
RelIdToTypeIdCacheHash.  
  
This commit adds a delete_rel_type_cache_if_needed() call to the  
TypeCacheOpcCallback() function to maintain RelIdToTypeIdCacheHash after  
resetting TCFLAGS_OPERATOR_FLAGS.  
  
Also, this commit fixes the name of the delete_rel_type_cache_if_needed()  
function in its mentions in the comments.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20250411203241.e9.nmisch%40google.com  

commit   : 9f404d7922e8831dc49bfa225530ba5309900e4e    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 23 Apr 2025 20:13:51 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 23 Apr 2025 20:13:51 +0300    

To estimate with extended statistics, we need to clear the varnullingrels  
field in the expression, and duplicates are not allowed in the GroupVarInfo  
list.  We might re-use add_unique_group_var(), but we don't do so for two  
reasons.  
  
  1) We must keep the origin_rinfos list ordered exactly the same way as  
     varinfos.  
  2) add_unique_group_var() is designed for estimate_num_groups(), where a  
     larger number of groups is worse.   While estimating the number of hash  
     buckets, we have the opposite: a lesser number of groups is worse.  
     Therefore, we don't have to remove "known equal" vars: the removed var  
     may valuably contribute to the multivariate statistics to grow the number  
     of groups.  
  
This commit adds custom code to estimate_multivariate_bucketsize() to  
initialize varinfos properly.  
  
Reported-by: Robins Tharakan <tharakan@gmail.com>  
Discussion: https://postgr.es/m/18885-da51324078588253%40postgresql.org  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : 3db61db48ef5b8898f7e85f98548fdec79d76524    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Apr 2025 12:03:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Apr 2025 12:03:02 -0400    

When a foreign key constraint is placed on a partitioned table, we  
actually make two pg_constraint entries associated with that table.  
(I have my doubts about the wisdom of that, but it's been like that  
since v12 and post-feature-freeze is no time to be messing with such  
entrenched decisions.)  The second "child" entry always had a name  
generated according to the default rule, "table_column(s)_fkey[nnn]",  
even if the primary entry had an unrelated user-specified name.  The  
trouble with doing that is that the default name could collide with  
the user-specified name of some other constraint on the same table.  
While we were willing to adjust the generated name to avoid  
collisions, that only helps if it's made second; if it's made first  
then creation of the other constraint would fail, potentially causing  
dump/reload or pg_upgrade failures.  
  
The core of the problem here is that we're infringing on user  
namespace, so I doubt that there's any 100% solution other than to  
find a way to not need the "child" entry.  In the meantime, it seems  
like it'd be an improvement to make the child's name be the name of  
the parent constraint with an underscore and digit(s) appended as  
necessary to make it unique.  This rule can in theory fail in the same  
way, but it seems much less probable; for one thing, this rule is  
guaranteed not to match primary entries having auto-generated names.  
(While an auto-generated primary name isn't user-specified to begin  
with, it acts like that during dump/reload, so collisions against such  
names are definitely possible.)  
  
An additional bonus, visible in some of the regression test cases  
that change here, arises from the fact that some error messages  
cite the child constraint's name not the parent's.  In the  
previous approach the two names could be completely unrelated,  
leading to user confusion --- the more so since psql's \d command  
hides child constraints.  With this approach it's hopefully much  
clearer which constraint-the-user-knows-about is failing.  
  
However, that does mean that there's user-visible behavior change  
occurring here, making it seem like not something to back-patch.  
I feel it's not too late for v18, though.  
  
Reported-by: Kirill Reshke <reshkekirill@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Alvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CALdSSPhGitjpTfzEMJN-Y2x+Q-5QChSxAsmSJ1-E8mQJLkHOqQ@mail.gmail.com  

commit   : 994a100b37ad8c2fb8282a9fce91a16b4c832277    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 23 Apr 2025 11:02:05 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 23 Apr 2025 11:02:05 +0200    

The stack allocated JsonLexContexts, in combination with codepaths  
using goto, were causing warnings when compiling with LTO enabled  
as the optimizer is unable to figure out that is safe.  Rather than  
contort the code with workarounds for this simply heap allocate the  
structs instead as these are not in any performance critical paths.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2074634.1744839761@sss.pgh.pa.us  

commit   : 0ff95e0a5be1372bfba9db284ea17c8e0e5da3a0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Apr 2025 15:33:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Apr 2025 15:33:07 +0900    

The routine was coded so as a WAL sender was always used, state required  
only for one failure test related to START_REPLICATION.  This test is  
changed so as a WAL sender is used by passing a replication option to  
psql_fails_like(), instead of forcing the use of a WAL sender for all  
the tests.  
  
This has come up as useful in the context of a separate bug fix where  
we are looking at extending tests for some failure scenarios.  These  
tests need to happen in the context of a normal backend, and not a WAL  
sender where the extended query protocol cannot be used.  
  
Discussion: https://postgr.es/m/aAXkJIOildLUA7vQ@paquier.xyz  

commit   : 0e091ce409e06cd89baf81306cc92c496d8ba58d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Apr 2025 11:08:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Apr 2025 11:08:24 +0530    

Commit 3f28b2fcac tried to ensure that the replication origin shouldn't be  
advanced in case of an ERROR in the apply worker, so that it can request  
the same data again after restart. However, it is possible that an ERROR  
was caught and handled by a (say PL/pgSQL) function, and  the apply worker  
continues to apply further changes, in which case, we shouldn't reset the  
replication origin.  
  
Ensure to reset the origin only when the apply worker exits after an  
ERROR.  
  
Commit 3f28b2fcac added new function geterrlevel, which we removed in HEAD  
as part of this commit, but kept it in backbranches to avoid breaking any  
applications. A separate case can be made to have such a function even for  
HEAD.  
  
Reported-by: Shawn McCoy <shawn.the.mccoy@gmail.com>  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where it was introduced  
Discussion: https://postgr.es/m/CALsgZNCGARa2mcYNVTSj9uoPcJo-tPuWUGECReKpNgTpo31_Pw@mail.gmail.com  

commit   : 1f7878c33cab8b741ecb0d145809cdd3000677be    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Apr 2025 13:53:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Apr 2025 13:53:29 +0900    

This assertion, based on pending_since (timestamp used to prevent stats  
reports to be too frequent or should a partial flush happen), is reached  
when it is found that no data can be flushed but a previous call of  
pgstat_report_stat() determined that some stats data has been found as  
in need of a flush.  So pending_since is set when some stats data is  
pending (in non-force mode) or if report attempts are too frequent, and  
reset to 0 once all stats have been flushed.  
  
Since 5cbbe70a9cc6, WAL senders have begun to report their stats on a  
periodic basis for IO stats in v16~ and backend stats on HEAD, creating  
some friction with the concurrent pgstat_report_stat() calls that can  
happen in the context of a WAL sender (shutdown callback doing a final  
report or backend-related code paths).  This problem is the cause of  
spurious failures in the TAP tests.  
  
In theory, this assertion can be also reached in v15, even if that's  
very unlikely.  For example, a process, say a background worker, could  
do periodic and direct stats flushes with concurrent calls of  
pgstat_report_stat() that could cause conflicting values of  
pending_since.  This can be done with WAL or SLRU stats flushes using  
pgstat_flush_wal() or pgstat_slru_flush().  HEAD makes this situation  
easier to happen with custom cumulative stats.  
  
This commit removes the assertion altogether, per discussion, as it is  
more useful to keep the state of things as they are for the WAL sender.  
The assertion could use a special state based on for example  
am_walsender, but I doubt that this would be meaningful in the long run  
based on the other arguments raised while discussing this issue.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/1489124.1744685908@sss.pgh.pa.us  
Discussion: https://postgr.es/m/dwrkeszz6czvtkxzr5mqlciy652zau5qqnm3cp5f3p2po74ppk@omg4g3cc6dgq  
Backpatch-through: 15  

commit   : e0f373ee42a40a41bdfc025a1641d351580991c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Apr 2025 15:10:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Apr 2025 15:10:50 -0400    

Cluster.pm's connect_fails routine has long had the ability to  
sniff the postmaster log file for expected messages after a  
connection failure.  However, that's always had a race condition:  
on some platforms it's possible for psql to exit and the test  
script to slurp up the postmaster log before the backend process  
has been able to write out its final log messages.  Back in  
commit 55828a6b6 we disabled a bunch of tests after discovering  
that, and the aim of this patch is to re-enable them.  
  
(The sibling function connect_ok doesn't seem to have a similar  
problem, mainly because the messages we look for come out during  
the authentication handshake, so that if psql reports successful  
connection they should certainly have been emitted already.)  
  
The solution used here is borrowed from 002_connection_limits.pl's  
connect_fails_wait routine: set the server's log_min_messages setting  
to DEBUG2 so that the postmaster will log child-process exit, and then  
wait till we see that log entry before checking for the messages we  
are actually interested in.  
  
If a TAP test uses connect_fails' log_like or log_unlike options, and  
forgets to set log_min_messages, those connect_fails calls will now  
hang until timeout.  Fixing up the existing callers shows that we had  
several other TAP tests that were in theory vulnerable to the same  
problem.  It's unclear whether the lack of failures is just luck, or  
lack of buildfarm coverage, or perhaps there is some obscure timing  
effect that only manifests in SSL connections.  In any case, this  
change should in principle make those other call sites more robust.  
I'm not inclined to back-patch though, unless sometime we observe  
an actual failure in one of them.  
  
Reported-by: Andrew Dunstan <andrew@dunslane.net>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/984fca80-85a8-4c6f-a5cc-bb860950b435@dunslane.net  

commit   : da83b1ea10c2b7937d4c9e922465321749c6785b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Apr 2025 14:24:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Apr 2025 14:24:21 -0400    

While heapam reproduces the insertion order of rows well, updates  
can move rows to varying places depending on autovacuum activity.  
In most regression tests we've guarded against getting variable  
results due to that, but float4.sql and float8.sql had escaped  
notice so far because they update tables that are too small for  
autovacuum to pay attention to.  
  
With increasing interest in non-heap table AMs, it seems worth  
allowing for update behaviors that are not like heapam's.  Hence,  
add ORDER BY to stabilize the results in case the updates put  
the rows in a different order.  (We'll continue to assume that a  
seqscan will reproduce original insertion order, though.  Removing  
that assumption would require vastly-more-invasive test changes.)  
  
Author: Pavel Borisov <pashkin.elfe@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CALT9ZEExHAnBoBVQzQuWPMKUbapF5-FBO3fdeYG3s2tuWQz1NQ@mail.gmail.com  

commit   : eaf582806c0d6b19c081c5afecd9ddb7003e6f80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Apr 2025 13:56:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Apr 2025 13:56:31 -0400    

This error message was 'runaway "struct_name"', which isn't all  
that clear; I think 'could not find closing brace for "struct_name"'  
is better.  Also, provide the location of the struct start using the  
script's usual '$file:$lineno' style.  
  
Bug: #18901  
Reported-by: Clemens Ruck <clemens.ruck@t-online.de>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18901-424272abe01357e6@postgresql.org  

commit   : e29df428a1dca4112aad640c889a9a54642759c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 12:41:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 12:41:29 +0900    

All the injection points used in the tree have relied on an implied  
rule: their names should be made of lower-case characters, with dashes  
between the words used.  
  
This commit adds a light mention about that in the docs, encouraging the  
practice.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Aleksander Alekseev <aleksander@timescale.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966E14C1378DEE51FB7B7C5F5B32@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 17  

commit   : 0b06459f3c0a515c922f2a22974acea9db38c024    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 14:54:22 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 14:54:22 +1200    

The previous text was a little clumsy.  Here we improve that.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reported-by: Noboru Saito <noborusai@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CAAM3qnJtv5YbjpwDfVOYN2gZ9zGSLFM1UGJgptSXmwfifOZJFQ@mail.gmail.com  
Backpatch-through: 13  

commit   : 02c63f9438e082ac58284eed52a9a46015a83432    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 10:01:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 10:01:38 +0900    

This injection point was named "AtEOXact_Inval-with-transInvalInfo", not  
respecting the implied naming convention that injection points should  
use lower-case characters, with terms separated by dashes.  All the  
other points defined in the tree follow this style, so let's be more  
consistent.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Aleksander Alekseev <aleksander@timescale.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966E14C1378DEE51FB7B7C5F5B32@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 17  

commit   : 5e6f9a9c4e7edbe110eab25f9fc05a6d136b950a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 11:10:08 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 11:10:08 +1200    

* Use <symbol> tags for CONNECTION_* #defines  
  
We were using an inconsistent mix of <literal> and sometimes <function>  
tags.  
  
* Use <application> tag for libpq  
  
There was a mix of <literal> and <productname>  
  
Also fix a whitespace issue.  
  
None of these seem critical enough mistakes to backpatch.  
  
Author: Noboru Saito <noborusai@gmail.com>  
Discussion: https://postgr.es/m/CAAM3qnJtv5YbjpwDfVOYN2gZ9zGSLFM1UGJgptSXmwfifOZJFQ@mail.gmail.com  

commit   : d010cc6ccacf88926255d3ae2d67dad3e332ae8a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 11:04:04 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 11:04:04 +1200    

Author: Noboru Saito <noborusai@gmail.com>  
Discussion: https://postgr.es/m/CAAM3qnJtv5YbjpwDfVOYN2gZ9zGSLFM1UGJgptSXmwfifOZJFQ@mail.gmail.com  
Backpatch-through: 17  

commit   : 90260e2ec6bbfc3dfa9d9501ab75c535de52f677    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 21 Apr 2025 12:34:58 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 21 Apr 2025 12:34:58 -0700    

Word boundaries are based on whether a character is alphanumeric or  
not. For the PG_UNICODE_FAST collation, alphanumeric includes  
non-ASCII digits; whereas for the PG_C_UTF8 collation, it only  
includes digits 0-9. Pass down the right information from the  
pg_locale_t into initcap_wbnext to differentiate the behavior.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20250417135841.33.nmisch@google.com  

commit   : 80b727eb9deab589a8648750bc20f1623d5acd3e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Apr 2025 12:09:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Apr 2025 12:09:36 -0400    

exec_replication_command created a cmd_context to work in and  
then deleted it on exit.  This is pretty dangerous because  
some replication commands start/finish transactions.  In the  
wake of commit 1afe31f03, that could lead to re-selecting a  
CurrentMemoryContext that's already been deleted, leading to  
hilarity such as a memory context that is its own parent.  
  
To fix, let's make the cmd_context persist across  
exec_replication_command calls; instead of deleting it, we'll just  
reset it each time.  In this way it retains the same identity and  
there's no problem if transaction abort restores it as the working  
context.  It probably even saves a few microseconds to do this.  
  
This fix also ensures that exec_replication_command returns to the  
caller (PostgresMain) with the same context active that had been  
when it was called (probably MessageContext).  The previous  
coding could get that wrong too.  
  
Reported-by: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAO6_XqoJA7-_G6t7Uqe5nWF3nj+QBGn4F6Ptp=rUGDr0zo+KvA@mail.gmail.com  

commit   : 5ec8b01c30e7ea34bb42592ad9d34d4b02ea593d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Apr 2025 11:34:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Apr 2025 11:34:36 -0400    

The case of "node == parent" might seem impossible, since we just  
allocated the new node.  But it's possible if parent is a dangling  
reference to a recently-deleted context.  In fact, given aset.c's  
habit of recycling contexts, it's actually rather likely if that's so.  
If we'd had this assertion before, it would have simplified debugging  
a recently-identified walsender issue.  
  
Reported-by: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAO6_XqoJA7-_G6t7Uqe5nWF3nj+QBGn4F6Ptp=rUGDr0zo+KvA@mail.gmail.com  

commit   : 706cbed351037fb5e886815506515d1281e62d40    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 21 Apr 2025 14:53:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 21 Apr 2025 14:53:25 +0900    

Commit d9e03864b6b changed the memory context level numbers shown by  
pg_log_backend_memory_contexts() to be 1-based. However, the example in  
the documentation was not updated and still used 0-based numbering.  
  
This commit updates the example to match the current 1-based output.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: David Rowley <drowleyml@gmail.com>  
Discussion: https://postgr.es/m/1ad6d388-1b43-400d-bec9-36d52f755f74@oss.nttdata.com  

commit   : 78eda9e2648ab3f8c0df0d4aca53eb0ad6399c59    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Apr 2025 13:50:50 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Apr 2025 13:50:50 +1200    

Similar to 84fd3bc14 but these ones were found using a regex that can span  
multiple lines.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAApHDvrMcr8XD107H3NV=WHgyBcu=sx5+7=WArr-n_cWUqdFXQ@mail.gmail.com  

commit   : 84fd3bc141039b32f25c3c9f6157163a56ab5f66    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Apr 2025 10:41:18 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Apr 2025 10:41:18 +1200    

These are all new to v18  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAApHDvrMcr8XD107H3NV=WHgyBcu=sx5+7=WArr-n_cWUqdFXQ@mail.gmail.com  

commit   : 818013665259d4242ba641aad705ebe5a3e2db8e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Apr 2025 12:00:17 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Apr 2025 12:00:17 -0700    

Blocking checkpoint phase 2 requires MarkBufferDirty() and  
BUFFER_LOCK_EXCLUSIVE; neither suffices by itself.  transam/README documents  
this, citing SyncOneBuffer().  Update the DELAY_CHKPT_START documentation to  
say this.  Expand the heap_inplace_update_and_unlock() comment that cites  
XLogSaveBufferForHint() as precedent, since heap_inplace_update_and_unlock()  
could have opted not to use DELAY_CHKPT_START.  
  
Commit 8e7e672cdaa6bfec85d4d5dd9be84159df23bb41 added DELAY_CHKPT_START to  
heap_inplace_update_and_unlock().  Since commit  
bc6bad88572501aecaa2ac5d4bc900ac0fd457d5 reverted it in non-master branches,  
no back-patch.  
  
Discussion: https://postgr.es/m/20250406180054.26.nmisch@google.com  

commit   : 714bd9e3a733a98da47531a750182ee5981cc3ed    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Apr 2025 08:28:48 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Apr 2025 08:28:48 -0700    

v14 commit 1f95181b44c843729caaa688f74babe9403b5850 and its v13  
equivalent caused timing-dependent failures in archive recovery, at  
restartpoints.  The symptom was "invalid magic number 0000 in log  
segment X, offset 0", "unexpected pageaddr X in log segment Y, offset 0"  
[X < Y], or an assertion failure.  Commit  
3635a0a35aafd3bfa80b7a809bc6e91ccd36606a and predecessors back-patched  
v15 changes to fix that.  This test reproduces the problem  
probabilistically, typically in less than 1000 iterations of the test.  
Hence, buildfarm and CI runs would have surfaced enough failures to get  
attention within a day.  
  
Reported-by: Arun Thirupathi <arunth@google.com>  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 2d5350cfbdc6e61124214d68713295bb060bc541    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Apr 2025 08:28:48 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Apr 2025 08:28:48 -0700    

Commit 7102070329d8147246d2791321f9915c3b5abf31 fixed a similar bug, but  
it missed the case of database-wide ANALYZE ("use_own_xacts" mode).  
Commit a07e03fd8fa7daf4d1356f7cb501ffe784ea6257 changed consequences  
from silent discard of a pg_class stats (relpages et al.) update to  
ERROR "tuple to be updated was already modified".  Losing a relpages  
update of an ON COMMIT DELETE ROWS table was negligible, but a  
COMMIT-time error isn't negligible.  Back-patch to v13 (all supported  
versions).  
  
Reported-by: Richard Guo <guofenglinux@gmail.com  
Reported-by: Robins Tharakan <tharakan@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs4-XwMKMKJ_GT=p3_-_=j9rQSEs1FbDFUnW9zHuKPsPNEQ@mail.gmail.com  
Backpatch-through: 13  

commit   : d47f922246b54f0290811951e0b73a3d6110437c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 20 Apr 2025 22:12:07 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 20 Apr 2025 22:12:07 +1200    

1349d2790 added support so that aggregate functions with an ORDER BY or  
DISTINCT clause could make use of presorted inputs to avoid an implicit  
sort within nodeAgg.c.  That commit failed to consider that a FILTER  
clause may exist that filters rows before the aggregate function  
arguments are evaluated.  That can be problematic if an aggregate  
argument contains an expression which could error out during evaluation.  
It's perfectly valid to want to have a FILTER clause which eliminates  
such values, and with the pre-sorted path added in 1349d2790, it was  
possible that the planner would produce a plan with a Sort node above  
the Aggregate to perform the sort on the aggregate's arguments long before  
the Aggregate node would filter out the non-matching values.  
  
Here we fix this by inspecting ORDER BY / DISTINCT aggregate functions  
which have a FILTER clause to see if the aggregate's arguments are  
anything more complex than a Var or a Const.  Evaluating these isn't  
going to cause an error.  If we find any non-Var, non-Const parameters  
then the planner will now opt to perform the sort in the Aggregate node  
for these aggregates, i.e. disable the presorted aggregate optimization.  
  
An alternative fix would have been to completely disallow the presorted  
optimization for Aggrefs with any FILTER clause, but that wasn't done as  
that could cause large performance regressions for queries that see  
significant gains from 1349d2790 due to presorted results coming in from  
an Index Scan.  
  
Backpatch to 16, where 1349d2790 was introduced  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Reported-by: Kaimeh <kkaimeh@gmail.com>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAK-%2BJz9J%3DQ06-M7cDJoPNeYbz5EZDqkjQbJnmRyQyzkbRGsYkA%40mail.gmail.com  
Backpatch-through: 16