PostgreSQL 17.5 commit log

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

commit   : ecbe349e9128b678311a2b8e328cbe258d7807ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2025 11:29:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2025 11:29:49 -0400    

Security: CVE-2025-4207  

commit   : ec5f89e8a29f32c7dbc4dd8734ed8406d771de2f    
  
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   : 617d34908b5dd1a7a643e82af871fa5b69a37491    
  
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   : 954aacaee3f94b52b2afcaa313b5ff90f2fcd2e7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 May 2025 12:14:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 May 2025 12:14:36 +0200    

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

commit   : 09fac4a28daa49af91d2af28348267efe916c95b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 May 2025 13:52:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 May 2025 13:52:59 -0400    

commit   : ee2486989e7a9d84a530268276e3330b4ea3cc73    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 3 May 2025 19:10:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sat, 3 May 2025 19:10:01 +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   : f51ae3187472536f0ab6e7dc421399062547eb9d    
  
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   : 766d2e6733421d91694c878cef64519d47ec8d90    
  
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   : c9c62c44cd5cafe677476e5fc4723d54ec4ab56d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 12:35:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 12:35:36 -0400    

commit   : 176877f461a8b55e921f597fb217f6ab89ee019f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 12:27:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2025 12:27:01 -0400    

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

commit   : 40d1a1016d75daee39219fcda9eec2e38d1028e8    
  
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   : 18dc43a07fecc22934742fd752dcdd3a10f9d6cd    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 1 May 2025 11:06:21 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 1 May 2025 11:06:21 +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   : 5d5970b9f00a09ef9433f60f5b6e0e9fba1f1f98    
  
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   : 36148b22ee09f504e049e7da2495d32ca1c265bd    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Apr 2025 11:22:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Apr 2025 11:22:07 +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   : d96206f259d6799de066c6fa88a4b51c494f7167    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Apr 2025 12:32:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Apr 2025 12:32:00 +0530    

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

commit   : e384118559ef693eaa47ba265627e2e6d8bca843    
  
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   : 05676d87e2e69a889abf75ce4f0c1bedde9ed71f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Apr 2025 10:52:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Apr 2025 10:52:36 +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   : 4b6331e0fd5779f31df640d6f5b08a03d8dfb829    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Apr 2025 13:54:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Apr 2025 13:54:53 +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   : 185d345d79095d705f02b3e1eb9fd0a06a144573    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 12:41:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 12:41:58 +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   : f04b11454d5dc35093d42f0e3148203ebb31e0ce    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 14:56:39 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 14:56:39 +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   : 21a9b2b086fab75091c8a848de9fd9aba48a11b8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 10:01:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Apr 2025 10:01:42 +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   : 12bf43410aba58a577a8519e031a0e24631eaf33    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 11:04:44 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 11:04:44 +1200    

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

commit   : e297ddcfb7d37f54567b9a9bb87ef15e0aedc0d5    
  
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   : d0a049987e5a0aab8bc79af889ff12349a325c97    
  
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   : 065ce49a10e0722df809935504bc7814e94a04dc    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 20 Apr 2025 22:12:37 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 20 Apr 2025 22:12:37 +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  

commit   : ecb8e56412b270eab66f3d34329c608fc3356e30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Apr 2025 16:37:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Apr 2025 16:37:42 -0400    

The original intent in heap_page_items() was to return nulls, not  
throw an error or crash, if an item was sufficiently corrupt that  
we couldn't safely extract data from it.  However, commit d6061f83a  
utterly missed that memo, and not only put in an un-length-checked  
copy of the tuple's data section, but also managed to break the check  
on sane nulls-bitmap length.  Either mistake could possibly lead to  
a SIGSEGV crash if the tuple is corrupt.  
  
Bug: #18896  
Reported-by: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>  
Author: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18896-add267b8e06663e3@postgresql.org  
Backpatch-through: 13  

commit   : 4a0650d359c5981270039eeb634c3b7427aa0af5    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 18 Apr 2025 09:35:35 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 18 Apr 2025 09:35:35 +0900    

Backpatch to 17, where the line was added.  
  
Reported by Noboru Saito while he was working on translating the file  
into Japanese.  
  
Discussion: https://postgr.es/m/20250417.203047.1321297410457834775.ishii%40postgresql.org  
Reported-by: Noboru Saito <noborusai@gmail.com>  
Reviewed-by: Daniel Gustafs <daniel@yesql.se>  
Backpatch-through: 17  

commit   : 3424c1075e4aafdf42e9ff829ed2a6e12c554ff2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Apr 2025 13:31:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Apr 2025 13:31:44 -0400    

We'd try to drop the partitions of a partitioned index separately,  
which is disallowed by the backend, leading to an error during  
restore.  While the error is harmless, it causes problems if you  
try to use --single-transaction mode.  
  
Fortunately, there seems no need to do a DROP at all, since the  
partition will go away silently when we drop either the parent index  
or the partition's table.  So just make the DROP conditional on not  
being a partition.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Author: jian he <jian.universality@gmail.com>  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACJufxF0QSdkjFKF4di-JGWN6CSdQYEAhGPmQJJCdkSZtd=oLg@mail.gmail.com  
Backpatch-through: 13  

commit   : 3c39c000c85957940d4c4b30639447246b2595c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Apr 2025 12:08:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Apr 2025 12:08:34 -0400    

If a GENERATED column is declared to have a domain data type where  
the domain's constraints disallow null values, INSERT commands failed  
because we built a targetlist that included coercing a null constant  
to the domain's type.  The failure occurred even when the generated  
value would have been perfectly OK.  This is adjacent to the issues  
fixed in 0da39aa76, but we didn't notice for lack of testing a domain  
with such a constraint.  
  
We aren't going to use the result of the targetlist entry for the  
generated column --- ExecComputeStoredGenerated will overwrite it.  
So it's not really necessary that it have the exact datatype of  
the generated column.  This patch fixes the problem by changing  
the targetlist entry to be a null Const of the domain's base type,  
which should be sufficiently legal.  (We do have to tweak  
ExecCheckPlanOutput to accept the situation, though.)  
  
This has been broken since we implemented generated columns.  
However, this patch only applies easily as far back as v14, partly  
because I (tgl) only carried 0da39aa76 back that far, but mostly  
because v14 significantly refactored the handling of INSERT/UPDATE  
targetlists.  Given the lack of field complaints and the short  
remaining support lifetime of v13, I judge the cost-benefit ratio  
not good for devising a version that would work in v13.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Author: jian he <jian.universality@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACJufxG59tip2+9h=rEv-ykOFjt0cbsPVchhi0RTij8bABBA0Q@mail.gmail.com  
Backpatch-through: 14  

commit   : 1b1dc81649a2d359f74553ebe2ecdd1d2d6e9bfe    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 15 Apr 2025 23:15:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 15 Apr 2025 23:15:06 +0900    

Previously, a space was missing between "<option>--exclude-schema</option>"  
and "for" in the pg_restore documentation. This commit fixes the typo by  
adding the missing whitespace.  
  
Back-patch to v17 where the typo was added.  
  
Author: Lele Gaifax <lele@metapensiero.it>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/87lds3ysm0.fsf@metapensiero.it  
Backpatch-through: 17  

commit   : fb9ec9cf79263329ca8f116d6dacaada78f49dc2    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 15 Apr 2025 15:27:08 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 15 Apr 2025 15:27:08 +0200    

The code comment for parse_oid accidentally used the wrong parameter  
when referring to the location of the last backup. Also, while there,  
improve sentence wording by removing a superfluous word.  
  
Backpatch to v17 where pg_combinebackup was addedd  
  
Author: Amul Sul <sulamul@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CAAJ_b95ecWgzcS4K3Dx0E_Yp-SLwK5JBasFgioKMSjhQLw9xvg@mail.gmail.com  
Backpatch-through: 17  

commit   : 8c153fcfa0d6281f4d2754dfdc74055aee86814e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Apr 2025 12:27:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Apr 2025 12:27:46 -0400    

Commit 0f21db36d made an assumption that GIN triConsistentFns  
would not modify their input entryRes[] arrays.  But in fact,  
the "shim" triConsistentFn that we use for opclasses that don't  
supply their own did exactly that, potentially leading to wrong  
answers from a GIN index search.  Through bad luck, none of the  
test cases that we have for such opclasses exposed the bug.  
  
One response to this could be that the assumption of consistency check  
functions not modifying entryRes[] arrays is a bad one, but it still  
seems reasonable to me.  Notably, shimTriConsistentFn is itself  
assuming that with respect to the underlying boolean consistentFn,  
so it's sure being self-centered in supposing that it gets to do so.  
  
Fortunately, it's quite simple to fix shimTriConsistentFn to restore  
the entry-time state of entryRes[], so let's do that instead.  
  
This issue doesn't affect any core GIN opclasses, since they all  
supply their own triConsistentFns.  It does affect contrib modules  
btree_gin, hstore, and intarray.  
  
Along the way, I (tgl) noticed that shimTriConsistentFn failed to  
pick up on a "recheck" flag returned by its first call to the boolean  
consistentFn.  This may be only a latent problem, since it would be  
unlikely for a consistentFn to set recheck for the all-false case  
and not any other cases.  (Indeed, none of our contrib modules do  
that.)  Nonetheless, it's formally wrong.  
  
Reported-by: Vinod Sridharan <vsridh90@gmail.com>  
Author: Vinod Sridharan <vsridh90@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFMdLD7XzsXfi1+DpTqTgrD8XU0i2C99KuF=5VHLWjx4C1pkcg@mail.gmail.com  
Backpatch-through: 13  

commit   : 3339847ccde019e6e691c9d4caec4736c06277bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Apr 2025 10:02:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Apr 2025 10:02:15 +0900    

synchronous_standby_names cannot be reloaded safely by backends, and the  
checkpointer is in charge of updating a state in shared memory if the  
GUC is enabled in WalSndCtl, to let the backends know if they should  
wait or not for a given LSN.  This provides a strict control on the  
timing of the waiting queues if the GUC is enabled or disabled, then  
reloaded.  The checkpointer is also in charge of waking up the backends  
that could be waiting for a LSN when the GUC is disabled.  
  
This logic had a race condition at startup, where it would be possible  
for backends to not wait for a LSN even if synchronous_standby_names is  
enabled.  This would cause visibility issues with transactions that we  
should be waiting for but they were not.  The problem lasts until the  
checkpointer does its initial update of the shared memory state when it  
loads synchronous_standby_names.  
  
In order to take care of this problem, the shared memory state in  
WalSndCtl is extended to detect if it has been initialized by the  
checkpointer, and not only check if synchronous_standby_names is  
defined.  In WalSndCtlData, sync_standbys_defined is renamed to  
sync_standbys_status, a bits8 able to know about two states:  
- If the shared memory state has been initialized.  This flag is set by  
the checkpointer at startup once, and never removed.  
- If synchronous_standby_names is known as defined in the shared memory  
state.  This is the same as the previous sync_standbys_defined in  
WalSndCtl.  
  
This method gives a way for backends to decide what they should do until  
the shared memory area is initialized, and they now ultimately fall back  
to a check on the GUC value in this case, which is the best thing that  
can be done.  
  
