PostgreSQL 14.18 commit log

commit   : 8bde80e30edd408a5bef4d5612db0bb173206293    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2025 16:33:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2025 16:33:27 -0400    

commit   : d9cee6a5f2ad73e1c13b619fdc2d42961079dbc3    
  
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   : 3f2ab73934ab1e27151ecd14fd7d8ef602555093    
  
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   : 258cde839d902ad9dd41cbd7ab58ebf4ba086874    
  
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   : 9dcd8c723c6d0bdf40d408cce83472c527212ac4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 May 2025 12:22:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 May 2025 12:22:42 +0200    

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

commit   : 2b2a1f7573e46f37e7654afe0385bcb9acfa738d    
  
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   : 1649d153a1729dd09d1e9af79b3868d1892b11ac    
  
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   : 16f911ced6bdc368c41865c0a2250462a69a4e66    
  
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   : 715241d71fa12a3864ea8c465745025030efdb90    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 May 2025 17:36:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 May 2025 17:36:47 -0400    

While back-patching 9f45e6a91, I neglected that the convention in  
pre-v16 libpq was to include a trailing newline in error message  
strings (since then, we add those separately).  Add them now.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/a9c837ad-d507-4607-94e4-c5743a8f49e0@eisentraut.org  
Backpatch-through: 13-15  

commit   : 1ba9ffa56eb510b8d9ae57431ad61a9e1a396674    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 1 May 2025 11:09:24 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 1 May 2025 11:09:24 +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   : 7be51eb4e169672d2029d955cb776e2252e6b7d3    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 20:36:23 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 30 Apr 2025 20:36:23 +0200    

Clear any potential stale next_phase_at value from the snapshot  
builder which otherwise may trip an assertion check ensuring  
that there is no next_phase_at value.  
  
This can be reproduced by running 80 concurrent sessions like  
the below where $c is a loop counter (assumes there has been  
1..$c databases created) :  
  
  echo "  
    CREATE TABLE replication_example(id SERIAL PRIMARY KEY,  
                                     somedata int,  
                                     text varchar(120));  
    SELECT 'init' FROM  
      pg_create_logical_replication_slot('regression_slot_$c',  
                                         'test_decoding');  
    SELECT data FROM  
      pg_logical_slot_get_changes('regression_slot_$c', NULL,  
                                  NULL, 'include-xids', '0',  
                                  'skip-empty-xacts', '1');  
  " | psql -d regress_$c >>psql.log &  
  
This was originally committed as 48efb23 and backpatched down to  
v16, but since then there have been reports of this happening on  
v14 and v15 as well so this is a backpatch of 48efb23 down to 14.  
  
Bug: #17695  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Reported-by: bowenshi <zxwsbg@qq.com>  
Reported-by: Alexander Pyhalov <a.pyhalov@postgrespro.ru>  
Reported-by: Teja Mupparti  
Discussion: https://postgr.es/m/17695-6be9277c9295985f@postgresql.org  
Backpatch-through: v14  

commit   : fa4244a43a3776e7795b08d669f5d96d0ae93410    
  
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   : 1f63b3626a52e596398c7a04a42081a773b12d76    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Apr 2025 10:34:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Apr 2025 10:34:45 +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   : bb1bc9fa962ed72a521ee129c20c089f9d507f97    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Apr 2025 11:53:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Apr 2025 11:53:27 +0530    

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

commit   : 442c992e9586c3e33d9fc2bf20c73b8c625a1129    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 14:57:45 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 22 Apr 2025 14:57:45 +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   : 41ffd9d6a72486efb182c4f937866cf6e069a8ec    
  
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   : a61b67cd06c283d51cc833b4d1b990e6519836d8    
  
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   : 3c2ea65bd85f16d563f896398251dd1337fc5856    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Apr 2025 16:37:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Apr 2025 16:37:43 -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   : 148cc0105dce93b52fe9e801f51ae0e3fbf96af1    
  
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   : 4604928edd7236587fcd27ee2ecc0c33124cbbfe    
  
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   : 1b47a112ac41b6414eadebcb3d5f3908bf440565    
  
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   : 873aff945a7b9f8417ef84f66f36f2631b1c5047    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Apr 2025 10:02:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Apr 2025 10:02:20 +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   : 95e83859b94eca33d3b236c8c8de9e81513e4a12    
  
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   : 0434033e8bb535dd809e97c24202be5ef620aaff    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 10 Apr 2025 12:22:30 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 10 Apr 2025 12:22:30 +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   : 115f45e9af4db0939bdb9ff9391916a4226f8b57    
  
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   : 3635a0a35aafd3bfa80b7a809bc6e91ccd36606a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 15 Sep 2022 06:45:23 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Sep 2022 06:45:23 -0700    