Fortunately, SyncRepUpdateSyncStandbysDefined() is called immediately by  
the checkpointer when this process starts, so the window is very narrow.  
It is possible to enlarge the problematic window by making the  
checkpointer wait at the beginning of SyncRepUpdateSyncStandbysDefined()  
with a hardcoded sleep for example, and doing so has showed that a 2PC  
visibility test is indeed failing.  On machines slow enough, this bug  
would cause spurious failures.  
  
In 17~, we have looked at the possibility of adding an injection point  
to have a reproducible test, but as the problematic window happens at  
early startup, we would need to invent a way to make an injection point  
optionally persistent across restarts when attached, something that  
would be fine for this case as it would involve the checkpointer.  This  
issue is quite old, and can be reproduced on all the stable branches.  
  
Author: Melnikov Maksim <m.melnikov@postgrespro.ru>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/163fcbec-900b-4b07-beaa-d2ead8634bec@postgrespro.ru  
Backpatch-through: 13  

commit   : 03faf38a13e51f708b1abf030aa33ad42731d027    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Apr 2025 14:49:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Apr 2025 14:49:10 -0400    

It's been twenty years since we generated constraint names that  
look like "$N".  So this advice about double-quoting such names  
is well past its sell-by date, and now it merely seems confusing.  
  
Reported-by: Yaroslav Saburov <y.saburov@gmail.com>  
Author: "David G. Johnston" <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/174393459040.678.17810152410419444783@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : cadaf0ac46374360e178f4ac120a7e29438b4dc0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 10 Apr 2025 12:57:10 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 10 Apr 2025 12:57:10 +0530    

Data loss can happen when the DDLs like ALTER PUBLICATION ... ADD TABLE ...  
or ALTER TYPE ...  that don't take a strong lock on table happens  
concurrently to DMLs on the tables involved in the DDL. This happens  
because logical decoding doesn't distribute invalidations to concurrent  
transactions and those transactions use stale cache data to decode the  
changes. The problem becomes bigger because we keep using the stale cache  
even after those in-progress transactions are finished and skip the  
changes required to be sent to the client.  
  
This commit fixes the issue by distributing invalidation messages from  
catalog-modifying transactions to all concurrent in-progress transactions.  
This allows the necessary rebuild of the catalog cache when decoding new  
changes after concurrent DDL.  
  
We observed performance regression primarily during frequent execution of  
*publication DDL* statements that modify the published tables. The  
regression is minor or nearly nonexistent for DDLs that do not affect the  
published tables or occur infrequently, making this a worthwhile cost to  
resolve a longstanding data loss issue.  
  
An alternative approach considered was to take a strong lock on each  
affected table during publication modification. However, this would only  
address issues related to publication DDLs (but not the ALTER TYPE ...)  
and require locking every relation in the database for publications  
created as FOR ALL TABLES, which is impractical.  
  
The bug exists in all supported branches, but we are backpatching till 14.  
The fix for 13 requires somewhat bigger changes than this fix, so the fix  
for that branch is still under discussion.  
  
Reported-by: hubert depesz lubaczewski <depesz@depesz.com>  
Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Tested-by: Benoit Lobréau <benoit.lobreau@dalibo.com>  
Backpatch-through: 14  
Discussion: https://postgr.es/m/de52b282-1166-1180-45a2-8d8917ca74c6@enterprisedb.com  
Discussion: https://postgr.es/m/CAD21AoAenVqiMjpN-PvGHL1N9DWnHSq673bfgr6phmBUzx=kLQ@mail.gmail.com  

commit   : 42bb4fb7281ec4881c8a9bac14e1ea7206d0e63d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 9 Apr 2025 07:23:39 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 9 Apr 2025 07:23:39 -0700    

This spec fails ~3% of my Valgrind runs, and the spec has failed on Valgrind  
buildfarm member skink at a similar rate.  Two problems contributed to that:  
  
- A competing buffer pin triggered VACUUM's lazy_scan_noprune() path, causing  
  "tuples missed: 1 dead from 1 pages not removed due to cleanup lock  
  contention".  FREEZE fixes that.  
  
- The spec ran lazy VACUUM immediately after VACUUM FULL.  The spec implicitly  
  assumed lazy VACUUM prunes the one tuple that VACUUM FULL made dead.  First  
  wait for old snapshots, making that assumption reliable.  
  
This also adds two forms of defense in depth:  
  
- Wait for snapshots using shared catalog pruning rules (VISHORIZON_SHARED).  
  This avoids the removable cutoff moving backward when an XID-bearing  
  autoanalyze process runs in another database.  That may never happen in this  
  test, but it's cheap insurance.  
  
- Use lazy VACUUM option DISABLE_PAGE_SKIPPING.  Commit  
  c2dc1a79767a0f947e1145f82eb65dfe4360d25f did this for a related requirement  
  in other tests, but I suspect FREEZE is necessary and sufficient in all  
  these tests.  
  
Back-patch to v17, where the test first appeared.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/sv3taq4e6ea4qckimien3nxp3sz4b6cw6sfcy4nhwl52zpur4g@h6i6tohxmizu  
Backpatch-through: 17  

commit   : 17a165d60f734b3aa2e495d890f0c4b8324ca629    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 8 Apr 2025 09:23:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 8 Apr 2025 09:23:07 +0530    

Some tests try to invalidate logical slots on the standby server by  
running VACUUM on the primary. The problem is that xl_running_xacts was  
getting generated and replayed before the VACUUM command, leading to the  
advancement of the active slot's catalog_xmin. Due to this, active slots  
were not getting invalidated, leading to test failures.  
  
We fix it by skipping the generation of xl_running_xacts for the required  
tests with the help of injection points. As the required interface for  
injection points was not present in back branches, we fixed the failing  
tests in them by disallowing the slot to become active for the required  
cases (where rows_removed conflict could be generated).  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where it was introduced  
Discussion: https://postgr.es/m/Z6oQXc8LmiTLfwLA@ip-10-97-1-34.eu-west-3.compute.internal  

commit   : b8b1e87b70aab380a4270926f49c06a07f00e14a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Apr 2025 21:33:41 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Apr 2025 21:33:41 -0400    

A PG 17 optimization allowed columns with NOT NULL constraints to skip  
table scans for IS NULL queries, and to skip IS NOT NULL checks for IS  
NOT NULL queries.  This didn't work for domain types, since domain types  
don't follow the IS NULL/IS NOT NULL constraint logic.  To fix, disable  
this optimization for domains for PG 17+.  
  
Reported-by: Jan Behrens  
  
Diagnosed-by: Tom Lane  
  
Discussion: https://postgr.es/m/Z37p0paENWWUarj-@momjian.us  
  
Backpatch-through: 17  

commit   : 5cbbe70a9cc6a9d8b7ed583cf66657be8ace0eaa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Apr 2025 07:58:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Apr 2025 07:58:47 +0900    

WAL senders do not flush their statistics until they exit, limiting the  
monitoring possible for live processes.  This is penalizing when WAL  
senders are running for a long time, like in streaming or logical  
replication setups, because it is not possible to know the amount of IO  
they generate while running.  
  
This commit makes WAL senders more aggressive with their statistics  
flush, using an internal of 1 second, with the flush timing calculated  
based on the existing GetCurrentTimestamp() done before the sleeps done  
to wait for some activity.  Note that the sleep done for logical and  
physical WAL senders happens in two different code paths, so the stats  
flushes need to happen in these two places.  
  
One test is added for the physical WAL sender case, and one for the  
logical WAL sender case.  This can be done in a stable fashion by  
relying on the WAL generated by the TAP tests in combination with a  
stats reset while a server is running, but only on HEAD as WAL data has  
been added to pg_stat_io in a051e71e28a1.  
  
This issue exists since a9c70b46dbe and the introduction of pg_stat_io,  
so backpatch down to v16.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/Z73IsKBceoVd4t55@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 16  

commit   : 4c1d853fd8c7ed832a231699512dc3f0fb6376fd    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 7 Apr 2025 00:03:18 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 7 Apr 2025 00:03:18 +0200    

Clarify the project naming in the history section of the docs  
to match the recent license preamble changes.  
  
Backpatch to all supported versions.  
  
Author: Dave Page <dpage@pgadmin.org>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA+OCxozLzK2+Jc14XZyWXSp6L9Ot+3efwXUE35FJG=fsbib2EA@mail.gmail.com  
Backpatch-through: 13  

commit   : 0851b6573877f0d22510688623eff4a2ab1dea49    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 6 Apr 2025 09:13:43 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 6 Apr 2025 09:13:43 -0700    

Introduced in 2a083ab807.  
  
Note: backport of commit 945126234b, which was missed at the time.  
  
Discussion: https://postgr.es/m/e852442da35b4f31acc600ed98bbee0f12e65e0c.camel@j-davis.com  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 16  

commit   : 5e7be43f4b8bfe77570e566b89f23fc73ea625dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2025 15:01:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2025 15:01:33 -0400    

makeDependencyGraphWalker thought that only SelectStmt nodes could  
contain a WithClause.  Which was true in our original implementation  
of WITH, but astonishingly we missed updating this code when we added  
the ability to attach WITH to INSERT/UPDATE/DELETE (and later MERGE).  
Moreover, since it was coded to deliberately block recursion to a  
WithClause, even updating raw_expression_tree_walker didn't save it.  
  
The upshot of this was that we didn't see references to outer CTE  
names appearing within an inner WITH, and would neither complain about  
disallowed recursion nor account for such references when sorting CTEs  
into a usable order.  The lack of complaints about this is perhaps not  
so surprising, because typical usage of WITH wouldn't hit either case.  
Still, it's pretty broken; failing to detect recursion here leads to  
assert failures or worse later on.  
  
Fix by factoring out the processing of sub-WITHs into a new function  
WalkInnerWith, and invoking that for all the statement types that  
can have WITH.  
  
Bug: #18878  
Reported-by: Yu Liang <luy70@psu.edu>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18878-a26fa5ab6be2f2cf@postgresql.org  
Backpatch-through: 13  

commit   : 717e8a1e5256fd01ed5b4cd60f2aac97dceb00bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2025 12:13:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2025 12:13:35 -0400    

transformJsonArrayQueryConstructor() applied transformStmt() to  
the same subquery tree twice.  While this causes no issue in many  
cases, there are some where it causes a coredump, thanks to the  
parser's habit of scribbling on its input.  
  
Fix by making a copy before the first transformation (compare  
0f43083d1).  This is quite brute-force, but then so is the  
whole business of transforming the input twice.  Per discussion  
in the bug thread, this implementation of json_array() parsing  
should be replaced completely.  But that will take some work  
and will surely not be back-patchable, so for the moment let's  
take the easy way out.  
  
Oversight in 7081ac46a.  Back-patch to v16 where that came in.  
  
Bug: #18877  
Reported-by: Yu Liang <luy70@psu.edu>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18877-c3c3ad75845833bb@postgresql.org  
Backpatch-through: 16  

commit   : 5e6e97fbf4031de0e7c84d87a002c0eef2ca7abe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Apr 2025 20:11:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Apr 2025 20:11:48 -0400    