After commit cc2c7d65fc27e877c9f407587b0b92d46cd6dd16 added this flag,  
failure to reset it caused assertion failures.  In non-assert builds, it  
made the system fail to achieve the objectives listed in that commit;  
chiefly, we might emit a spurious log message.  Back-patch to v15, where  
that commit first appeared.  
  
Bharath Rupireddy and Kyotaro Horiguchi.  Reviewed by Dilip Kumar,  
Nathan Bossart and Michael Paquier.  Reported by Dilip Kumar.  
  
This commit has been applied as of b4f584f9d2a1 in v15 and newer  
versions.  This is required on stable branches of v13 and v14 to fix a  
regression reported by Noah Misch, introduced by 1f95181b44c8, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The backpatched versions of  
the patches have been aligned on these branches by me.  Tests have been  
conducted by the both of us.  
  
Discussion: https://postgr.es/m/CAFiTN-sE3ry=ycMPVtC+Djw4Fd7gbUGVv_qqw6qfzp=JLvqT3g@mail.gmail.com  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 014a508009dfa60c685410a870e471c4486a6d58    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    

The previous commit addressed the chief consequences of a race condition  
between InstallXLogFileSegment() and KeepFileRestoredFromArchive().  Fix  
three lesser consequences.  A spurious durable_rename_excl() LOG message  
remained possible.  KeepFileRestoredFromArchive() wasted the proceeds of  
WAL recycling and preallocation.  Finally, XLogFileInitInternal() could  
return a descriptor for a file that KeepFileRestoredFromArchive() had  
already unlinked.  That felt like a recipe for future bugs.  
  
This commit has been applied as of cc2c7d65fc27 in v15 and newer  
versions.  This is required on stable branches of v13 and v14 to fix a  
regression reported by Noah Misch, introduced by 1f95181b44c8, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The backpatched versions of  
the patches have been aligned on these branches by me, Noah Misch is the  
author.  Tests have been conducted by the both of us.  
  
Note that this commit is known to have introduced a regression of its  
own.  This is fixed by the commit following this one, and not grouped in  
a single commit to keep the commit history consistent across all  
branches.  
  
Reported-by: Arun Thirupathi  
Author: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 675b771ca5f28bb38cf14151fb30ac28f2e1ca4b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    

Before a restartpoint finishes PreallocXlogFiles(), a startup process  
KeepFileRestoredFromArchive() call can unlink the preallocated segment.  
If a CHECKPOINT sql command had elicited the restartpoint experiencing  
the race condition, that sql command failed.  Moreover, the restartpoint  
omitted its log_checkpoints message and some inessential resource  
reclamation.  Prevent the ERROR by skipping open() of the segment.  
Since these consequences are so minor, no back-patch.  
  
This commit has been applied as of 2b3e4672f760 in v15 and newer  
versions.  This is required on stable branches of v13 and v14 to fix a  
regression reported by Noah Misch, introduced by 1f95181b44c8, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The backpatched versions of  
the patches have been aligned on these branches by me, Noah Misch is the  
author.  Tests have been conducted by the both of us.  
  
Reported-by: Arun Thirupathi  
Author: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 47d2d29827293ed46f3641d8843ce5b5823d26e4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 6 Apr 2025 15:14:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 6 Apr 2025 15:14:52 +0900    

This reverts commit 8ad6c5dbbe5a, which was a commit specific to v14 and  
older branches as the race condition between restartpoints and  
KeepFileRestoredFromArchive() still existed.  
  
1f95181b44c8 has worsened the situation on these two branches, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The same logic as v15 and  
newer versions will be applied in some follow-up commits to close this  
problem, making this HINT not necessary anymore.  
  
Reported-by: Arun Thirupathi  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : b494640e8297db8b626d8ffa775cb491f7d2e7e2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    

Only initdb used it.  initdb refuses to operate on a non-empty directory  
and generally does not cope with pre-existing files of other kinds.  
Hence, use the opportunity to simplify.  
  
This commit has been applied as of 421484f79c0b in v15 and newer  
versions.  This is required on stable branches of v13 and v14 to fix a  
regression reported by Noah Misch, introduced by 1f95181b44c8, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The backpatched versions of  
the patches have been aligned on these branches by me, Noah Misch is the  
author.  Tests have been conducted by the both of us.  
  
Reported-by: Arun Thirupathi  
Author: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 8967dddf086e81b0b5ee84a197cc2773f73e131a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    

Infrequently, the mismatch caused log_checkpoints messages and  
TRACE_POSTGRESQL_CHECKPOINT_DONE() to witness an "added" count too high  
by one.  Since that consequence is so minor, no back-patch.  
  
This commit has been applied as of 85656bc3050f in v15 and newer  
versions.  This is required on stable branches of v13 and v14 to fix a  
regression reported by Noah Misch, introduced by 1f95181b44c8, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The backpatched versions of  
the patches have been aligned on these branches by me, Noah Misch is the  
author.  Tests have been conducted by the both of us.  
  
Reported-by: Arun Thirupathi  
Author: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 6b168c1299c5da486c653e2456a87841d24b1ea7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    

Cold paths, initdb and end-of-recovery, used it.  Don't optimize them.  
  
This commit has been applied as of c53c6b98d38a in v15 and newer  
versions.  This is required on stable branches of v13 and v14 to fix a  
regression reported by Noah Misch, introduced by 1f95181b44c8, causing  
spurious failures in archive recovery (neither streaming nor archive  
recovery) with concurrent restartpoints.  The backpatched versions of  
the patches have been aligned on these branches by me, Noah Misch is the  
author.  Tests have been conducted by the both of us.  
  
Reported-by: Arun Thirupathi  
Author: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  
Discussion: https://postgr.es/m/20250306193013.36.nmisch@google.com  
Backpatch-through: 13  

commit   : 754a3d82d79cc3d7040cfadaf9c8cd1579684ee6    
  
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   : a749c6f18fbacd05f432cd29f9e7294033bc666f    
  
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   : d4fe7437e53659c111db4e7602a017bd5dffefc8    
  
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   : 0d22daad7e1a5abd16795590da54015aefb94848    
  
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   : a8a9189376af5be5afab2a086fd9a9d25b23b07c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Jan 2024 11:39:56 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Jan 2024 11:39:56 -0800    

This replaces dblink's blocking libpq calls, allowing cancellation and  
allowing DROP DATABASE (of a database not involved in the query).  Apart  
from explicit dblink_cancel_query() calls, dblink still doesn't cancel  
the remote side.  The replacement for the blocking calls consists of  
new, general-purpose query execution wrappers in the libpqsrv facility.  
Out-of-tree extensions should adopt these.  
  
The original commit d3c5f37dd543498cc7c678815d3921823beec9e9 did not  
back-patch.  Back-patch now to v16-v13, bringing coverage to all supported  
versions.  This back-patch omits the orignal's refactoring in postgres_fdw.  
  
Discussion: https://postgr.es/m/20231122012945.74@rfd.leadboat.com  

commit   : aa435d7c42a09f7019805d1cf87eb64545efe1bc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    

Currently dblink and postgres_fdw don't process interrupts during connection  
establishment. Besides preventing query cancellations etc, this can lead to  
undetected deadlocks, as global barriers are not processed.  
  
Libpqwalreceiver in contrast, processes interrupts during connection  
establishment. The required code is not trivial, so duplicating it into  
additional places does not seem like a good option.  
  
These aforementioned undetected deadlocks are the reason for the spate of CI  
test failures in the FreeBSD 'test_running' step.  
  
For now the helper library is just a header, as it needs to be linked into  
each extension using libpq, and it seems too small to be worth adding a  
dedicated static library for.  
  
The conversion to the helper are done in subsequent commits.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de  

commit   : be625caf3dad63bae39296b553fc8f856d7fb9b7    
  
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   : 4934d38759cdb65965db4ccf10aa767d9bee5e00    
  
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   : d31d39cfe4f5f357c5ebf986efec61021cdf729d    
  
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   : d501e7ba5e50b86a3769595d5cfbfea281312af6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 14:04:53 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 14:04:53 +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   : b68f664bb024330d33983b1e1f59f483bdd3aca1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 11:58:37 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Apr 2025 11:58:37 +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   : 71790aef1a6eea6f9662a1edcd669d89d5486b03    
  
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   : 5ff827389e7739c05888218bd9cd123f0b9b3122    
  
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   : b209856b6224ae9516e49690eb49101b4309846a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Mar 2025 10:20:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Mar 2025 10:20:49 +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   : 6be02bbc884b1dd0e0791fc7c7d8280eb2078fce    
  
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   : 66235baab72b22456c88a28db788048b52712100    
  
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   : c196c610b3391209ad43db22905ef5725dad559c    
  
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   : ae0696ed32316d0c0a82d55fd54a21c9947bb181    
  
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   : f7ae51312f3d5366ab958c43239ca142aeb11a70    
  
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   : 1a20bc94623e6ee5041713fc66b7f803832f0bba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2025 12:13:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2025 12:13:07 -0400    

Letting the rewriter keep RangeTblEntry.relid when expanding a view  
RTE, without making the outfuncs/readfuncs changes that went along  
with that originally, is more problematic than I realized.  It causes  
WRITE_READ_PARSE_PLAN_TREES testing to fail because outfuncs/readfuncs  
don't think relid need be saved in an RTE_SUBQUERY RTE.  
  