Since v15 we've had an option to apply a foreign key constraint's  
ON DELETE SET DEFAULT or SET NULL action to just some of the  
referencing columns.  There was not a check for duplicate entries in  
the list of columns-to-set, though.  That caused a potential memory  
stomp in CreateConstraintEntry(), which incautiously assumed that  
the list of columns-to-set couldn't be longer than the number of key  
columns.  Even after fixing that, the case doesn't work because you  
get an error like "multiple assignments to same column" from the SQL  
command that is generated to do the update.  
  
We could either raise an error for duplicate columns or silently  
suppress the dups, and after a bit of thought I chose to do the  
latter.  This is motivated by the fact that duplicates in the FK  
column list are legal, so it's not real clear why duplicates  
in the columns-to-set list shouldn't be.  Of course there's no  
need to actually set the column more than once.  
  
I left in the fix in CreateConstraintEntry() too, just because  
it didn't seem like such low-level code ought to be making  
assumptions about what it's handed.  
  
Bug: #18879  
Reported-by: Yu Liang <luy70@psu.edu>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18879-259fc59d072bd4d7@postgresql.org  
Backpatch-through: 15  

commit   : 6526d07948c58fd83a71a902bea8caa793c9c4b8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 4 Apr 2025 13:49:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 4 Apr 2025 13:49:00 +0300    

Commit 28d3c2ddcf introduced an assertion that if the memorized  
downlink location in the insertion stack isn't valid, the parent's  
LSN should've changed too. Turns out that was too strict. In  
gistFindCorrectParent(), if we walk right, we update the parent's  
block number and clear its memorized 'downlinkoffnum'. That triggered  
the assertion on next call to gistFindCorrectParent(), if the parent  
needed to be split too. Relax the assertion, so that it's OK if  
downlinkOffnum is InvalidOffsetNumber.  
  
Backpatch to v13-, all supported versions. The assertion was added in  
commit 28d3c2ddcf in v12.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://www.postgresql.org/message-id/18396-03cac9beb2f7aac3@postgresql.org  

commit   : c88b36d382ebb7925db9f713dcf5ad8ca1bbae71    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 4 Apr 2025 09:47:36 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 4 Apr 2025 09:47:36 +0200    

The documentation for the special value "system" for sslrootcert could  
be misinterpreted to mean the default operating system CA store, which  
it may be, but it's defined to be the default CA store of the SSL lib  
used.  
  
Backpatch down to v16 where support for the system value was added.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: George MacKerron <george@mackerron.co.uk>  
Discussion: https://postgr.es/m/B3CBBAA3-6EA3-4AB7-8619-4BBFAB93DDB4@yesql.se  
Backpatch-through: 16  

commit   : aab422af95c395e01436f9fc0cb74ff96550143e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Apr 2025 13:32:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Apr 2025 13:32:46 +0900    

The regression test for logical decoding verifies whether a logical slot  
is correctly dropped on a standby when its associated database is dropped.  
However, the test mistakenly retrieved slot information from the primary  
instead of the standby, causing incorrect behavior.  
  
This commit fixes the issue by ensuring the test correctly checks the slot  
on the standby.  
  
Back-patch to all supported versions.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/1fdfd020-a509-403c-bd8f-a04664aba148@oss.nttdata.com  
Backpatch-through: 13  

commit   : 5570e103bf84af8ce4c71d4fd49920673907bc7f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Apr 2025 13:09:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Apr 2025 13:09:06 +0900    

The regression tests for logical decoding verify whether a logical slot  
exists or has been dropped. Previously, these tests attempted to  
retrieve "slot_name" from the result of slot(), but since "slot_name" was  
not included in the result, slot()->{'slot_name'} always returned undef,  
leading to incorrect behavior.  
  
This commit fixes the issue by checking the "plugin" field in the result  
of slot() instead, ensuring the tests properly verify slot existence.  
  
Back-patch to all supported versions.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB149667EC4E738769CA80B7EA5F5AE2@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : a4309e85f4614315584e67737ea7b5efa19fb24c    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 3 Apr 2025 10:30:02 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Thu, 3 Apr 2025 10:30:02 -0700    

Previously, invalidated logical and physical replication slots could  
be copied using the pg_copy_logical_replication_slot and  
pg_copy_physical_replication_slot functions. Replication slots that  
were invalidated for reasons other than WAL removal retained their  
restart_lsn. This meant that a new slot copied from an invalidated  
slot could have a restart_lsn pointing to a WAL segment that might  
have already been removed.  
  
This commit restricts the copying of invalidated replication slots.  
  
Backpatch to v16, where slots could retain their restart_lsn when  
invalidated for reasons other than WAL removal.  
  
For v15 and earlier, this check is not required since slots can only  
be invalidated due to WAL removal, and existing checks already handle  
this issue.  
  
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CANhcyEU65aH0VYnLiu%3DOhNNxhnhNhwcXBeT-jvRe1OiJTo_Ayg%40mail.gmail.com  
Backpatch-through: 16  

commit   : e0191121b2f0ef86138400fb89b150d0ae7353b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Apr 2025 16:17:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Apr 2025 16:17:43 -0400    

compareentry() is declared to work on WordEntryIN structs, but  
tsvectorrecv() is using it in two places to work on WordEntry  
structs.  This is almost okay, since WordEntry is the first  
field of WordEntryIN.  But on machines with 8-byte pointers,  
WordEntryIN will have a larger alignment spec than WordEntry,  
and it's at least theoretically possible that the compiler  
could generate code that depends on the larger alignment.  
  
Given the lack of field reports, this may be just a hypothetical bug  
that upsets nothing except sanitizer tools.  Or it may be real on  
certain hardware but nobody's tried to use tsvectorrecv() on such  
hardware.  In any case we should fix it, and the fix is trivial:  
just change compareentry() so that it works on WordEntry without any  
mention of WordEntryIN.  We can also get rid of the quite-useless  
intermediate function WordEntryCMP.  
  
Bug: #18875  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18875-07a29c49c825a608@postgresql.org  
Backpatch-through: 13  

commit   : 78cb2466f75280da70461f8b9ae3d1062c884214    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 2 Apr 2025 14:25:17 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 2 Apr 2025 14:25:17 -0400    

The optimization does not take the removal of TIDs by a concurrent vacuum into  
account. The concurrent vacuum can remove dead TIDs and make pages ALL_VISIBLE  
while those dead TIDs are referenced in the bitmap. This can lead to a  
skip_fetch scan returning too many tuples.  
  
It likely would be possible to implement this optimization safely, but we  
don't have the necessary infrastructure in place. Nor is it clear that it's  
worth building that infrastructure, given how limited the skip_fetch  
optimization is.  
  
In the backbranches we just disable the optimization by always passing  
need_tuples=true to table_beginscan_bm(). We can't perform API/ABI changes in  
the backbranches and we want to make the change as minimal as possible.  
  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Reported-By: Konstantin Knizhnik <knizhnik@garret.ru>  
Discussion: https://postgr.es/m/CAEze2Wg3gXXZTr6_rwC+s4-o2ZVFB5F985uUSgJTsECx6AmGcQ@mail.gmail.com  
Backpatch-through: 13  

commit   : 0941aadcd55b58a03af5d06f3374ca168522097f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Apr 2025 11:13:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Apr 2025 11:13:01 -0400    

Without this, an additional change to the same pg_attribute row  
within the same command will fail.  This is possible at least with  
ALTER TABLE ADD COLUMN on a multiple-inheritance-pathway structure.  
(Another potential hazard is that immediately-following operations  
might not see the missingval.)  
  
Introduced by 95f650674, which split the former coding that  
used a single pg_attribute update to change both atthasdef and  
atthasmissing/attmissingval into two updates, but missed that  
this should entail two CommandCounterIncrements as well.  Like  
that fix, back-patch through v13.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/025a3ffa-5eff-4a88-97fb-8f583b015965@gmail.com  
Backpatch-through: 13  

commit   : b19893b94bdea3b206cb544619d84cea6276f648    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Apr 2025 14:34:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Apr 2025 14:34:24 +0200    

The changes made in commit d2b4b4c2259 contained incorrect comments:  
They said that certain forward declarations were necessary to "avoid  
including pathnodes.h here", but the file is itself pathnodes.h!  So  
change the comment to just say it's a forward declaration in one case,  
and in the other case we don't need the declaration at all because it  
already appeared earlier in the file.  

commit   : e962d6d12b7e8185775da26ef0f77a3ac63d18a0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 14:03:48 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 14:03:48 +1300    

The documentation around locking of partitions for the executor startup  
phase of run-time partition pruning wasn't clear about which partitions  
were being locked.  Fix that.  
  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAApHDvp738G75HfkKcfXaf3a8s%3D6mmtOLh46tMD0D2hAo1UCzA%40mail.gmail.com  
Backpatch-through: 13  

commit   : 5672a839977949457d1f81a4fd43b1e7c097ba14    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 11:57:27 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 11:57:27 +1300    

50e17ad28 (v14) and 29f45e299 (v15) made it so the planner could identify  
IN and NOT IN clauses which have Const lists as right-hand arguments and  
when an appropriate hash function is available for the data types, mark  
the ScalarArrayOpExpr as hashable so the executor could execute it more  
optimally by building and probing a hash table during expression  
evaluation.  
  
These commits both worked correctly when there was only a single  
ScalarArrayOpExpr in the given expression being processed by the  
planner, but when there were multiple, only the first was checked and any  
subsequent ones were not identified, which resulted in less optimal  
expression evaluation during query execution for all but the first found  
ScalarArrayOpExpr.  
  
Backpatch to 14, where 50e17ad28 was introduced.  
  
Author: David Geier <geidav.pg@gmail.com>  
Discussion: https://postgr.es/m/29a76f51-97b0-4c07-87b7-ec8e3b5345c9@gmail.com  
Backpatch-through: 14  

commit   : 915e88968034a7422679b74c3002f5c150c33e35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Apr 2025 16:49:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Apr 2025 16:49:51 -0400    

As of 15.4, macOS has strchrnul(), but access to it is blocked behind  
a check for MACOSX_DEPLOYMENT_TARGET >= 15.4.  But our does-it-link  
configure check finds it, so we try to use it, and fail with the  
present default deployment target (namely 15.0).  This accounts for  
today's buildfarm failures on indri and sifaka.  
  
This is the identical problem that we faced some years ago when Apple  
introduced preadv and pwritev in the same way.  We solved that in  
commit f014b1b9b by using AC_CHECK_DECLS instead of AC_CHECK_FUNCS  
to check the functions' availability.  So do the same now for  
strchrnul().  Interestingly, we already had a workaround for  
"the link check doesn't agree with <string.h>" cases with glibc,  
which we no longer need since only the header declaration is being  
checked.  
  
Testing this revealed that the meson version of this check has never  
worked, because it failed to use "-Werror=unguarded-availability-new".  
(Apparently nobody's tried to build with meson on macOS versions that  
lack preadv/pwritev as standard.)  Adjust that while at it.  Also,  
we had never put support for "-Werror=unguarded-availability-new"  
into v13, but we need that now.  
  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Co-authored-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/385134.1743523038@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 25303678a1d334200c0f1446eef2ebe1aaf2709b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 29 Mar 2025 09:50:14 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 29 Mar 2025 09:50:14 +0000    