There doesn't seem to be any other good route to fixing the whole-row  
Var problem solved at f4e7756ef, so we just have to deal with the  
consequences.  We can make the eventually-produced plan tree safe  
for WRITE_READ_PARSE_PLAN_TREES by clearing the relid field at the  
end of planning, as was already being done for the functions field.  
(The functions field is not problematic here because our abuse of it  
is strictly local to the planner.)  However, there is no nice fix for  
the post-rewrite WRITE_READ_PARSE_PLAN_TREES test.  
  
The solution adopted here is to remove the post-rewrite test in the  
affected branches.  That's surely less than ideal, but a couple of  
arguments can be made why it's not unacceptable.  First, the behavior  
of outfuncs/readfuncs for parsetrees in these branches is frozen no  
matter what, because of catalog stability requirements.  So we're not  
testing anything that is going to change.  Second, testing  
WRITE_READ_PARSE_PLAN_TREES at this particular time doesn't correspond  
to any direct system functionality requirement, neither rule storage  
nor plan transmission.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
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-15  

commit   : d2fb076bec06dafd6922669eed826191c01fa9c6    
  
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   : d3a29ae6a60cba3d971cd184d477af8d17f157ee    
  
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   : 584f17a9063ee63aa472705bfac1bed95e3e2194    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Mar 2025 11:28:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Mar 2025 11:28:04 -0400    

When the rewriter converts an RTE_RELATION RTE for a view into  
an RTE_SUBQUERY RTE containing the view's defining query, leave  
the relid field alone instead of zeroing it.  This allows the  
planner to tell that the subquery came from a view rather than  
having been written in-line, which is needed to support an  
upcoming planner bug fix.  We cannot change the behavior of the  
outfuncs/readfuncs code in released branches, so the relid field  
will not survive in plans passed to parallel workers; therefore  
this info should not be relied on in the executor.  
  
This back-patches a portion of the data structure definitional  
changes made in v16 and up by commit 47bb9db75.  It's being  
committed separately for visibility in the commit log, but  
with luck it will not actually matter to anyone.  While it's  
not inconceivable that this change will break code expecting  
relid to be zero in a subquery RTE, we can hope that such code  
has already been adjusted to cope with v16 and up.  
  
Reported-by: Duncan Sands <duncan.sands@deepbluecap.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-15  

commit   : 5144e1f8fddeab4b3a6fec5d2b734402f1a5462b    
  
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   : 136e68b465c151fa832d8bb20beea1a1a9c22252    
  
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   : 2ef048855fdc770302a2c5897c6bbeef8af4ad62    
  
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   : e7d29d1fac822d5a3dc2f7fafa5bd80a742f27af    
  
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   : da85544ae53f8eb86dcf0e50e3df2aa9068ca38a    
  
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   : be342766fb02b55d91166386affa8607b1da842e    
  
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   : e2a6934a8855bc4c8421412bc4d9495de0753ab5    
  
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   : 33b02bfac4777a80151a564d751651c6efba002a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Mar 2025 08:45:35 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Mar 2025 08:45:35 -0500    

In newer glibc versions two additional functions appear between  
send() and socketcall.send(msg):  
   fun:__internal_syscall_cancel  
   fun:__syscall_cancel  
Due to that our existing suppression do not work anymore.  
  
Use '...', like aleady used in other suppressions, to make valgrind ignore  
these interstitial frames.  
  
The problematic suppressions are only in < 15, as they aren't needed after  
5891c7a8ed8.  
  
Discussion: https://postgr.es/m/d7pyc6wbo2rqhfk24lsgz37766n75vty4jxy5dnppny7ezd4qc@56juadvntebw  
Backpatch-through: 13  

commit   : 931a1c0237901c68e6d57227fb1368178665c794    
  
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   : c75c830e23929141b80b0f13612f2796254bd27d    
  
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   : 76fbb38ef69c9210b4ba839b541f7f307817294f    
  
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   : 35a591a0486fb5527b11ff1878f0ccaa0e672676    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2025 14:06:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Feb 2025 14:06:00 +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   : ce1475acd5e2d328b50f2544506f56e5e74fa72c    
  
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   : b91326f372386aa8d4639f3891487cc5a87808be    
  
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   : cecbb131e5ebe5ffa91c9560dd3698fe5867e4df    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2025 09:31:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Feb 2025 09:31:06 +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   : c21ebcca7965f29105276682ba236c2868f53d12    
  
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   : 7c07ab62aeb7e8c4c24a5ff85e5c2a3416f257e7    
  
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   : 3170aece14b8ddd2290a97f5c448c70dc4bdde67    
  
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   : 8388cae5526b39dea40e35c14b7bc93cae5cb321    
  
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   : 07a55093cd2e80be5fb54c867208ef6c52bd00ce    
  
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   : 691c32ba4b194abf590ecf58baea46349f59f109    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Feb 2025 09:45:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Feb 2025 09:45:59 +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