ExecInitPartitionInfo() duplicates much of the logic in  
ExecInitMerge(), except that it failed to handle DO NOTHING  
actions. This would cause an "unknown action in MERGE WHEN clause"  
error if a MERGE with any DO NOTHING actions attempted to insert into  
a partition not already initialised by ExecInitModifyTable().  
  
Bug: #18871  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Gurjeet Singh <gurjeet@singh.im>  
Discussion: https://postgr.es/m/18871-b44e3c96de3bd2e8%40postgresql.org  
Backpatch-through: 15  

commit   : 8afec4ef67a2fcec2ad0537fad5bc66e4388bc41    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 27 Mar 2025 22:57:34 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 27 Mar 2025 22:57:34 +0100    

check_createrole_self_grant and check_synchronized_standby_slots  
were allocating memory on a LOG elevel without checking if the  
allocation succeeded or not, which would have led to a segfault  
on allocation failure.  
  
On top of that, a number of callsites were using the ERROR level,  
relying on erroring out rather than returning false to allow the  
GUC machinery handle it gracefully.  Other callsites used WARNING  
instead of LOG.  While neither being not wrong, this changes all  
check_ functions do it consistently with LOG.  
  
init_custom_variable gets a promoted elevel to FATAL to keep  
the guc_malloc error handling in line with the rest of the  
error handling in that function which already call FATAL.  If  
we encounter an OOM in this callsite there is no graceful  
handling to be had, better to error out hard.  
  
Backpatch the fix to check_createrole_self_grant down to v16  
and the fix to check_synchronized_standby_slots down to v17  
where they were introduced.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Nikita <pm91.arapov@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Bug: #18845  
Discussion: https://postgr.es/m/18845-582c6e10247377ec@postgresql.org  
Backpatch-through: 16  

commit   : 51d038da8280a597ebb769a9a1bcf027d4d80132    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Mar 2025 13:20:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Mar 2025 13:20:23 -0400    

Applying pg_freespacemap() to a relation lacking storage (such as a  
view) caused an assertion failure, although there was no ill effect  
in non-assert builds.  Add an error check for that case.  
  
Bug: #18866  
Reported-by: Robins Tharakan <tharakan@gmail.com>  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Discussion: https://postgr.es/m/18866-d68926d0f1c72d44@postgresql.org  
Backpatch-through: 13  

commit   : 2afdb9dd96fb01fa22a11275c0bd47db14d05998    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Mar 2025 10:20:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Mar 2025 10:20:45 +0900    

The implementation of FSM for indexes is simpler than heap, where 0 is  
used to track if a page is in-use and (BLCKSZ - 1) if a page is free.  
One comment in indexfsm.c and one description in the documentation of  
pg_freespacemap were incorrect about that.  
  
Author: Alex Friedman <alexf01@gmail.com>  
Discussion: https://postgr.es/m/71eef655-c192-453f-ac45-2772fec2cb04@gmail.com  
Backpatch-through: 13  

commit   : cb0ad70b8e47a2beb199b2106fb652f6a287aade    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 26 Mar 2025 16:50:13 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 26 Mar 2025 16:50:13 +0100    

The brin_bloom_union() function combines two BRIN summaries, by merging  
one filter into the other. With bloom, we have to decompress the filters  
first, but the function failed to update the summary to store the merged  
filter. As a consequence, the index may be missing some of the data, and  
return false negatives.  
  
This issue exists since BRIN bloom indexes were introduced in Postgres  
14, but at that point the union function was called only when two  
sessions happened to summarize a range concurrently, which is rare. It  
got much easier to hit in 17, as parallel builds use the union function  
to merge summaries built by workers.  
  
Fixed by storing a pointer to the decompressed filter, and freeing the  
original one. Free the second filter too, if it was decompressed. The  
freeing is not strictly necessary, because the union is called in  
short-lived contexts, but it's tidy.  
  
Backpatch to 14, where BRIN bloom indexes were introduced.  
  
Reported by Arseniy Mukhin, investigation and fix by me.  
  
Reported-by: Arseniy Mukhin  
Discussion: https://postgr.es/m/18855-1cf1c8bcc22150e6%40postgresql.org  
Backpatch-through: 14  

commit   : 34fbfe1f57d84163fea4e234bf78d3b5fd5364b1    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 26 Mar 2025 17:46:51 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 26 Mar 2025 17:46:51 +0900    

Setting the iteration count for SCRAM secret generation to INT_MAX  
will cause an infinite loop in scram_SaltedPassword() due to integer  
overflow, as the loop uses the "i <= iterations" comparison.  To fix,  
use "i < iterations" instead.  
  
Back-patch to v16 where the user-settable GUC scram_iterations has  
been added.  
  
Author: Kevin K Biju <kevinkbiju@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAM45KeEMm8hnxdTOxA98qhfZ9CzGDdgy3mxgJmy0c+2WwjA6Zg@mail.gmail.com  

commit   : f186f90e55b7d984be572e3628e19e6d018c7199    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Mar 2025 20:03:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Mar 2025 20:03:56 -0400    

We need the -I switch for libpq_srcdir to come before any -I switches  
injected by configure.  Otherwise there is a risk of pulling in a  
mismatched version of libpq_fe.h from someplace like  
/usr/local/include, if the platform has another Postgres version  
installed there.  This evidently accounts for today's buildfarm  
failures on "anaconda".  
  
In principle the -I switch for src/port/ is at similar hazard, and has  
been for a very long time.  But the only .h files we keep there are  
pg_config_paths.h and pthread-win32.h, neither of which get installed  
on Unix-ish systems, so the odds of picking up a conflicting header  
seem pretty small.  That doubtless accounts for the lack of prior  
reports.  
  
Back-patch to v17 where pg_regress acquired a build dependency on  
libpq_fe.h.  We could go back further to fix the hazard for src/port/  
in older branches, but it seems unlikely to be worth troubling over.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/Z-MhRzoc7t-nPUQG@nathan  
Backpatch-through: 17  

commit   : c5cf99e9e52e99400654aa51fe6aa5a8e89bab6f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 25 Mar 2025 12:48:48 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 25 Mar 2025 12:48:48 +0200    

If a var belongs to the innerrel of the joinrel, it's not possible that  
it belongs to the outerrel.  This commit removes the redundant check from  
the if-clause but keeps it as an assertion.  
  
Discussion: https://postgr.es/m/flat/CAHewXN=8aW4hd_W71F7Ua4+_w0=bppuvvTEBFBF6G0NuSXLwUw@mail.gmail.com  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Alexander Pyhalov <a.yhalov@postgrespro.ru>  
Backpatch-through: 17  

commit   : 729fe699e61231a01d834078c0566830638440ee    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 25 Mar 2025 05:49:47 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 25 Mar 2025 05:49:47 +0200    

Semi-join joins below left/right join are deparsed as  
subqueries.  Thus, we can't refer to subqueries vars from upper relations.  
This commit avoids pulling conditions from them.  
  
Reported-by: Robins Tharakan <tharakan@gmail.com>  
Bug: #18852  
Discussion: https://postgr.es/m/CAEP4nAzryLd3gwcUpFBAG9MWyDfMRX8ZjuyY2XXjyC_C6k%2B_Zw%40mail.gmail.com  
Author: Alexander Pyhalov <a.pyhalov@postgrespro.ru>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Backpatch-through: 17  

commit   : 302ce5bd93b48549bf6717512ea92252319dc944    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 23 Mar 2025 20:41:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 23 Mar 2025 20:41:16 +0200    

During hot standby, ExpireAllKnownAssignedTransactionIds() and  
ExpireOldKnownAssignedTransactionIds() functions mark old transactions  
as no-longer running, but they failed to update xactCompletionCount  
and latestCompletedXid. AFAICS it would not lead to incorrect query  
results, because those functions effectively turn in-progress  
transactions into aborted transactions and an MVCC snapshot considers  
both as "not visible". But it could surprise GetSnapshotDataReuse()  
and trigger the "TransactionIdPrecedesOrEquals(TransactionXmin,  
RecentXmin))" assertion in it, if the apparent xmin in a backend would  
move backwards. We saw this happen when GetCatalogSnapshot() would  
reuse an older catalog snapshot, when GetTransactionSnapshot() had  
already advanced TransactionXmin.  
  
The bug goes back all the way to commit 623a9ba79b in v14 that  
introduced the snapshot reuse mechanism, but it started to happen more  
frequently with commit 952365cded6 which removed a  
GetTransactionSnapshot() call from backend startup. That made it more  
likely for ExpireOldKnownAssignedTransactionIds() to be called between  
GetCatalogSnapshot() and the first GetTransactionSnapshot() in a  
backend.  
  
Andres Freund first spotted this assertion failure on buildfarm member  
'skink'. Reproduction and analysis by Tomas Vondra.  
  
Backpatch-through: 14  
Discussion: https://www.postgresql.org/message-id/oey246mcw43cy4qw2hqjmurbd62lfdpcuxyqiu7botx3typpax%40h7o7mfg5zmdj  

commit   : 1353b1161a790e64507428e33cc0c5975f26474b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Mar 2025 11:30:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Mar 2025 11:30:42 -0400    

exec_save_simple_expr did not account for the possibility that  
standard_planner would stick a Materialize node atop the plan  
of even a simple Result, if CURSOR_OPT_SCROLL is set.  This led  
to an "unexpected plan node type" error.  
  
This is a very old bug, but it'd only be reached by declaring a  
cursor for a "SELECT simple-expression" query and explicitly  
marking it scrollable, which is an odd thing to do.  So the lack  
of prior reports isn't too surprising.  
  
Bug: #18859  
Reported-by: Olleg Samoylov <splarv@ya.ru>  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18859-0d5f28ac99a37059@postgresql.org  
Backpatch-through: 13  

commit   : 97ce4d375a0ada1c1dd2f23552b40eadf5ecf14e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Mar 2025 12:56:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Mar 2025 12:56:39 +0900    

pg_drop_replication_slot() can drop replication slots created on  
a different database than the one where it is executed. This behavior  
has been in place since PostgreSQL 9.4, when pg_drop_replication_slot()  
was introduced.  
  
However, commit ff539d mistakenly added the following incorrect  
description in the documentation:  
  
     For logical slots, this must be called when connected to  
     the same database the slot was created on.  
  
This commit removes that incorrect statement. A similar mistake was  
also present in the documentation for the DROP_REPLICATION_SLOT  
command, which has now been corrected as well.  
  
Back-patch to all supported versions.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/OSCPR01MB14966C6BE304B5BB2E58D4009F5DE2@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : 9de86e367a675baee879eeca93f1ddf3da29542f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Mar 2025 09:04:09 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Mar 2025 09:04:09 -0400    

Otherwise the progress won't reliably be displayed during a test.  
  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/kx6xu7suexal5vwsxpy7ybgkcznx6hgywbuhkr6qabcwxjqax2@i4pcpk75jvaa  
Backpatch-through: 16  

commit   : a38dce3c4a90aa0facef350bc6a502f31b0cfa31    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 18 Mar 2025 16:36:59 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 18 Mar 2025 16:36:59 -0700    

bbf668d66fbf lowered the minimum value of maintenance_work_mem to  
64kB. However, in parallel vacuum cases, since the initial underlying  
DSA size is 256kB, it attempts to perform a cycle of index vacuuming  
and table vacuuming with an empty TID store, resulting in an assertion  
failure.  
  
This commit ensures that at least one page is processed before index  
vacuuming and table vacuuming begins.  
  
Backpatch to 17, where the minimum maintenance_work_mem value was  
lowered.  
  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoCEAmbkkXSKbj4dB+5pJDRL4ZHxrCiLBgES_g_g8mVi1Q@mail.gmail.com  
Backpatch-through: 17  

commit   : ee578921b60ef9a14eaea54b608549e4f8b14f26    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 18 Mar 2025 13:43:10 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 18 Mar 2025 13:43:10 -0400    

In case the smgr_open callback failed, the ->pincount field would not be  
initialized and the relation would not be put onto the unpinned_relns list.  
  
This buglet was introduced in 21d9c3ee4ef7, in 17.  
  
Discussion: https://postgr.es/m/3vae7l5ozvqtxmd7rr7zaeq3qkuipz365u3rtim5t5wdkr6f4g@vkgf2fogjirl  
Backpatch-through: 17  

commit   : 09ef2f8df1cd746d711ffd916bdd2e9526c51b65    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 16 Mar 2025 13:28:22 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 16 Mar 2025 13:28:22 +0200    

47f99a407d introduced a parallel index-level REINDEX.  The code was written  
assuming that running run_reindex_command() with 'async == true' can schedule  
a number of queries for a connection.  That's not true, and the second query  
sent using run_reindex_command() will wait for the completion of the previous  
one.  
  
This commit fixes that by putting REINDEX commands for the same table into a  
single query.  
  
Also, this commit removes the 'async' argument from run_reindex_command(),  
as only its call always passes 'async == true'.  
  
Reported-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202503071820.j25zn3lo4hvn%40alvherre.pgsql  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Backpatch-through: 17  

commit   : c826cd1b1d42823406360ab5f795490ca8744961    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2025 16:07:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2025 16:07:55 -0400    

If the given input_type yields valid results from both  
get_element_type and get_array_type, initArrayResultAny believed the  
former and treated the input as an array type.  However this is  
inconsistent with what get_promoted_array_type does, leading to  
situations where the output of an ARRAY() subquery is labeled with  
the wrong type: it's labeled as oidvector[] but is really a 2-D  
array of OID.  That at least results in strange output, and can  
result in crashes if further processing such as unnest() is applied.  
AFAIK this is only possible with the int2vector and oidvector  
types, which are special-cased to be treated mostly as true arrays  
even though they aren't quite.  
  
Fix by switching the logic to match get_promoted_array_type by  
testing get_array_type not get_element_type, and remove an Assert  
thereby made pointless.  (We need not introduce a symmetrical  
check for get_element_type in the other if-branch, because  
initArrayResultArr will check it.)  This restores the behavior  
that existed before bac27394a introduced initArrayResultAny:  
the output really is int2vector[] or oidvector[].  
  
Comparable confusion exists when an input of an ARRAY[] construct  
is int2vector or oidvector: transformArrayExpr decides it's dealing  
with a multidimensional array constructor, and we end up with  
something that's a multidimensional OID array but is alleged to be  
of type oidvector.  I have not found a crashing case here, but it's  
easy to demonstrate totally-wrong results.  Adjust that code so  
that what you get is an oidvector[] instead, for consistency with  
ARRAY() subqueries.  (This change also makes these types work like  
domains-over-arrays in this context, which seems correct.)  
  
Bug: #18840  
Reported-by: yang lei <ylshiyu@126.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18840-fbc9505f066e50d6@postgresql.org  
Backpatch-through: 13  

commit   : e273468070ab4212b0babb5b6e94cb57256c3512    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 13 Mar 2025 15:43:34 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 13 Mar 2025 15:43:34 +1300    

In a couple of places, read_stream.c assumed that io_combine_limit would  
be stable during the lifetime of a stream.  That is not true in at least  
one unusual case: streams held by CURSORs where you could change the GUC  
between FETCH commands, with unpredictable results.  
  
Fix, by storing stream->io_combine_limit and referring only to that  
after construction.  This mirrors the treatment of the other important  
setting {effective,maintenance}_io_concurrency, which is stored in  
stream->max_ios.  
  
One of the cases was the queue overflow space, which was sized for  
io_combine_limit and could be overrun if the GUC was increased.  Since  
that coding was a little hard to follow, also introduce a variable for  
better readability instead of open-coding the arithmetic.  Doing so  
revealed an off-by-one thinko while clamping max_pinned_buffers to  
INT16_MAX, though that wasn't a live bug due to the current limits on  
GUC values.  
  
Back-patch to 17.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2B2T9p-%2BzM6Eeou-RAJjTML6eit1qn26f9twznX59qtCA%40mail.gmail.com  

commit   : 8b2392ae3d5b7e1225ea5d7ffde1d65791dd112a    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Thu, 13 Mar 2025 09:56:49 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Thu, 13 Mar 2025 09:56:49 +0900    

Commit 3c152a27b06 mistakenly repeated JSONTYPE_JSON in a condition,  
omitting JSONTYPE_CAST. As a result, datum_to_jsonb_internal() failed  
to reject inputs that were casts (e.g., from an enum to json as in the  
example below) when used as keys in JSON constructors.  
  
This led to a crash in cases like:  
  
  SELECT JSON_OBJECT('happy'::mood: '123'::jsonb);  
  
where 'happy'::mood is implicitly cast to json. The missing check  
meant such casted values weren’t properly rejected as invalid  
(non-scalar) JSON keys.  
  
Reported-by: Maciek Sakrejda <maciek@pganalyze.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Maciek Sakrejda <maciek@pganalyze.com>  
Discussion: https://postgr.es/m/CADXhmgTJtJZK9A3Na_ry+Xrq-ghjcejBRhcRMzWZvbd__QdgJA@mail.gmail.com  
Backpatch-through: 17  

commit   : e731e9d5eee8c9ba554b10e4f192951344dd0624    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Mar 2025 20:53:09 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Mar 2025 20:53:09 +0200    

We did not wake up on interrupts while waiting on async events on an  
async-capable append node. For example, if you tried to cancel the  
query, nothing would happen until one of the async subplans becomes  
readable. To fix, add WL_LATCH_SET to the WaitEventSet.  
  
Backpatch down to v14 where async Append execution was introduced.  
  
Discussion: https://www.postgresql.org/message-id/37a40570-f558-40d3-b5ea-5c2079b3b30b@iki.fi  

commit   : ca0830e5a27a1a7e58bc62b4b7950c1bf96d882c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Mar 2025 11:47:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Mar 2025 11:47:19 -0400    

makeWholeRowVar() has different rules for constructing a  
whole-row Var depending on the kind of RTE it's representing.  
This turns out to be problematic because the rewriter and planner  
can convert view RTEs and set-returning-function RTEs into  
subquery RTEs; so a whole-row Var made during planning might  
look different from one made by the parser.  In isolation this  
doesn't cause any problem, but if a query contains Vars made  
both ways for the same varno, there are cross-checks in the  
executor that will complain.  This manifests for UPDATE, DELETE,  
and MERGE queries that use whole-row table references.  
  
To fix, we need makeWholeRowVar() to produce the same result  
from an inlined RTE as it would have for the original.  For  
an inlined view, we can use RangeTblEntry.relid to detect  
that this had been a view RTE.  For inlined SRFs, make a  
data structure definition change akin to commit 47bb9db75,  
and say that we won't clear RangeTblEntry.functions until  
the end of planning.  That allows makeWholeRowVar() to  
repeat what it would have done with the unmodified RTE.  
  
Reported-by: Duncan Sands <duncan.sands@deepbluecap.com>  
Reported-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Diagnosed-by: Tender Wang <tndrwang@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/3518c50a-ab18-482f-b916-a37263622501@deepbluecap.com  
Backpatch-through: 13  

commit   : ade976f8b48193c7d57f475033d60bc5fa185a4a    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 11 Mar 2025 12:50:35 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 11 Mar 2025 12:50:35 +0100    

With improperly defined operator classes, it's possible to get a  
Postgres crash because we'd try to invoke a procedure that doesn't  
exist.  This is because the code is being a bit too trusting that the  
opclass is correctly defined.  Add some ereport(ERROR)s for cases where  
mandatory support procedures are not defined, transforming the crashes  
into errors.  
  
The particular case that was reported is an incomplete opclass in  
PostGIS.  
  
Backpatch all the way down to 13.  
  
Reported-by: Tobias Wendorff <tobias.wendorff@tu-dortmund.de>  
Diagnosed-by: David Rowley <dgrowleyml@gmail.com>  
Reviewed-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/fb6d9a35-6c8e-4869-af80-0a4944a793a4@tu-dortmund.de  

commit   : f1ef111a0940fedace997fe740fb221b068cf6ee    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Mar 2025 18:54:58 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Mar 2025 18:54:58 +0200    

Commit 2367503177 fixed this in RelationFindReplTupleByIndex(), but I  
missed two other similar cases.  
  
Per report from Ranier Vilela.  
  
Discussion: https://www.postgresql.org/message-id/CAEudQArUT1dE45WN87F-Gb7XMy_hW6x1DFd3sqdhhxP-RMDa0Q@mail.gmail.com  
Backpatch-through: 13  

commit   : c1dd3a9443991244b7cfac407cdb23150e97b46a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Mar 2025 17:07:38 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Mar 2025 17:07:38 +0200    

The function calls GetLatestSnapshot() to acquire a fresh snapshot,  
makes it active, and was meant to pass it to table_tuple_lock(), but  
instead called GetLatestSnapshot() again to acquire yet another  
snapshot. It was harmless because the heap AM and all other known  
table AMs ignore the 'snapshot' argument anyway, but let's be tidy.  
  
In the long run, this perhaps should be redesigned so that snapshot  
was not needed in the first place. The table AM API uses TID +  
snapshot as the unique identifier for the row version, which is  
questionable when the row came from an index scan with a Dirty  
snapshot. You might lock a different row version when you use a  
different snapshot in the table_tuple_lock() call (a fresh MVCC  
snapshot) than in the index scan (DirtySnapshot). However, in the heap  
AM and other AMs where the TID alone identifies the row version, it  
doesn't matter. So for now, just fix the obvious albeit harmless bug.  
  
This has been wrong ever since the table AM API was introduced in  
commit 5db6df0c01, so backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/83d243d6-ad8d-4307-8b51-2ee5844f6230@iki.fi  
Backpatch-through: 13  

commit   : 0f27bd14e48026fe4ddf131a531b230680868aaf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Mar 2025 10:22:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Mar 2025 10:22:08 -0400    

The previous wording talked about a "single pass over the data",  
which can be read as promising more than intended (to wit, that only  
one WindowAgg plan node will be used).  What we promise is only what  
the SQL spec requires, namely that the data not get re-sorted between  
window functions with compatible PARTITION BY/ORDER BY clauses.  
Adjust the wording in hopes of making this clearer.  
  
Reported-by: Christopher Inokuchi <cinokuchi@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CABde6B5va2wMsnM79u_x=n9KUgfKQje_pbLROEBmA9Ru5XWidw@mail.gmail.com  
Backpatch-through: 13  

commit   : 43847dd5e93816ef6e37dfb6c8bb7f98f48ddc01    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Mar 2025 13:11:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Mar 2025 13:11:20 -0400    

This doesn't work because record_recv requires the typmod that  
identifies the specific record type (in our session) and  
array_agg_deserialize has no convenient way to get that information.  
The result is an "input of anonymous composite types is not  
implemented" error.  
  
We could probably make this work if we had to, but it does not seem  
worth the trouble, given that it took this long to get a field report.  
Just shut off parallelization, as though record_recv didn't exist.  
  
Oversight in commit 16fd03e95.  Back-patch to v16 where that  
came in.  
  
Reported-by: Kirill Zdornyy <kirill@dineserve.com>  
Diagnosed-by: Richard Guo <guofenglinux@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/atLI5Kce2ie1zcYjU0w_kjtVaxiYbYGTihrkLDmGZQnRDD4pnXukIATaABbnIj9pUnelC4ESvCXMm4HAyHg-v61XABaKpERj0A2IXzJZM7g=@dineserve.com  
Backpatch-through: 16  

commit   : 99c01aadf979eed412a5189c8370ec8fe4784e6f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Mar 2025 11:24:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Mar 2025 11:24:22 -0500    

Per POSIX, a caller of strtol() that wishes to check for errors must  
set errno to 0 beforehand.  Several places in spell.c neglected that,  
so that they risked delivering a false overflow error in case errno  
had been ERANGE already.  Given the lack of field reports, this case  
may be unreachable at present --- but it's surely trouble waiting to  
happen, so fix it.  
  
Author: Jacob Brazeal <jacob.brazeal@gmail.com>  
Discussion: https://postgr.es/m/CA+COZaBhsq6EromFm+knMJfzK6nTpG23zJ+K2=nfUQQXcj_xcQ@mail.gmail.com  
Backpatch-through: 13  

commit   : c3510cfc8b401d61812713c4ccf040125dc7ce1b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 7 Mar 2025 15:23:09 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 7 Mar 2025 15:23:09 -0600    

pqsignal() already does a similar check, but strange Valgrind  
reports have us wondering if wrapper_handler() is somehow getting  
called with an invalid signal number.  
  
Reported-by: Tomas Vondra <tomas@vondra.me>  
Suggested-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/ace01111-f9ac-4f61-b1b1-8e9379415444%40vondra.me  
Backpatch-through: 17  

commit   : 5c8dcf9483349f39ee8da965c3acd3a61cf242fe    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 7 Mar 2025 10:22:56 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 7 Mar 2025 10:22:56 +0700    

The threshold is two billion members, which was interpreted as 2GB  
in the documentation. Fix to reflect that each member takes up five  
bytes, which translates to about 10GB. This is not exact, because of  
page boundaries. While at it, mention the maximum size 20GB.  
  
This has been wrong since commit c552e171d16e, so backpatch to  
version 14.  
  
Author: Alex Friedman <alexf01@gmail.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/CACbFw60UOk6fCC02KsyT3OfU9Dnuq5roYxdw2aFisiN_p1L0bg@mail.gmail.com  
Backpatch-through: 14  

commit   : 9094eb25b7d956307677f9ff26c8a3fc900ca1c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2025 11:54:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2025 11:54:27 -0500    

If a GIN index search had a lot of search keys (for example,  
"jsonbcol ?| array[]" with tens of thousands of array elements),  
both ginFillScanKey() and startScanKey() took O(N^2) time.  
Worse, those loops were uncancelable for lack of CHECK_FOR_INTERRUPTS.  
  
The problem in ginFillScanKey() is the brute-force search key  
de-duplication done in ginFillScanEntry().  The most expedient  
solution seems to be to just stop trying to de-duplicate once  
there are "too many" search keys.  We could imagine working harder,  
say by using a sort-and-unique algorithm instead of brute force  
compare-all-the-keys.  But it seems unlikely to be worth the trouble.  
There is no correctness issue here, since the code already allowed  
duplicate keys if any extra_data is present.  
  
The problem in startScanKey() is the loop that attempts to identify  
the first non-required search key.  In the submitted test case, that  
vainly tests all the key positions, and each iteration takes O(N)  
time.  One part of that is that it's reinitializing the entryRes[]  
array from scratch each time, which is entirely unnecessary given  
that the triConsistentFn isn't supposed to scribble on its input.  
We can easily adjust the array contents incrementally instead.  
The other part of it is that the triConsistentFn may itself take  
O(N) time (and does in this test case).  This is all extremely  
brute force: in simple cases with AND or OR semantics, we could  
know without any looping whatever that all or none of the keys  
are required.  But GIN opclasses don't have any API for exposing  
that knowledge, so at least in the short run there is little to  
be done about that.  Put in a CHECK_FOR_INTERRUPTS so that at  
least the loop is cancelable.  
  
These two changes together resolve the primary complaint that  
the test query doesn't respond promptly to cancel interrupts.  
Also, while they don't completely eliminate the O(N^2) behavior,  
they do provide quite a nice speedup for mid-sized examples.  
  
Bug: #18831  
Reported-by: Niek <niek.brasa@hitachienergy.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18831-e845ac44ebc5dd36@postgresql.org  
Backpatch-through: 13  

commit   : 3f4c5e38e8818bc3a29f8efae4e7b68055dd31c7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 5 Mar 2025 10:29:08 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 5 Mar 2025 10:29:08 -0500    

Upgrade to the current stable version. To avoid needing commits like this in  
the future, the CI image name now doesn't contain the OS version number  
anymore.  
  
Backpatch to all versions with CI support, we don't want to generate CI images  
for multiple FreeBSD versions.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/CAN55FZ3_P4JJ6tWZafjf-_XbHgG6DQGXhH-y6Yp78_bwBJjcww@mail.gmail.com  

commit   : 4e026be5f15994a7036eaca172126226e053f655    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 Mar 2025 20:07:30 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 Mar 2025 20:07:30 +0100    

This bogus error message was introduced in 2013 by commit f177cbfe676d,  
because of misunderstanding the processCASbits() API; at the time, no  
test cases were added that would be affected by this change.  Only in  
ca87c415e2fc was one added (along with a couple of typos), with an XXX  
note that the error message was bogus.  Fix the whole, add some test  
cases.  
  
Backpatch all the way back.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/202503041822.aobpqke3igvb@alvherre.pgsql  

commit   : 56e6a3186885c726bbbff89eaec0b2fa077d0a9a    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 4 Mar 2025 12:08:27 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 4 Mar 2025 12:08:27 +0100    

This updates the paragraph on backwards compatitibility for server  
features to include --incremental which only works on servers with  
v17 or newer.  Backpatch down to v17 where incremental backup was  
added.  
  
Author: David G. Johnston <David.G.Johnston@Gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAKFQuwZYfZyeTkS3g2Ovw84TsxHa796xnf-u5kfgn_auyxZk0Q@mail.gmail.com  
Backpatch-through: 17  

commit   : bc5a08af3c44b4529d5dba5e26755e8cfbb0d3c7    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 4 Mar 2025 16:17:19 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 4 Mar 2025 16:17:19 +0900    

In commit b262ad440, we introduced an optimization that reduces an IS  
NOT NULL qual on a column defined as NOT NULL to constant true, and an  
IS NULL qual on a NOT NULL column to constant false, provided we can  
prove that the input expression of the NullTest is not nullable by any  
outer join.  This deduction happens after we have generated multiple  
clones of the same qual condition to cope with commuted-left-join  
cases.  
  
However, performing the NullTest deduction for clone clauses can be  
unsafe, because we don't have a reliable way to determine if the input  
expression of a NullTest is non-nullable: nullingrel bits in clone  
clauses may not reflect reality, so we dare not draw conclusions from  
clones about whether Vars are guaranteed not-null.  
  
To fix, we check whether the given RestrictInfo is a clone clause in  
restriction_is_always_true and restriction_is_always_false, and avoid  
performing any reduction if it is.  
  
There are several ensuing plan changes in predicate.out, and we have  
to modify the tests to ensure that they continue to test what they are  
intended to.  Additionally, this fix causes the test case added in  
f00ab1fd1 to no longer trigger the bug that commit fixed, so we also  
remove that test case.  
  
Back-patch to v17 where this bug crept in.  
  
Reported-by: Ronald Cruz <cruz@rentec.com>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/f5320d3d-77af-4ce8-b9c3-4715ff33f213@rentec.com  
Backpatch-through: 17  

commit   : d6dd2a02bae0d67ff6fbd73068dc36d0b82fc14b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Mar 2025 12:43:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Mar 2025 12:43:29 -0500    

If a domain type has a default, adding a column of that type (without  
any explicit DEFAULT clause) failed to install the domain's default  
value in existing rows, instead leaving the new column null.  This  
is unexpected, and it used to work correctly before v11.  The cause  
is confusion in the atthasmissing mechanism about which default value  
to install: we'd only consider installing an explicitly-specified  
default, and then we'd decide that no table rewrite is needed.  
  
To fix, take the responsibility for filling attmissingval out of  
StoreAttrDefault, and instead put it into ATExecAddColumn's existing  
logic that derives the correct value to fill the new column with.  
Also, centralize the logic that determines the need for  
default-related table rewriting there, instead of spreading it over  
four or five places.  
  
In the back branches, we'll leave the attmissingval-filling code  
in StoreAttrDefault even though it's now dead, for fear that some  
extension may be depending on that functionality to exist there.  
A separate HEAD-only patch will clean up the now-useless code.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Author: jian he <jian.universality@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CACJufxHFssPvkP1we7WMhPD_1kwgbG52o=kQgL+TnVoX5LOyCQ@mail.gmail.com  
Backpatch-through: 13  

commit   : d69c781084f580c17e9acae607798469c7c2e44e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Mar 2025 14:22:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Mar 2025 14:22:56 -0500    

We had managed not to notice this simple oversight because none  
of our calls exercised the case --- until commit 8f427187d.  
That led to pg_dump crashing on any platform that uses this code  
(currently Cygwin and Mingw).  
  
Even though there's no immediate bug in the back branches, backpatch,  
because a non-POSIX-compliant strtof() substitute is trouble waiting  
to happen for extensions or future back-patches.  
  
Diagnosed-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/339b3902-4e98-4e31-a744-94e43b7b9292@gmail.com  
Backpatch-through: 13  

commit   : ee78823ff5f6243a588bbeaabaa4d00c03b973e4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Feb 2025 10:15:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Feb 2025 10:15:32 +0900    

The function in charge of freeing the memory from a result created by  
PQescapeIdentifier() has to be PQfreemem(), to ensure that both  
allocation and free come from libpq.  
  
One spot in pg_upgrade was not respecting that for pg_database's  
datlocale (daticulocale in v16) when the collation provider is libc (aka  
datlocale/daticulocale is NULL) with an allocation done using  
pg_strdup() and a free with PQfreemem().  The code is changed to always  
use PQescapeLiteral() when processing the input.  
  
Oversight in 9637badd9f92.  This commit is similar to 48e4ae9a0707 and  
5b94e2753439.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Co-authored-by: Ranier Vilela <ranier.vf@gmail.com>  
Discussion: https://postgr.es/m/Z601RQxTmIUohdkV@paquier.xyz  
Backpatch-through: 16  

commit   : f903d4da9276b3c44bb28ea705e7eff0e849f6a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2025 14:05:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2025 14:05:55 +0900    

The function in charge of freeing the memory from a result created by  
PQescapeIdentifier() has to be PQfreemem(), to ensure that both  
allocation and free come from libpq, but one spot in pg_amcheck was  
missing that.  
  
Oversight in b859d94c6389.  
  
Author: Ranier Vilela <ranier.vf@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Discussion: https://postgr.es/m/CAEudQArD_nKSnYCNUZiPPsJ2tNXgRmLbXGSOrH1vpOF_XtP0Vg@mail.gmail.com  
Discussion: https://postgr.es/m/CAEudQArbTWVSbxq608GRmXJjnNSQ0B6R7CSffNnj2hPWMUsRNg@mail.gmail.com  
Backpatch-through: 14  

commit   : 7c906c5b46f8189a04e67bc550cba33dd3851b6e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 Feb 2025 09:22:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 Feb 2025 09:22:16 +0530    

This commit documents that the failover option is not copied when using  
the pg_copy_logical_replication_slot function.  
  
In passing, we modify the comments in the function clarifying the reason  
for this behavior.  
  
Reported-by: <duffieldzane@gmail.com>  
Author: Hou Zhijie <houzj.fnst@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/173976850802.682632.11315364077431550250@wrigleys.postgresql.org  

commit   : 174952ece1c04b725a2eafabf08d7192b99866ca    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 24 Feb 2025 14:03:07 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 24 Feb 2025 14:03:07 -0800    

When a standby replays an XLOG_PARAMETER_CHANGE record that lowers  
wal_level below logical, we invalidate all logical slots in hot  
standby mode. However, if this record was replayed while not in hot  
standby mode, logical slots could remain valid even after promotion,  
potentially causing an assertion failure during WAL record decoding.  
  
To fix this issue, this commit adds a check for hot_standby status  
when restoring a logical replication slot on standbys. This check  
ensures that logical slots are invalidated when they become  
incompatible due to insufficient wal_level during recovery.  
  
Backpatch to v16 where logical decoding on standby was introduced.  
  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoABoFwGY_Rh2aeE6tEq3HkJxf0c6UeOXn4VV9v6BAQPSw%40mail.gmail.com  
Backpatch-through: 16  

commit   : fde7c0164ea20433964a0a05a91c5708384a285c    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Mon, 24 Feb 2025 18:03:29 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Mon, 24 Feb 2025 18:03:29 +0700    

Due to misunderstanding on my part, commit 235328ee4 did not go far  
enough to silence older versions of Valgrind. For those, it was the bit  
scan that was problematic, not the subsequent bit-masking operation. To  
fix, use the unaligned path for the trailing bytes. Since we don't have  
a bit scan here anymore, also remove some comments and endian-specific  
coding around that.  
  
Reported-by: Anton A. Melnikov <a.melnikov@postgrespro.ru>  
Discussion: https://postgr.es/m/f3aa2d45-3b28-41c5-9499-a1bc30e0f8ec@postgrespro.ru  
Backpatch-through: 17  

commit   : 16eff4261f46a4820ee628d160c53ab2a07eef49    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2025 13:37:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2025 13:37:12 -0500    

There is a race condition between "GRANT role" and "DROP ROLE",  
which allows GRANT to install pg_auth_members entries that refer to  
dropped roles.  (Commit 6566133c5 prevented that for the grantor  
field, but not for the granted or grantee roles.)  We'll soon fix  
that, at least in HEAD, but pg_dumpall needs to cope with the  
situation in case of pre-existing inconsistency.  As pg_dumpall  
stands, it will emit invalid commands like 'GRANT foo TO ""',  
which causes pg_upgrade to fail.  Fix it to emit warnings and skip  
those GRANTs, instead.  
  
There was some discussion of removing the problem by changing  
dumpRoleMembership's query to use JOIN not LEFT JOIN, but that  
would result in silently ignoring such entries.  It seems better  
to produce a warning.  
  
Pre-v16 branches already coped with dangling grantor OIDs by simply  
omitting the GRANTED BY clause.  I left that behavior as-is, although  
it's somewhat inconsistent with the behavior of later branches.  
  
Reported-by: Virender Singla <virender.cse@gmail.com>  
Discussion: https://postgr.es/m/CAM6Zo8woa62ZFHtMKox6a4jb8qQ=w87R2L0K8347iE-juQL2EA@mail.gmail.com  
Backpatch-through: 13  

commit   : 69c45eccea3b7d865321323813e57fe420c4757c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Feb 2025 13:03:29 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Feb 2025 13:03:29 -0500    

Also simplify and correct data checksum wording in master now that it is  
the default.  PG 13 did not have the awkward wording.  
  
Reported-by: Felix <afripowered@gmail.com>  
  
Reviewed-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/173928241056.707.3989867022954178032@wrigleys.postgresql.org  
  
Backpatch-through: 14  

commit   : 0f7c0fb59cb71e1ecd45c6892ab184fefbfde8be    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 21 Feb 2025 11:16:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 21 Feb 2025 11:16:57 -0500    

Previously the portlock logic, added in 9b4eafcaf41, didn't actually work  
properly when the tests were run via meson. 9b4eafcaf41 used the  
MESON_BUILD_ROOT environment variable to determine the directory for the port  
lock directory, but that's never set for running the tests.  That meant that  
each test used its own portlock dir, unless the PG_TEST_PORT_DIR environment  
variable was set.  
  
Fix the problem by setting top_builddir for the environment. That's also used  
for the autoconf/make build.  
  
Backpatch back to 16, where meson support was added.  
  
Reported-by: Zharkov Roman <r.zharkov@postgrespro.ru>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Backpatch-through: 16  

commit   : 310907aaf01053bbc00972a01438997b146b3fdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Feb 2025 20:37:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Feb 2025 20:37:36 +0900    

Dumps from versions older than v16 do not know about NO INDENT in a  
XMLSERIALIZE() clause.  This commit adjusts AdjustUpgrade.pm so as NO  
INDENT is discarded in the contents of the new dump adjusted for  
comparison when the old version is v15 or older.  This should be enough  
to make the cross-version upgrade tests pass.  
  
Per report from buildfarm member crake.  Oversight in 984410b92326.  
  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://postgr.es/m/88b183f1-ebf9-4f51-9144-3704380ccae7@dunslane.net  
Backpatch-through: 16  

commit   : 0ae1245e04ad7130238acf8cfb6d40c32fa1e588    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 Feb 2025 14:21:29 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 Feb 2025 14:21:29 +0530    

Previously, a WARNING was issued at the time of defining a subscription  
with origin=NONE only when the publisher subscribed to the same table from  
other publishers, indicating potential data origination from different  
origins. However, the publisher can subscribe to the partition ancestors  
or partition children of the table from other publishers, which could also  
result in mixed-origin data inclusion. So, give a WARNING in those cases  
as well.  
  
Reported-by: Sergey Tatarintsev <s.tatarintsev@postgrespro.ru>  
Author: Hou Zhijie <houzj.fnst@fujitsu.com>  
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16, where it was introduced  
Discussion: https://postgr.es/m/5eda6a9c-63cf-404d-8a49-8dcb116a29f3@postgrespro.ru  

commit   : 2e0f93d7cb09799bff498c604e875ac2e7a2b9dc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Feb 2025 17:31:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Feb 2025 17:31:01 +0900    

NO INDENT is the default, and is added if no explicit indentation  
flag was provided with XMLSERIALIZE().  
  
Oversight in 483bdb2afec9.  
  
Author: Jim Jones <jim.jones@uni-muenster.de>  
Discussion: https://postgr.es/m/bebd457e-5b43-46b3-8fc6-f6a6509483ba@uni-muenster.de  
Backpatch-through: 16  

commit   : 57dca6faa9bdfd3c2ad2805fc088dc768d36fcf0    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 15 Feb 2025 13:13:19 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 15 Feb 2025 13:13:19 +1300    

This is a back-patch of commits 2a8a0067 and 2509b857 into  
REL_17_STABLE.  It's doesn't fix any known live bug in PostgreSQL v17  
itself, but an extension could in theory have used the per-buffer data  
feature and seen spurious errors under Valgrind.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2Bg6aXpi2FEHqeLOzE%2BxYw%3DOV%2B-N5jhOEnnV%2BF0USM9xA%40mail.gmail.com  

commit   : 29cce279bbc5919b8a85fb1ebc71d24395b2451b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2025 10:43:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2025 10:43:35 +0900    

If the requested recovery timeline is not reachable, the logged  
checkpoint and timeline should to be the values read from the  
backup_label when it is defined.  The message generated used the values  
from the control file in this case, which is fine when recovering from  
the control file without a backup_label, but not if there is a  
backup_label.  
  
Issue introduced in ee994272ca50.  v15 has introduced xlogrecovery.c and  
more simplifications in this area (4a92a1c3d1c3, a27048cbcb58), making  
this change a bit simpler to think about, so backpatch only down to this  
version.  
  
Author: David Steele <david@pgbackrest.org>  
Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Benoit Lobréau <benoit.lobreau@dalibo.com>  
Discussion: https://postgr.es/m/c3d617d4-1696-4aa7-8a4d-5a7d19cc5618@pgbackrest.org  
Backpatch-through: 15  

commit   : e7f72185062ca1c76334e1d6de35ec17a2489234    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2025 09:31:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2025 09:31:01 +0900    

The short option name -f was not listed, only its long option name  
--force-unsupported.  
  
Author: Japin Li  
Discussion: https://postgr.es/m/ME0P300MB04452BD1FB1B277D4C1C20B9B6C52@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  
Backpatch-through: 13  

commit   : 587b6aa3f3cea5d30e65317c34d0cae288edaa6d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 19 Feb 2025 23:51:48 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 19 Feb 2025 23:51:48 +0100    

Since commit 29cf61ade3, table_block_relation_estimate_size() considers  
fillfactor when estimating number of rows in a relation before the first  
ANALYZE. The formula however did not consider tuples may be larger than  
available space determined by fillfactor, ending with density 0. This  
ultimately means the relation was estimated to contain a single row.  
  
The executor however places at least one tuple per page, even with very  
low fillfactor values, so the density should be at least 1. Fixed by  
clamping the density estimate using clamp_row_est().  
  
Reported by Heikki Linnakangas. Fix by me, with regression test inspired  
by example provided by Heikki.  
  
Backpatch to 17, where the issue was introduced.  
  
Reported-by: Heikki Linnakangas  
Backpatch-through: 17  
Discussion: https://postgr.es/m/2bf9d973-7789-4937-a7ca-0af9fb49c71e@iki.fi  

commit   : 788baa9a25ae83b576621166367c868d3329b4d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2025 16:35:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Feb 2025 16:35:15 -0500    

Logical replication crashes if the subscriber's partitioned table  
has a BRIN index.  There are two independently blamable causes,  
and this patch fixes both:  
  
1. brininsertcleanup fails if called twice for the same IndexInfo,  
because it half-destroys its BrinInsertState but leaves it still  
linked from ii_AmCache.  brininsert would also fail in that state,  
so it's pretty hard to see any advantage to this coding.  Fully  
remove the BrinInsertState, instead, so that a new brininsert  
call would create a new cache.  
  
2. A logical replication subscriber sometimes does ExecOpenIndices  
twice on the same ResultRelInfo, followed by doing ExecCloseIndices  
twice; the second call reaches the brininsertcleanup bug.  Quite  
aside from tickling unexpected cases in aminsertcleanup methods,  
this seems very wasteful, because the IndexInfos built in the  
first ExecOpenIndices call are just lost during the second call,  
and have to be rebuilt at possibly-nontrivial cost.  We should  
establish a coding rule that you don't do that.  
  
The problematic coding is that when the target table is partitioned,  
apply_handle_tuple_routing calls ExecFindPartition which does  
ExecOpenIndices (and expects that ExecCleanupTupleRouting will  
close the indexes again).  Using the ResultRelInfo made by  
ExecFindPartition, it calls apply_handle_delete_internal or  
apply_handle_insert_internal, both of which think they need to do  
ExecOpenIndices/ExecCloseIndices for themselves.  They do in the main  
non-partitioned code paths, but not here.  The simplest fix is to pull  
their ExecOpenIndices/ExecCloseIndices calls out and put them in the  
call sites for the non-partitioned cases.  (We could have refactored  
apply_handle_update_internal similarly, but I did not do so today  
because there's no bug there: the partitioned code path doesn't  
call it.)  
  
Also, remove the always-duplicative open/close calls within  
apply_handle_tuple_routing itself.  
  
Since brininsertcleanup and indeed the whole aminsertcleanup mechanism  
are new in v17, there's no observable bug in older branches.  A case  
could be made for trying to avoid these duplicative open/close calls  
in the older branches, but for now it seems not worth the trouble and  
risk of new bugs.  
  
Bug: #18815  
Reported-by: Sergey Belyashov <sergey.belyashov@gmail.com>  
Discussion: https://postgr.es/m/18815-2a0407cc7f40b327@postgresql.org  
Backpatch-through: 17  

commit   : f61769adaa6214a01d087ab71ece8d170cda072f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Feb 2025 10:45:48 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Feb 2025 10:45:48 -0500    

This addresses various corner cases in BackgroundPsql:  
  
- On windows stdout and stderr may arrive out of order, leading to errors not  
  being reported, or attributed to the wrong statement.  
  
  To fix, emit the "query-separation banner" on both stdout and stderr and  
  wait for both.  
  
- Very occasionally the "query-separation banner" would not get removed, because  
  we waited until the banner arrived, but then replaced the banner plus  
  newline.  
  
  To fix, wait for banner and newline.  
  
- For interactive psql replacing $banner\n is not sufficient, interactive psql  
  outputs \r\n.  
  
- For interactive psql, where commands are echoed to stdout, the \echo  
  command, rather than its output, would be matched.  
  
  This would sometimes lead to output from the prior query, or wait_connect(),  
  being returned in the next command.  
  
  This also affected wait_connect(), leading to sometimes sending queries to  
  psql before the connection actually was established.  
  
While debugging these issues I also found that it's hard to know whether a  
query separation banner was attributed to the right query. Make that easier by  
counting the queries each BackgroundPsql instance has emitted and include the  
number in the banner.  
  
Also emit psql stdout/stderr in query() and wait_connect() as Test::More  
notes, without that it's rather hard to debug some issues in CI and buildfarm.  
  
As this can cause issues not just to-be-added tests, but also existing ones,  
backpatch the fix to all supported versions.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/wmovm6xcbwh7twdtymxuboaoarbvwj2haasd3sikzlb3dkgz76@n45rzycluzft  
Backpatch-through: 13  

commit   : 49b6f4a02b2339aac288cf3d363a4e1e9777b5c6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Feb 2025 09:41:08 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Feb 2025 09:41:08 -0500    

This is a backport of ba08edb0654. Originally it was only applied to master,  
but I (Andres) am planning to fix a few bugs in BackgroundPsql, which would be  
somewhat harder with the behavioural differences across branches. It's also  
generally good for test infrastructure to behave similarly across branches, to  
avoid pain during backpatching.  
  
Discussion: https://postgr.es/m/ilcctzb5ju2gulvnadjmhgatnkxsdpac652byb2u3d3wqziyvx@fbuqcglker46  
  
Michael's original commit message:  
  
This commit extends the constructor routine of BackgroundPsql.pm with a  
new "wait" parameter.  If set to 0, the routine returns without waiting  
for psql to start, ready to consume input.  
  
background_psql() in Cluster.pm gains the same "wait" parameter.  The  
default behavior is still to wait for psql to start.  It becomes now  
possible to not wait, giving to TAP scripts the possibility to perform  
actions between a BackgroundPsql startup and its wait_connect() call.  
  
Author: Jacob Champion  
Discussion: https://postgr.es/m/CAOYmi+=60deN20WDyCoHCiecgivJxr=98s7s7-C8SkXwrCfHXg@mail.gmail.com  

commit   : 31a242e90c8857c0e79e76e324a84f935d3cfedf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Feb 2025 09:39:49 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 19 Feb 2025 09:39:49 -0500    

This is a backport of 70291a3c66e. Originally it was only applied to master,  
but I (Andres) am planning to fix a few bugs in BackgroundPsql that are harder  
to fix in the backbranches with the old behavior. It's also generally good for  
test infrastructure to behave similarly across branches, to avoid pain during  
backpatching.  70291a3c66e changes the behavior in some cases, but after  
discussing it, we are ok with that, it seems unlikely that there are  
out-of-core tests relying on the prior behavior.  
  
Discussion: https://postgr.es/m/ilcctzb5ju2gulvnadjmhgatnkxsdpac652byb2u3d3wqziyvx@fbuqcglker46  
  
Michael's original commit message:  
  
A newline is not added at the end of an empty query result, causing the  
banner of the hardcoded \echo to not be discarded.  This would reflect  
on scripts that expect an empty result by showing the "QUERY_SEPARATOR"  
in the output returned back to the caller, which was confusing.  
  
This commit changes BackgroundPsql::query() so as empty results are able  
to work correctly, making the first newline before the banner optional,  
bringing more flexibility.  
  
Note that this change affects 037_invalid_database.pl, where three  
queries generated an empty result, with the script relying on the data  
from the hardcoded banner to exist in the expected output.  These  
queries are changed to use query_safe(), leading to a simpler script.  
  
The author has also proposed a test in a different patch where empty  
results would exist when using BackgroundPsql.  
  
Author: Jacob Champion  
Reviewed-by: Andrew Dunstan, Michael Paquier  
Discussion: https://postgr.es/m/CAOYmi+=60deN20WDyCoHCiecgivJxr=98s7s7-C8SkXwrCfHXg@mail.gmail.com  

commit   : 77cdee9ea905f32c5c93d1505ec85db3ecea5dd4    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Wed, 19 Feb 2025 15:07:24 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Wed, 19 Feb 2025 15:07:24 +0900    

 1. Remove an unused PASSING variable.  
  
 2. Adjust formatting of JSON data used in an example to be valid  
    under strict mode  
  
Reported-by: Miłosz Chmura <mieszko4@gmail.com>  
Author: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/173859550337.1071.4748984213168572913@wrigleys.postgresql.org  

commit   : 7edd2cbc535cc093abc84ccc5764d794609e1473    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Feb 2025 21:23:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Feb 2025 21:23:59 -0500    

Absorb upstream bug fix (their commit  
e322673a841d9abd69994ae8cd20e191090b6ef4), which prevents a null  
pointer dereference crash if SN_create_env() gets a malloc failure  
at just the wrong point.  
  
Thanks to Maksim Korotkov for discovering the null-pointer  
bug and submitting the fix to upstream snowball.  
  
Reported-by: Maksim Korotkov <m.korotkov@postgrespro.ru>  
Author: Maksim Korotkov <m.korotkov@postgrespro.ru>  
Discussion: https://postgr.es/m/1d1a46-67ab1000-21-80c451@83151435  
Backpatch-through: 13  

commit   : 49a450892a3e65619287c099d4b2493ae61aea9b    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 19 Feb 2025 11:05:35 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 19 Feb 2025 11:05:35 +0900    

When considering a local buffer, the GetBufferDescriptor() call in  
BufferGetLSNAtomic() would be retrieving a shared buffer with a bad  
buffer ID.  Since the code checks whether the buffer is shared before  
using the retrieved BufferDesc, this issue did not lead to any  
malfunction.  Nonetheless this seems like trouble waiting to happen,  
so fix it by ensuring that GetBufferDescriptor() is only called when  
we know the buffer is shared.  
  
Author: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAHewXNku-o46-9cmUgyv6LkSZ25doDrWq32p=oz9kfD8ovVJMg@mail.gmail.com  
Backpatch-through: 13  

commit   : 727bc6ac33f63245167b34e553c452c65c7c6d7d    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 19 Feb 2025 10:04:44 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 19 Feb 2025 10:04:44 +0900    

In try_partitionwise_join, we try to break down the join between two  
partitioned relations into joins between matching partitions.  To  
achieve this, we iterate through each pair of partitions from the two  
joining relations and create child join relations for them.  To reduce  
memory accumulation during each iteration, one step we take is freeing  
the SpecialJoinInfos created for the child joins.  
  
A child join's SpecialJoinInfo is a copy of the parent join's  
SpecialJoinInfo, with some members being translated copies of their  
counterparts in the parent.  However, when freeing the bitmapset  
members in a child join's SpecialJoinInfo, we failed to check whether  
they were translated copies.  As a result, we inadvertently freed the  
members that were still in use by the parent SpecialJoinInfo, leading  
to crashes when those freed members were accessed.  
  
To fix, check if each member of the child join's SpecialJoinInfo is a  
translated copy and free it only if that's the case.  This requires  
passing the parent join's SpecialJoinInfo as a parameter to  
free_child_join_sjinfo.  
  
Back-patch to v17 where this bug crept in.  
  
Bug: #18806  
Reported-by: 孟令彬 <m_lingbin@126.com>  
Diagnosed-by: Tender Wang <tndrwang@gmail.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/18806-d70b0c9fdf63dcbf@postgresql.org  
Backpatch-through: 17  

commit   : a68a7594ca3adc22899a5d06629fb2d0fa6724bc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Feb 2025 09:45:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Feb 2025 09:45:54 +0900    

This addresses two errors in the module, based on the set of options  
supported:  
- '-c', for --conninfo, was not listed.  
- '-f', for --force-unsupported, was not listed.  
  
While on it, these are now listed in an alphabetical order.  
  
Author: Japin Li  
Discussion: https://postgr.es/m/ME0P300MB04451FB20CE0346A59C25CADB6FA2@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  
Backpatch-through: 13