PostgreSQL 15.0 (upcoming) commit log

commit   : 4729d1e8aab90bc5861a4ff01fc306ebf1bec433    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 14:26:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 14:26:34 -0400    

The idea of EvalPlanQual is that we replace the query's scan of the  
result relation with a single injected tuple, and see if we get a  
tuple out, thereby implying that the injected tuple still passes the  
query quals.  (In join cases, other relations in the query are still  
scanned normally.)  This logic was not updated when commit 86dc90056  
made it possible for a single DML query plan to have multiple result  
relations, when the query target relation has inheritance or partition  
children.  We replaced the output for the current result relation  
successfully, but other result relations were still scanned normally;  
thus, if any other result relation contained a tuple satisfying the  
quals, we'd think the EPQ check passed, even if it did not pass for  
the injected tuple itself.  This would lead to update or delete  
actions getting performed when they should have been skipped due to  
a conflicting concurrent update in READ COMMITTED isolation mode.  
  
Fix by blocking all sibling result relations from emitting tuples  
during an EvalPlanQual recheck.  In the back branches, the fix is  
complicated a bit by the need to not change the size of struct  
EPQState (else we'd have ABI-breaking changes in offsets in  
struct ModifyTableState).  Like the back-patches of 3f7836ff6  
and 4b3e37993, add a separately palloc'd struct to avoid that.  
The logic is the same as in HEAD otherwise.  
  
This is only a live bug back to v14 where 86dc90056 came in.  
However, I chose to back-patch the test cases further, on the  
grounds that this whole area is none too well tested.  I skipped  
doing so in v11 though because none of the test applied cleanly,  
and it didn't quite seem worth extra work for a branch with only  
six months to live.  
  
Per report from Ante Krešić (via Aleksander Alekseev)  
  
Discussion: https://postgr.es/m/CAJ7c6TMBTN3rcz4=AjYhLPD_w3FFT0Wq_C15jxCDn8U4tZnH1g@mail.gmail.com  

commit   : 89f5eb26f6b9b2739aacf53676bfa0eee7be421a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 10:57:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 10:57:46 -0400    

Commits 681d9e462 et al added a test case in namespace.sql that  
implicitly relied on there not being a table "public.abc".  
However, the concurrently-run transactions.sql test creates precisely  
such a table, so with the right timing you'd get a failure.  
Creating a table named as generically as "abc" in a common schema  
seems like bad practice, so fix this by changing the name of  
transactions.sql's table.  (Compare 2cf8c7aa4.)  
  
Marina Polyakova  
  
Discussion: https://postgr.es/m/80d0201636665d82185942e7112257b4@postgrespro.ru  

commit   : 2dd77822178807f3da988e1d873777685d9f7504    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 May 2023 12:38:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 May 2023 12:38:15 +0900    

Non-leaf pages of GiST indexes contain key attributes, leaf pages  
contain both key and non-key attributes, and gist_page_items() ignored  
the handling of non-key attributes.  This caused a few problems when  
using gist_page_items() on a GiST index with INCLUDE:  
- On a non-leaf page, the function would crash.  
- On a leaf page, the function would work, but miss to display all the  
values for included attributes.  
  
This commit fixes gist_page_items() to handle such cases in a more  
appropriate way, and now displays the values of key and non-key  
attributes for each item separately in a style consistent with what  
ruleutils.c would generate for the attribute list, depending on the page  
type dealt with.  In a way similar to how a record is displayed, values  
would be double-quoted for key or non-key attributes if required.  
  
ruleutils.c did not provide a routine able to control if non-key  
attributes should be displayed, so an extended() routine for index  
definitions is added to work around the leaf and non-leaf page  
differences.  
  
While on it, this commit fixes a third problem related to the amount of  
data reported for key attributes.  The code originally relied on  
BuildIndexValueDescription() (used for error reports on constraints)  
that would not print all the data stored in the index but the index  
opclass's input type, so this limited the amount of information  
available.  This switch makes gist_page_items() much cheaper as there is  
no need to run ACL checks for each item printed, which is not an issue  
anyway as superuser rights are required to execute the functions of  
pageinspect.  Opclasses whose data cannot be displayed can rely on  
gist_page_items_bytea().  
  
The documentation of this function was slightly incorrect for the  
output results generated on HEAD and v15, so adjust it on these  
branches.  
  
Author: Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org  
Backpatch-through: 14  

commit   : e187693239ad99fcfa368811f51fcf8af7428082    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 00:00:22 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 00:00:22 +0200    

BRIN indexes did not properly distinguish between summaries for empty  
(no rows) and all-NULL ranges, treating them as essentially the same  
thing. Summaries were initialized with allnulls=true, and opclasses  
simply reset allnulls to false when processing the first non-NULL value.  
This however produces incorrect results if the range starts with a NULL  
value (or a sequence of NULL values), in which case we forget the range  
contains NULL values when adding the first non-NULL value.  
  
This happens because the allnulls flag is used for two separate  
purposes - to mark empty ranges (not representing any rows yet) and  
ranges containing only NULL values.  
  
Opclasses don't know which of these cases it is, and so don't know  
whether to set hasnulls=true. Setting the flag in both cases would make  
it correct, but it would also make BRIN indexes useless for queries with  
IS NULL clauses. All ranges start empty (and thus allnulls=true), so all  
ranges would end up with either allnulls=true or hasnulls=true.  
  
The severity of the issue is somewhat reduced by the fact that it only  
happens when adding values to an existing summary with allnulls=true.  
This can happen e.g. for small tables (because a summary for the first  
range exists for all BRIN indexes), or for tables with large fraction of  
NULL values in the indexed columns.  
  
Bulk summarization (e.g. during CREATE INDEX or automatic summarization)  
that processes all values at once is not affected by this issue. In this  
case the flags were updated in a slightly different way, not forgetting  
the NULL values.  
  
To identify empty ranges we use a new flag, stored in an unused bit in  
the BRIN tuple header so the on-disk format remains the same. A matching  
flag is added to BrinMemTuple, into a 3B gap after bt_placeholder.  
That means there's no risk of ABI breakage, although we don't actually  
pass the BrinMemTuple to any public API.  
  
We could also skip storing index tuples for empty summaries, but then  
we'd have to always process such ranges - even if there are no rows in  
large parts of the table (e.g. after a bulk DELETE), it would still  
require reading the pages etc. So we store them, but ignore them when  
building the bitmap.  
  
Backpatch to 11. The issue exists since BRIN indexes were introduced in  
9.5, but older releases are already EOL.  
  
Backpatch-through: 11  
Reviewed-by: Justin Pryzby, Matthias van de Meent, Alvaro Herrera  
Discussion: https://postgr.es/m/402430e4-7d9d-6cf1-09ef-464d80afff3b@enterprisedb.com  

commit   : 80f64b90088a8aeae6aeace2d344c8116ec28061    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 May 2023 13:00:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 May 2023 13:00:31 +0200    

When merging BRIN summaries, union_tuples() did not correctly update the  
target hasnulls/allnulls flags. When merging all-NULL summary into a  
summary without any NULL values, the result had both flags set to false  
(instead of having hasnulls=true).  
  
This happened because the code only considered the hasnulls flags,  
ignoring the possibility the source summary has allnulls=true.  
  
Discovered while investigating issues with handling empty BRIN ranges  
and handling of NULL values, but it's a separate problem (has nothing to  
do with empty ranges).  
  
Fixed by considering both flags on the source summary, and updating the  
hasnulls flag on the target summary.  
  
Backpatch to 11. The bug exists since 9.5 (where BRIN indexes were  
introduced), but those releases are EOL already.  
  
Discussion: https://postgr.es/m/9d993d0d-e431-2196-9ccc-0554d0e60154%40enterprisedb.com  

commit   : eaf99e4c4ae4084b8261e5e1f9c2c93004a98638    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2023 10:53:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2023 10:53:42 -0400    

fuzzystrmatch's difference() function assumes that _soundex()  
always initializes its output buffer fully.  This was not so for  
the case of a string containing no alphabetic characters, resulting  
in unstable output and Valgrind complaints.  
  
Fix by using memset() to fill the whole buffer in the early-exit  
case.  Also make some cosmetic improvements (I didn't care for the  
random switches between "instr[0]" and "*instr" notation).  
  
Report and diagnosis by Alexander Lakhin (bug #17935).  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17935-b99316aa79c18513@postgresql.org  

commit   : f06156da18f67bc2c904c0a76b70dafcb14ca7c2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 May 2023 11:47:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 May 2023 11:47:25 +0200    

The problem that these messages protect against can only occur because  
a corrupted hash spill file was written, i.e., a Postgres bug.  There's  
no reason to have them as translatable.  
  
Backpatch to 15, where these messages were changed by commit c4649cce39a4.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/20230510175407.dwa5v477pw62ikyx@alvherre.pgsql  

commit   : bc478a0a85bc8660bfa251866f85c673e4be84ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2023 16:11:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2023 16:11:14 -0400    

Don't use PSQL_WATCH_PAGER when stdin/stdout are not a terminal.  
This corresponds to the restrictions on when other commands will  
use [PSQL_]PAGER.  There isn't a lot of sense in trying to use a  
pager in non-interactive cases, and doing so allows an environment  
setting to break our tests.  
  
Also, ignore PSQL_WATCH_PAGER if it is set but empty or all-blank,  
for the same reasons we ignore such settings of [PSQL_]PAGER (see  
commit 18f8f784c).  
  
No documentation change is really needed, since there is nothing  
suggesting that these constraints on [PSQL_]PAGER didn't already  
apply to PSQL_WATCH_PAGER too.  But I rearranged the text  
a little to make it read more naturally (IMHO anyway).  
  
Per report from Pavel Stehule.  Back-patch to v15 where  
PSQL_WATCH_PAGER was introduced.  
  
Discussion: https://postgr.es/m/CAFj8pRDTwFzmEWdA-gdAcUh0ZnxUioSfTMre71WyB_wNJy-8gw@mail.gmail.com  

commit   : 95f2827c80acc06fecf4b47e46d95a038e0c8664    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 May 2023 10:49:48 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 May 2023 10:49:48 -0700    

Fix a link from the "Heap-Only Tuples" documentation section.  
Previously, its "fillfactor" link pointed to the "CREATE TABLE"  
command's documentation.  Now the link directly points to the fillfactor  
storage parameter documentation (which is about half way into the  
"CREATE TABLE" sect1).  
  
Oversight in commit 115464bb.  
  
Backpatch: 12-, the first version with a usable reloption link.  

commit   : 8e1d68c8f8eae96334db2f6633d2a61bcfb22f9a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 May 2023 18:26:10 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 May 2023 18:26:10 +0200    

There was some odd wording in corner-case gram.y error messages "some  
error ... at or near", which appears to have been modeled after "syntax  
error" messages.  However, they don't work that way, and they're just  
wrong.  They're also uncovered by tests.  Remove the trailing words,  
and also add tests.  
  
They were introduced with 5a2832465fd8; backpatch to 15.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : ccd21e1cfa11fa4f39d01d95cf119beae9cf4d20    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 May 2023 11:24:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 May 2023 11:24:40 +0900    

An update of the GUC stats_fetch_consistency in a transaction would be  
able to trigger an assertion when doing cache->snapshot.  In this case,  
when retrieving a pgstat entry after the switch, a new snapshot would be  
rebuilt, confusing pgstat_build_snapshot() because a snapshot is already  
cached with an unexpected mode ("cache").  
  
In order to fix this problem, this commit adds a flag to force a  
snapshot clear each time this GUC is changed.  Some tests are added to  
check, while on it.  
  
Some optimizations in avoiding the snapshot clear should be possible  
depending on what is cached and the current GUC value, I guess, but this  
solution is simple, and ensures that the state of the cache is updated  
each time a new pgstat entry is fetched, hence being consistent with the  
level wanted by the client that has set the GUC.  
  
Note that cache->none and snapshot->none would not cause issues, as  
fetching a pgstat entry would be retrieved from shared memory on the  
second attempt, however a snapshot would still be cached.  Similarly,  
none->snapshot and none->cache would build a new snapshot on the second  
fetch attempt.  Finally, snapshot->cache would cache a new snapshot on  
the second attempt.  
  
Reported-by: Alexander Lakhin  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/17804-2a118cd046f2d0e5@postgresql.org  
backpatch-through: 15  

commit   : 8382864eb5c9f9ebe962ac20b3392be5ae304d23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 17:13:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 17:13:20 -0400    

commit   : 8cd6b5af5898900e674885284f855c0a0abdcd70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 12:38:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 12:38:08 -0400    

Security: CVE-2023-2454, CVE-2023-2455  

commit   : 1b761d89644b584dff2dcc8cbdf7b1e11b4e9cde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 11:24:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 11:24:47 -0400    

Security: CVE-2023-2454  

commit   : 04e5606045e4887463ac9070acfc52e060fe6583    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 10:12:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 10:12:44 -0400    

If an SRF in the FROM clause references a table having row-level  
security policies, and we inline that SRF into the calling query,  
we neglected to mark the plan as potentially dependent on which  
role is executing it.  This could lead to later executions in the  
same session returning or hiding rows that should have been hidden  
or returned instead.  
  
Our thanks to Wolfgang Walther for reporting this problem.  
  
Stephen Frost and Tom Lane  
  
Security: CVE-2023-2455  

commit   : dbd5795e7539ec9e15c0d4ed2d05b1b18d2a3b09    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2023 06:14:07 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2023 06:14:07 -0700    

The two methods don't cooperate, so set_config_option("search_path",  
...) has been ineffective under non-empty overrideStack.  This defect  
enabled an attacker having database-level CREATE privilege to execute  
arbitrary code as the bootstrap superuser.  While that particular attack  
requires v13+ for the trusted extension attribute, other attacks are  
feasible in all supported versions.  
  
Standardize on the combination of NewGUCNestLevel() and  
set_config_option("search_path", ...).  It is newer than  
PushOverrideSearchPath(), more-prevalent, and has no known  
disadvantages.  The "override" mechanism remains for now, for  
compatibility with out-of-tree code.  Users should update such code,  
which likely suffers from the same sort of vulnerability closed here.  
Back-patch to v11 (all supported versions).  
  
Alexander Lakhin.  Reported by Alexander Lakhin.  
  
Security: CVE-2023-2454  

commit   : 8229bfe91def5878b498996ab24b62950edd9e40    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 14:29:57 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 14:29:57 +0200    

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

commit   : b89a27ae554492501cfcd6492c9a9fc30be1dc7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 12:36:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 12:36:12 -0400    

commit   : f200b9695fde037ec5c182871339a02e98abecdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 11:01:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 11:01:15 -0400    

This was overlooked when MERGE was added, but it's essential  
support for MERGE in new-style SQL functions.  
  
Alvaro Herrera  
  
Discussion: https://postgr.es/m/3579737.1683293801@sss.pgh.pa.us  

commit   : 56e869a0987c93f594e73c1c3e49274de5c502d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2023 12:38:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2023 12:38:54 -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   : d31dab9a541c2c4c5b0491a7b3fe964c9494e216    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 May 2023 21:25:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 May 2023 21:25:50 +0900    

This wait event was documented as "CommitTsBuffer" since its  
introduction, but the code named it "CommitTSBuffer".  This commit fixes  
the code to follow the term documented, which is also more consistent  
with the naming of the other wait events used for commit timestamps.  
  
Introduced by 5da1493.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com  
Backpatch-through: 13  

commit   : 3d37476f503f02f079648f0abb3c2354e1c3ab74    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 May 2023 06:29:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 May 2023 06:29:49 +0200    

Commit 153e215677 added the portlock directory.  This is created in  
$ENV{top_builddir} if it is set.  Under PGXS, top_builddir points into  
the installation directory, which is not necessarily writable and in  
any case inappropriate to use by a test suite.  The cause of the  
problem is that the prove_installcheck target in Makefile.global  
exports top_builddir, which isn't useful (since no other Perl code  
actually reads it) and breaks this use case.  The reason this code is  
there is probably that is has been dragged around with various other  
changes, in particular a0fc813266, but without a real purpose of its  
own.  By just removing the exporting of top_builddir in  
prove_installcheck, the portlock directory then ends up under  
tmp_check in the build directory, which is more suitable.  
  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://www.postgresql.org/message-id/78d1cfa6-0065-865d-584b-cde6d8c18aff@enterprisedb.com  

commit   : 825ebc9848fdf9f229ba05a9aec3f58d13b17fd4    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 3 May 2023 11:32:43 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 3 May 2023 11:32:43 -0700    

If we exit a PG_TRY block early via "continue", "break", "goto", or  
"return", we'll skip unwinding its exception stack.  This change  
moves a couple of such "return" statements in PL/Python out of  
PG_TRY blocks.  This was introduced in d0aa965c0a and affects all  
supported versions.  
  
We might also be able to add compile-time checks to prevent  
recurrence, but that is left as a future exercise.  
  
Reported-by: Mikhail Gribkov, Xing Guo  
Author: Xing Guo  
Reviewed-by: Michael Paquier, Andres Freund, Tom Lane  
Discussion: https://postgr.es/m/CAMEv5_v5Y%2B-D%3DCO1%2Bqoe16sAmgC4sbbQjz%2BUtcHmB6zcgS%2B5Ew%40mail.gmail.com  
Discussion: https://postgr.es/m/CACpMh%2BCMsGMRKFzFMm3bYTzQmMU5nfEEoEDU2apJcc4hid36AQ%40mail.gmail.com  
Backpatch-through: 11 (all supported versions)  

commit   : ccb479e76ac3032ef942f5d4f6a3ab742c2db03e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:48:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:48:23 -0400    

These functions incautiously fetched the array's first lower bound  
even when the array is zero-dimensional, thus fetching the word  
after the allocated array space.  While almost always harmless,  
with very bad luck this could result in SIGSEGV.  Fix by adding  
an early exit for empty input.  
  
Per bug #17920 from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/17920-f7c228c627b6d02e%40postgresql.org  

commit   : b7001c6b6a776ecff38cb1b40ce10a9d190fc1fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:00:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:00:33 -0400    

Like plperl before f47004add, plpython wasn't being sufficiently  
careful about checking that list-of-list structures represent  
rectangular arrays, so that it would accept some cases in which  
different parts of the "array" are nested to different depths.  
This was exacerbated by Python's weak distinction between  
sequences and lists, so that in some cases strings could get  
treated as though they are lists (and burst into individual  
characters) even though a different ordering of the upper-level  
list would give a different result.  
  
Some of this behavior was unreachable (without risking a crash)  
before 81eaaf65e.  It seems like a good idea to clean it all up  
in the same releases, rather than shipping a non-crashing but  
nonetheless visibly buggy behavior in the name of minimal change.  
Hence, back-patch.  
  
Per bug #17912 and further testing by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org  

commit   : 23c7aa865b321b9aba50b105288a5d12ccc35442    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2023 17:55:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2023 17:55:01 -0400    

plperl, plpython, and pltcl all provide query-execution functions  
that are thin wrappers around SPI_execute() or its variants.  
The SPI functions document their row-count limit arguments clearly,  
as "maximum number of rows to return, or 0 for no limit".  However  
the PLs' documentation failed to explain this special behavior of  
zero, so that a reader might well assume it means "fetch zero  
rows".  Improve that.  
  
Daniel Gustafsson and Tom Lane, per report from Kieran McCusker  
  
Discussion: https://postgr.es/m/CAGgUQ6H6qYScctOhktQ9HLFDDoafBKHyUgJbZ6q_dOApnzNTXg@mail.gmail.com  

commit   : 77ea05406cb61292782eb874866247f20b47b6df    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 11:40:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 11:40:58 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com  
Backpatch-through: 14  

commit   : ce9a1a3ea8fe672a46502070d421f107f43d35dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Apr 2023 13:06:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Apr 2023 13:06:44 -0400    

plperl_array_to_datum() wasn't sufficiently careful about checking  
that nested lists represent a rectangular array structure; it would  
accept inputs such as "[1, []]".  This is a bit related to the  
PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to  
provide any direct route to a memory stomp.  Instead the likely  
failure mode is for makeMdArrayResult to be passed fewer Datums than  
the claimed array dimensionality requires, possibly leading to a wild  
pointer dereference and SIGSEGV.  
  
Per report from Alexander Lakhin.  It's been broken for a long  
time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com  

commit   : 512c555221c33f1791ee28a4cfeb929fcd957fdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Apr 2023 12:24:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Apr 2023 12:24:29 -0400    

If PLySequence_ToArray came across a zero-length sublist, it'd compute  
the overall array size as zero, possibly leading to a memory clobber.  
(This would likely qualify as a security bug, were it not that plpython  
is an untrusted language already.)  
  
I think there are other corner-case issues in this code as well, notably  
that the error messages don't match the core code and for some ranges  
of array sizes you'd get "invalid memory alloc request size" rather than  
the intended message about array size.  
  
Really this code has no business doing its own array size calculation  
at all, so remove the faulty code in favor of using ArrayGetNItems().  
  
Per bug #17912 from Alexander Lakhin.  Bug seems to have come in with  
commit 94aceed31, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org  

commit   : b9ad73ad250bc278d52d4383b0f3972997a43906    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Apr 2023 19:29:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Apr 2023 19:29:36 +0900    

CREATE SCHEMA AUTHORIZATION with appended schema elements can lead to  
crashes when comparing the schema name of the query with the schemas  
used in the qualification of some clauses in the elements' queries.  
  
The origin of the problem is that the transformation routine for the  
elements listed in a CREATE SCHEMA query uses as new, expected, schema  
name the one listed in CreateSchemaStmt itself.  However, depending on  
the query, CreateSchemaStmt.schemaname may be NULL, being computed  
instead from the role specification of the query given by the  
AUTHORIZATION clause, that could be either:  
- A user name string, with the new schema name being set to the same  
value as the role given.  
- Guessed from CURRENT_ROLE, SESSION_ROLE or CURRENT_ROLE, with a new  
schema name computed from the security context where CREATE SCHEMA is  
running.  
  
Regression tests are added for CREATE SCHEMA with some appended elements  
(some of them with schema qualifications), covering also some role  
specification patterns.  
  
While on it, this simplifies the context structure used during the  
transformation of the elements listed in a CREATE SCHEMA query by  
removing the fields for the role specification and the role type.  They  
were not used, and for the role specification this could be confusing as  
the schema name may by extracted from that at the beginning of  
CreateSchemaCommand().  
  
This issue exists for a long time, so backpatch down to all the versions  
supported.  
  
Reported-by: Song Hongyu  
Author: Michael Paquier  
Reviewed-by: Richard Guo  
Discussion: https://postgr.es/m/17909-f65c12dfc5f0451d@postgresql.org  
Backpatch-through: 11  

commit   : c98b06e2f8655818e83a5a26ef93cc31c357614c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 27 Apr 2023 13:43:48 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 27 Apr 2023 13:43:48 -0700    

The call to XLogGetReplicationSlotMinimumLSN() might return a  
greater LSN than the one given to the function.  Subsequent segment  
number calculations might then underflow, which could result in  
unexpected behavior when removing or recyling WAL files.  This was  
introduced with max_slot_wal_keep_size in c655077639.  To fix, skip  
the block of code for replication slots if the LSN is greater.  
  
Reported-by: Xu Xingwang  
Author: Kyotaro Horiguchi  
Reviewed-by: Junwang Zhao  
Discussion: https://postgr.es/m/17903-4288d439dee856c6%40postgresql.org  
Backpatch-through: 13  

commit   : 85ec8bcce2608b8e29a1a0742282d39b29b78dda    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2023 11:55:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2023 11:55:06 -0400    

Python 3 changed the behavior of PyMapping_Check(), breaking the  
test in plpython_to_hstore() that verifies whether a function result  
to be transformed is acceptable.  A backwards-compatible fix is to  
first verify that the object doesn't pass PySequence_Check().  
  
Perhaps accidentally, our other uses of PyMapping_Check() already  
follow uses of PySequence_Check(), so that no other bugs were  
created by this change.  
  
Per bug #17908 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Dmitry Dolgov and Tom Lane  
  
Discussion: https://postgr.es/m/17908-3f19a125d56a11d6@postgresql.org  

commit   : 1ed1b84bdcd26abf3c4d08a9cf1aa9f7834262ab    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Apr 2023 07:30:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Apr 2023 07:30:42 +0900    

SLRUFlushSync has been accidently removed during dee663f, that has moved  
the flush of the SLRU files to the checkpointer, so add it back.  The  
issue has been noticed by Thomas when checking for orphaned wait  
events.  
  
Author: Thomas Munro  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/CA+hUKGK6tqm59KuF1z+h5Y8fsWcu5v8+84kduSHwRzwjB2aa_A@mail.gmail.com  

commit   : 0319b306e87e04a02b672b38caf578859fcea6a3    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 25 Apr 2023 13:54:10 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 25 Apr 2023 13:54:10 +0200    

Commit 1021bd6a89 excluded autovacuum workers from cost-limit balance  
calculations when per-relation options were set.  The code checks for  
limit and cost_delay being greater than zero, but since cost_delay can  
be set to -1 the test needs to check for greater than or zero.  
  
Backpatch to all supported branches since 1021bd6a89 was backpatched  
all the way at the time.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAD21AoBS7o6Ljt_vfqPQPf67AhzKu3fR0iqk8B=vVYczMugKMQ@mail.gmail.com  
Backpatch-through: v11 (all supported branches)  

commit   : aa6177c882d4cd11559d0a10b73e6cd1d8c18fb1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Apr 2023 09:42:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Apr 2023 09:42:33 +0900    

The leak would show up when using batch inserts with foreign tables  
included in a partition tree, as the slots used in the batch were not  
reset once processed.  In order to fix this problem, some  
ExecClearTuple() are added to clean up the slots used once a batch is  
filled and processed, mapping with the number of slots currently in use  
as tracked by the counter ri_NumSlots.  
  
This buffer refcount leak has been introduced in b676ac4 with the  
addition of the executor facility to improve bulk inserts for FDWs, so  
backpatch down to 14.  
  
Alexander has provided the patch (slightly modified by me).  The test  
for postgres_fdw comes from me, based on the test case that the author  
has sent in the report.  
  
Author: Alexander Pyhalov  
Discussion: https://postgr.es/m/b035780a740efd38dc30790c76927255@postgrespro.ru  
Backpatch-through: 14  

commit   : c1598d85fe465e650e6af126610c8e33c450f939    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2023 14:19:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2023 14:19:46 -0400    

Commit 04fe805a1 modified plpgsql so that datatype casts make use of  
expressions cached by plancache.c, in place of older code where these  
expression trees were managed by plpgsql itself.  However, I (tgl)  
forgot that we use a separate, shorter-lived cast info hashtable in  
DO blocks.  The new mechanism thus resulted in session-lifespan  
leakage of the plancache data once a DO block containing one or more  
casts terminated.  To fix, split the cast hash table into two parts,  
one that tracks only the plancache's CachedExpressions and one that  
tracks the expression state trees generated from them.  DO blocks need  
their own expression state trees and hence their own version of the  
second hash table, but there's no reason they can't share the  
CachedExpressions with regular plpgsql functions.  
  
Per report from Ajit Awekar.  Back-patch to v12 where the issue  
was introduced.  
  
Ajit Awekar and Tom Lane  
  
Discussion: https://postgr.es/m/CAHv6PyrNaqdvyWUspzd3txYQguFTBSnhx+m6tS06TnM+KWc_LQ@mail.gmail.com  

commit   : a63b821c137524ad1ec699f20c0bf57987ffce82    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 24 Apr 2023 11:16:17 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 24 Apr 2023 11:16:17 +0200    

Commit 6df7a9698bb accidentally included two identical prototypes for  
default_multirange_selectivi() and commit 086cf1458c6 added a break;  
statement where one was already present, thus duplicating it.  While  
there is no bug caused by this, fix by removing the duplicated lines  
as they provide no value.  
  
Backpatch the fix for duplicate prototypes to v14 and the duplicate  
break statement fix to all supported branches to avoid backpatching  
hazards due to the removal.  
  
Reported-by: Anton Voloshin <a.voloshin@postgrespro.ru>  
Discussion: https://postgr.es/m/0e69cb60-0176-f6d0-7e15-6478b7d85724@postgrespro.ru  

commit   : 214495dc5b712552d3938d5f03acddfedc8a81ca    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:58:25 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:58:25 +0300    

Unaligned siglen could lead to an unaligned access to subsequent key fields.  
  
Backpatch to 13, where opclass options were introduced.  
  
Reported-by: Alexander Lakhin  
Bug: 17847  
Discussion: https://postgr.es/m/17847-171232970bea406b%40postgresql.org  
Reviewed-by: Tom Lane, Pavel Borisov, Alexander Lakhin  
Backpatch-through: 13  

commit   : 6e7361c85e95a09ee0d1fbb2f8460962b86489ab    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:55:49 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:55:49 +0300    

We need to call them only when validate == true.  
  
Backpatch to 13, where opclass options were introduced.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/2656633.1681831542%40sss.pgh.pa.us  
Reviewed-by: Tom Lane, Pavel Borisov  
Backpatch-through: 13  

commit   : 109363de0a8906ed6b0b4ab5f8e8e3daa3df929a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 21 Apr 2023 08:19:41 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 21 Apr 2023 08:19:41 -0700    

For regex escape sequences, just test directly for the relevant ASCII  
characters rather than using locale-sensitive character  
classification.  
  
This fixes an assertion failure when a locale considers a non-ASCII  
character, such as "൧", to be a digit.  
  
Reported-by: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs49Q6UoKGeT8pBkMtJGJd+16CBFZaaWUk9Du+2ERE5g_YA@mail.gmail.com  
Backpatch-through: 11  

commit   : a14afd3bdc21c0c56401fb8cb2fce74f4b7dc446    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Apr 2023 18:12:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Apr 2023 18:12:32 -0400    

We've long used "--strip-unneeded" for shared libraries but plain  
"-x" for static libraries when stripping symbols with GNU strip.  
There doesn't seem to be any really good reason for that though,  
since --strip-unneeded produces smaller output (as "-x" alone  
does not remove debug symbols).  Moreover it seems that  
llvm-strip, although it identifies as GNU strip, misbehaves when  
given "-x" for this purpose.  It's unclear whether that's  
intentional or a bug in llvm-strip, but in any case it seems like  
changing to use --strip-unneeded in all cases should be a win.  
  
Note that this doesn't change our behavior when dealing with  
non-GNU strip.  
  
Per gripes from Ed Maste and Palle Girgensohn.  Back-patch,  
in case anyone wants to use llvm-strip with stable branches.  
  
Discussion: https://postgr.es/m/17898-5308d09543463266@postgresql.org  
Discussion: https://postgr.es/m/20230420153338.bbj2g5jiyy3afhjz@awork3.anarazel.de  

commit   : 63a03aea6bc89060010255e8e61c83f95e1daec8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 10:02:25 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 10:02:25 +1200    

list_copy_head() given an empty List would crash from trying to  
dereference the List to obtain its length.  Since NIL is how we represent  
an empty List, we should just be returning another empty List in this  
case.  
  
list_copy_head() is new to v16, so let's fix it now before too many people  
start coding around the buggy NIL behavior.  
  
Reported-by: Miroslav Bendik  
Discussion: https://postgr.es/m/CAPoEpV02WhawuWnmnKet6BqU63bEu7oec0pJc=nKMtPsHMzTXQ@mail.gmail.com  

commit   : 94d73f9abdf13e6dd93d96d0e4b197479c8756de    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 23:52:36 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 23:52:36 +1200    

indexes-unique.html mentioned nothing about the availability of NULLS NOT  
DISTINCT to modify the NULLs-are-not-equal behavior of unique indexes.  
Add this to the synopsis and clarify what it does regarding NULLs.  
  
Author: David Gilman, David Rowley  
Reviewed-by: Corey Huinker  
Discussion: https://postgr.es/m/CALBH9DDr3NLqzWop1z5uZE-M5G_GYUuAeHFHQeyzFbNd8W0d=Q@mail.gmail.com  
Backpatch-through: 15, where NULLS NOT DISTINCT was added  

commit   : 62b22caa5531da8f6498f09f15ac0f09c95b1459    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Apr 2023 14:46:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Apr 2023 14:46:39 -0400    

DST law changes in Egypt, Greenland, Morocco, and Palestine.  
  
When observing Moscow time, Europe/Kirov and Europe/Volgograd now  
use the abbreviations MSK/MSD instead of numeric abbreviations,  
for consistency with other timezones observing Moscow time.  
  
Also, America/Yellowknife is no longer distinct from America/Edmonton;  
this affects some pre-1948 timestamps in that area.  

commit   : 8c746be44002e8f95dcf8e98f58a47ac851563ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Apr 2023 11:20:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Apr 2023 11:20:47 +0900    

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where  
it would incorrectly store the null terminator byte to str[-1] when  
varcharsize is 0, which is something that can happen when using SQLDA.  
This would eat 1 byte from the previous field stored, corrupting the  
results generated.  
  
All the callers of ecpg_get_data() estimate and allocate enough storage  
for the data received, and the fix of this commit relies on this  
assumption.  Note that this maps to the case where no padding or  
truncation is required.  
  
This issue has been introduced by 3b7ab43 with the Oracle compatibility  
option, so backpatch down to v11.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20230410.173500.440060475837236886.horikyota.ntt@gmail.com  
Backpatch-through: 11  

commit   : 2207df7c34bfcecec33da2a47068e94d7882ffdb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Apr 2023 14:22:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Apr 2023 14:22:06 -0400    

If the last few pages in the specified range are empty (all zero),  
then log_newpage_range() could try to emit an empty WAL record  
containing no FPIs.  This at least upsets an Assert in  
ReserveXLogInsertLocation, and might perhaps have bad real-world  
consequences in non-assert builds.  
  
This has been broken since log_newpage_range() was introduced,  
but the case was hard if not impossible to hit before commit 3d6a98457  
decided it was okay to leave VM and FSM pages intentionally zero.  
Nonetheless, it seems prudent to back-patch.  log_newpage_range()  
was added in v12 but later back-patched, so this affects all  
supported branches.  
  
Matthias van de Meent, per report from Justin Pryzby  
  
Discussion: https://postgr.es/m/ZD1daibg4RF50IOj@telsasoft.com  

commit   : c53ed26ea46e425c1a78bd0e72b74a541eb08a93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2023 12:01:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2023 12:01:39 -0400    

Commit 3e310d837 taught isAssignmentIndirectionExpr() to look through  
CoerceToDomain nodes.  That's not sufficient, because since commit  
04fe805a1 it's been possible for the planner to simplify  
CoerceToDomain to RelabelType when the domain has no constraints  
to enforce.  So we need to look through RelabelType too.  
  
Per bug #17897 from Alexander Lakhin.  Although 3e310d837 was  
back-patched to v11, it seems sufficient to apply this change  
to v12 and later, since 04fe805a1 came in in v12.  
  
Dmitry Dolgov  
  
Discussion: https://postgr.es/m/17897-4216c546c3874044@postgresql.org  

commit   : de575c78e14c909ce6962021552e0263ac237935    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 14 Apr 2023 10:15:50 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 14 Apr 2023 10:15:50 +0200    

Starting with OpenSSL 1.1.0 there is no need to call PQinitOpenSSL  
or PQinitSSL to avoid duplicate initialization of OpenSSL.  Add a  
note to the documentation to explain this.  
  
Backpatch to all supported versions as older OpenSSL versions are  
equally likely to be used for all branches.  
  
Reported-by: Sebastien Flaesch <sebastien.flaesch@4js.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/DBAP191MB12895BFFEC4B5FE0460D0F2FB0459@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM  
Backpatch-through: 11, all supported versions  

commit   : 0c09160e113f3b7daf9fc5370357955ab039428d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 14 Apr 2023 16:21:07 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 14 Apr 2023 16:21:07 +1200    

The partition pruning logic assumed that "b IS NOT true" was exactly the  
same as "b IS FALSE".  This is not the case when considering NULL values.  
Fix this so we correctly include any partition which could hold NULL  
values for the NOT case.  
  
Additionally, this fixes a bug in the partition pruning code which handles  
partitioned tables partitioned like ((NOT boolcol)).  This is a seemingly  
unlikely schema design, and it was untested and also broken.  
  
Here we add tests for the ((NOT boolcol)) case and insert some actual data  
into those tables and verify we do get the correct rows back when running  
queries.  I've also adjusted the existing boolpart tests to include some  
data and verify we get the correct results too.  
  
Both the bugs being fixed here could lead to incorrect query results with  
fewer rows being returned than expected.  No additional rows could have  
been returned accidentally.  
  
In passing, remove needless ternary expression.  It's more simple just to  
pass !is_not_clause to makeBoolConst().  It makes sense to do this so the  
code is consistent with the bug fix in the "else if" condition just below.  
  
David Kimura did submit a patch to fix the first of the issues here, but  
that's not what's being committed here.  
  
Reported-by: David Kimura  
Reviewed-by: Richard Guo, David Kimura  
Discussion: https://postgr.es/m/CAHnPFjQ5qxs6J_p+g8=ww7GQvfn71_JE+Tygj0S7RdRci1uwPw@mail.gmail.com  
Backpatch-through: 11, all supported versions  

commit   : fa83e9e23ca2542d040466d820c3bf8eef930331    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:37:13 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:37:13 -0400    

Per complaint from Peter Eisentraut.  
  
Discussion: http://postgr.es/m/4f1707cc-2432-da35-64a2-5c2a8d92a388@enterprisedb.com  

commit   : 749320cdc3fd747b9238d4e67a7521973c03fa27    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:18:40 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:18:40 -0400    

Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc should have done  
this, but I overlooked it.  
  
Per complaint from Thomas Munro.  
  
Discussion: http://postgr.es/m/CA+hUKGJixAHc860Ej9Qzd_z96Z6aoajAgJ18bYfV3Lfn6t9=+Q@mail.gmail.com  

commit   : f4badbcf4540d3f15de0e36fabca3ab05b20b922    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Apr 2023 10:46:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Apr 2023 10:46:30 -0400    

Our policy since commit ab77a5a45 has been that a plan node having  
any initplans is automatically not parallel-safe.  (This could be  
relaxed, but not today.)  clean_up_removed_plan_level neglected  
this, and could attach initplans to a parallel-safe child plan  
node without clearing the plan's parallel-safe flag.  That could  
lead to "subplan was not initialized" errors at runtime, in case  
an initplan referenced another one and only the referencing one  
got transmitted to parallel workers.  
  
The fix in clean_up_removed_plan_level is trivial enough.  
materialize_finished_plan also moves initplans from one node  
to another, but it's okay because it already copies the source  
node's parallel_safe flag.  The other place that does this kind  
of thing is standard_planner's hack to inject a top-level Gather  
when debug_parallel_query is active.  But that's actually dead  
code given that we're correctly enforcing the "initplans aren't  
parallel safe" rule, so just replace it with an Assert that  
there are no initplans.  
  
Also improve some related comments.  
  
Normally we'd add a regression test case for this sort of bug.  
The mistake itself is already reached by existing tests, but there  
is accidentally no visible problem.  The only known test case that  
creates an actual failure seems too indirect and fragile to justify  
keeping it as a regression test (not least because it fails to fail  
in v11, though the bug is clearly present there too).  
  
Per report from Justin Pryzby.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/ZDVt6MaNWkRDO1LQ@telsasoft.com  

commit   : 5c32549460fcabfb34ce47f96499bf753aaabeea    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Apr 2023 09:09:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Apr 2023 09:09:53 +0900    

Calling fseek() or ftello() on a handle to a non-seeking device such as  
a pipe or a communications device is not supported.  Unfortunately,  
MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not  
return an error when given a pipe as handle.  Some of the logic of  
pg_dump and restore relies on these routines to check if a handle is  
seekable, causing failures when passing the contents of pg_dump to  
pg_restore through a pipe, for example.  
  
This commit introduces wrappers for fseeko() and ftello() on MSVC so as  
any callers are able to properly detect the cases of non-seekable  
handles.  This relies mainly on GetFileType(), sharing a bit of code  
with the MSVC port for fstat().  The code in charge of getting a file  
type is refactored into a new file called win32common.c, shared by  
win32stat.c and the new win32fseek.c.  It includes the MSVC ports for  
fseeko() and ftello().  
  
Like 765f5df, this is backpatched down to 14, where the fstat()  
implementation for MSVC is able to understand about files larger than  
4GB in size.  Using a TAP test for that is proving to be tricky as  
IPC::Run handles the pipes by itself, still I have been able to check  
the fix manually.  
  
Reported-by: Daniel Watzinger  
Author: Juan José Santamaría Flecha, Michael Paquier  
Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com  
Backpatch-through: 14  

commit   : 8b07ee0beb9f67716a13bae193207ac19129bd0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 15:49:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 15:49:48 -0400    

The tables in "71.3. Extensibility" listing the support functions  
for bloom and minmax-multi opclasses should include the associated  
options function.  While this isn't quite as required as the rest,  
you need it for full functionality of the opclass.  
  
Back-patch to v14 where these functions were added.  

commit   : 707691ea620eaa7d8c7fc1e5177a54e944f39b59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 13:09:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 13:09:18 -0400    

EXTRACT(EPOCH), EXTRACT(SECOND), and some related cases print more  
trailing zeroes than they used to.  This behavior change happened  
with commit a2da77cdb (Change return type of EXTRACT to numeric),  
and it was intentional according to the commit log:  
  
    - Return values when extracting fields with possibly fractional  
      values, such as second and epoch, now have the full scale that the  
      value has internally (so, for example, '1.000000' instead of just  
      '1').  
  
It's been like that for two releases now, so while I suggested  
changing this back, it's probably better to adjust the documentation  
examples.  
  
Per bug #17866 from Евгений Жужнев.  Back-patch to v14 where the  
change came in.  
  
Discussion: https://postgr.es/m/17866-18eb70095b1594e2@postgresql.org  

commit   : ced712f1a1d60d5e24d207d97efbc4dddc051079    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    

Similar to 8dff2f224, this disables DNS lookups by the Kerberos library  
to look up the KDC and the realm while the Kerberos tests are running.  
In some environments, these lookups can take a long time and end up  
timing out and causing tests to fail.  Further, since this isn't really  
our domain, we shouldn't be sending out these DNS requests during our  
tests.  

commit   : 0787432f33fbbda4f628f4499468a3f7d0bc11ad    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    

In our Kerberos test suite, there isn't much need to worry about the  
normal canonicalization that Kerberos provides by looking up the reverse  
DNS for the IP address connected to, and in some cases it can actively  
cause problems (eg: a captive portal wifi where the normally not  
resolvable localhost address used ends up being resolved anyway, and  
not to the domain we are using for testing, causing the entire  
regression test to fail with errors about not being able to get a TGT  
for the remote realm for cross-realm trust).  
  
Therefore, disable it by adding rdns = false into the krb5.conf that's  
generated for the test.  
  
Reviewed-By: Heikki Linnakangas  
Discussion: https://postgr.es/m/Y/QD2zDkDYQA1GQt@tamriel.snowman.net  

commit   : d6ac2348b8a1f031013066619dfb2ce9872251ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 18:13:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 18:13:49 -0400    

The tests added by commits 029dea882 et al turn out to produce  
different output under -DRANDOMIZE_ALLOCATED_MEMORY.  This is  
not a bug exactly: that flag causes coerce_type() to invoke  
the input function twice when coercing an unknown-type literal  
to a specific type.  So you get tsqueryin's bleat about an empty  
tsquery twice.  Revise the test query to avoid that.  
  
Discussion: https://postgr.es/m/20230406213813.uep7plg6lvcywujo@awork3.anarazel.de  

commit   : f976a77787ebfd0595a3aa19ac6bb587cc6391e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 15:52:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 15:52:37 -0400    

tsquery's GETQUERY() macro is only safe to apply to a tsquery  
that is known non-empty; otherwise it gives a pointer to garbage.  
Before commit 5a617d75d, ts_headline() avoided this pitfall, but  
only in a very indirect, nonobvious way.  (hlCover could not reach  
its TS_execute call, because if the query contains no lexemes  
then hlFirstIndex would surely return -1.)  After that commit,  
it fell into the trap, resulting in weird errors such as  
"unrecognized operator" and/or valgrind complaints.  In HEAD,  
fix this by not calling TS_execute_locations() at all for an  
empty query.  In the back branches, add a defensive check to  
hlCover() --- that's not fixing any live bug, but I judge the  
code a bit too fragile as-is.  
  
Also, both mark_hl_fragments() and mark_hl_words() were careless  
about the possibility of empty search text: in the cases where  
no match has been found, they'd end up telling mark_fragment() to  
mark from word indexes 0 to 0 inclusive, even when there is no  
word 0.  This is harmless since we over-allocated the prs->words  
array, but it does annoy valgrind.  Fix so that the end index is -1  
and thus mark_fragment() will do nothing in such cases.  
  
Bottom line is that this fixes a live bug in HEAD, but in the  
back branches it's only getting rid of a valgrind nitpick.  
Back-patch anyway.  
  
Per report from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/c27f642d-020b-01ff-ae61-086af287c4fd@gmail.com  

commit   : 2624de79efe8d6866ddaf82ab780c96ad554b004    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Apr 2023 12:56:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Apr 2023 12:56:30 -0400    

In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned  
on cloned triggers, failing to find the clones because it thought they  
were system triggers.  Other variants of ENABLE/DISABLE TRIGGER would  
improperly apply a superuserness check.  Fix by adjusting the is-it-  
a-system-trigger check to match reality in those branches.  (As far  
as I can find, this is the only place that got it wrong.)  
  
There's no such bug in v15/HEAD, because we revised the catalog  
representation of system triggers to be what this code was expecting.  
However, add the test case to these branches anyway, because this area  
is visibly pretty fragile.  Also remove an obsoleted comment.  
  
The recent v15/HEAD commit 6949b921d fixed a nearby bug.  I now see  
that my commit message for that was inaccurate: the behavior of  
recursing to clone triggers is older than v15, but it didn't apply  
to the case in v13/v14 because in those branches parent partitioned  
tables have no pg_trigger entries for foreign-key triggers.  But add  
the test case from that commit to v13/v14, just to show what is  
happening there.  
  
Per bug #17886 from DzmitryH.  
  
Discussion: https://postgr.es/m/17886-5406d5d828aa4aa3@postgresql.org  

commit   : f5d60b1ea2156ecd42c6ccd4284f715763abf8f8    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 5 Apr 2023 14:16:19 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 5 Apr 2023 14:16:19 +0700    

Since 8b9e9644d, the messages for failed permissions checks report  
"table" where appropriate, rather than "relation".  
  
Backpatch to all supported branches  

commit   : b135a94db7743ffbceabf62c87be2b8f32a91465    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Apr 2023 07:59:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Apr 2023 07:59:49 +0900    

The explanation describing the dependency to system read() calls for  
these two functions has been removed in ddfc2d9.  And after more  
discussion about d69c404, we have concluded that adding more details  
makes them easier to understand.  
  
While on it, use the term "block read requests" (maybe found in cache)  
rather than "buffers fetched" and "buffer hits".  
  
Per discussion with Melanie Plageman, Kyotaro Horiguchi, Bertrand  
Drouvot and myself.  
  
Discussion: https://postgr.es/m/CAAKRu_ZmdiScT4q83OAbfmR5AH-L5zWya3SXjaxiJvhCob-e2A@mail.gmail.com  
Backpatch-through: 11  

commit   : 6e369817367cc3a9d0db368383a4430733883142    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 11:18:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 11:18:49 -0400    

Up through v11 it was sensible to use the "oid" system column as  
a foreign key column, but since that was removed there's no visible  
usefulness in making any of the remaining system columns a foreign  
key.  Moreover, since the TupleTableSlot rewrites in v12, such cases  
actively fail because of implicit assumptions that only user columns  
appear in foreign keys.  The lack of complaints about that seems  
like good evidence that no one is trying to do it.  Hence, rather  
than trying to repair those assumptions (of which there are at least  
two, maybe more), let's just forbid the case up front.  
  
Per this patch, a system column in either the referenced or  
referencing side of a foreign key will draw this error; however,  
putting one in the referenced side would have failed later anyway,  
since we don't allow unique indexes to be made on system columns.  
  
Per bug #17877 from Alexander Lakhin.  Back-patch to v12; the  
case still appears to work in v11, so we shouldn't break it there.  
  
Discussion: https://postgr.es/m/17877-4bcc658e33df6de1@postgresql.org  

commit   : 6f7ca625b9d3f6298a3e1ecd0187d123c25316a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 10:08:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 10:08:40 -0400    

The totalrows/totaldeadrows outputs were left uninitialized in cases  
where we find no analyzable child tables of a partitioned table.  This  
could lead to setting the partitioned table's pg_class.reltuples value  
to garbage.  It's not clear that that would have any very bad effects  
in practice, but fix it anyway because it's making valgrind unhappy.  
  
Reported and diagnosed by Alexander Lakhin (bug #17880).  
  
Discussion: https://postgr.es/m/17880-9282037c923d856e@postgresql.org  

commit   : df567fbf6e41aa6b574ead3803c304af55645501    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Mar 2023 12:13:34 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Mar 2023 12:13:34 +1300    

When calling generateSerialExtraStmts(), we would pass in the  
constraint->options.  In some cases, generateSerialExtraStmts() would  
modify the referenced List to remove elements from it, but doing so is  
invalid without assigning the list back to all variables that point to it.  
In the particular reported problem case, the List became empty, in which  
cases it became NIL, but the passed in constraint->options didn't get to  
find out about that and was left pointing to free'd memory.  
  
To fix this, just perform a list_copy() inside generateSerialExtraStmts().  
We could just do a list_copy() just before we perform the delete from the  
list, however, that seems less robust.  Let's make sure the generated  
CreateSeqStmt gets a completely different copy of the list to be safe.  
  
Bug: #17879  
Reported-by: Fei Changhong  
Diagnosed-by: Fei Changhong  
Discussion: https://postgr.es/m/17879-b7dfb5debee58ff5@postgresql.org  
Backpatch-through: 11, all supported versions  

commit   : 2dc77adc768e7b5732b58c7ce1d0c0beb09cc79c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Mar 2023 11:31:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Mar 2023 11:31:30 -0400    

gistBuildCallback tried to fetch the size of an index tuple that  
might have already been freed by gistProcessEmptyingQueue.  
While this seems to usually be harmless in production builds,  
in principle it could result in a SIGSEGV, or more likely a bogus  
value for indtuplesSize leading to poor page-split decisions later  
in the build.  
  
The memory management here is confusing and could stand to be  
refactored, but for the moment it seems to be enough to fetch  
the tuple size sooner.  AFAICT the indtuples[Size] totals aren't  
used in between these places; even if they were, the updated  
values shouldn't be any worse to use.  So just move the  
incrementing of the totals up.  
  
It's not very clear why our valgrind-using buildfarm animals  
haven't noticed this problem, because the relevant code path  
does seem to be exercised according to the code coverage report.  
I think the reason that we didn't fix this bug after the first  
report is that I'd wanted to try to understand that better.  
However, now that it's been re-discovered let's just be pragmatic  
and fix it already.  
  
Original report by Alexander Lakhin (bug #16329),  
later rediscovered by Egor Chindyaskin (bug #17874).  
  
Patch by Alexander Lakhin (commentary by Pavel Borisov and me).  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16329-7a6aa9b6fa1118a1@postgresql.org  
Discussion: https://postgr.es/m/17874-63ca6c7ce42d2103@postgresql.org  

commit   : 453f53821fa549d3e46c87a076fc7849fab9a948    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Mar 2023 16:16:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Mar 2023 16:16:53 -0400    

Commit e88754a1965c0f40a723e6e46d670cacda9e19bd caused that case  
to be reported as corruption, but Peter Geoghegan pointed out that  
it can legitimately happen in the case of a speculative insertion  
that aborts, so we'd better not flag it as corruption after all.  
  
Back-patch to v14, like the commit that introduced the issue.  
  
Discussion: http://postgr.es/m/CAH2-WzmEabzcPTxSY-NXKH6Qt3FkAPYHGQSe2PtvGgj17ZQkCw@mail.gmail.com  

commit   : bf5c4b3d9da67ab0dd8a5a560804f88370c42866    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Mar 2023 11:36:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Mar 2023 11:36:50 -0400    

MERGE planning could fail with "variable not found in subplan target  
list" if the target table is partitioned and all its partitions are  
excluded at plan time, or in the case where it has no partitions but  
used to have some.  This happened because distribute_row_identity_vars  
thought it didn't need to make the target table's reltarget list  
fully valid; but if we generate a join plan then that is required  
because the dummy Result node's tlist will be made from the reltarget.  
  
The same logic appears in distribute_row_identity_vars in v14,  
but AFAICS the problem is unreachable in that branch for lack of  
MERGE.  In other updating statements, the target table is always  
inner-joined to any other tables, so if the target is known dummy  
then the whole plan reduces to dummy, so no join nodes are created.  
So I'll refrain from back-patching this code change to v14 for now.  
  
Per report from Alvaro Herrera.  
  
Discussion: https://postgr.es/m/20230328112248.6as34mlx5sr4kltg@alvherre.pgsql  

commit   : 50792b15537147a5e62e672568bd14e1e9292db2    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 27 Mar 2023 21:35:19 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 27 Mar 2023 21:35:19 +0200    

Homebrew changed the prefix for Apple Silicon based machines, so  
our advice for XML_CATALOG_FILES needs to mention both.  More info  
on the Homebrew change can be found at:  
  
https://github.com/Homebrew/brew/issues/9177  
  
This is backpatch of commits 4c8d65408 and 5a91c7975, the latter  
which contained a small fix based on a report from Dagfinn Ilmari  
Mannsåker.  
  
Author: Julien Rouhaud <julien.rouhaud@free.fr>  
Discussion: https://postgr.es/m/20230327082441.h7pa2vqiobbyo7rd@jrouhaud  

commit   : d90d59e2503879cc2742a3a0eee01d2af2cca02d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Mar 2023 15:04:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Mar 2023 15:04:02 -0400    

find_composite_type_dependencies() ignored indexes, which is a poor  
decision because an expression index could have a stored column of  
a composite (or other container) type even when the underlying table  
does not.  Teach it to detect such cases and error out.  We have to  
work a bit harder than for other relations because the pg_depend entry  
won't identify the specific index column of concern, but it's not much  
new code.  
  
This does not address bug #17872's original complaint that dropping  
a column in such a type might lead to violations of the uniqueness  
property that a unique index is supposed to ensure.  That seems of  
much less concern to me because it won't lead to crashes.  
  
Per bug #17872 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17872-d0fbb799dc3fd85d@postgresql.org  

commit   : 7c4873438fd4c89da40beb943a373c61ae509e93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Mar 2023 13:41:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Mar 2023 13:41:06 -0400    

The nested-arrays code path in ExecEvalArrayExpr() used palloc to  
allocate the result array, whereas every other array-creating function  
has used palloc0 since 18c0b4ecc.  This mostly works, but unused bits  
past the end of the nulls bitmap may end up undefined.  That causes  
valgrind complaints with -DWRITE_READ_PARSE_PLAN_TREES, and could  
cause planner misbehavior as cited in 18c0b4ecc.  There seems no very  
good reason why we should strive to avoid palloc0 in just this one case,  
so fix it the easy way with s/palloc/palloc0/.  
  
While looking at that I noted that we also failed to check for overflow  
of "nbytes" and "nitems" while summing the sizes of the sub-arrays,  
potentially allowing a crash due to undersized output allocation.  
For "nbytes", follow the policy used by other array-munging code of  
checking for overflow after each addition.  (As elsewhere, the last  
addition of the array's overhead space doesn't need an extra check,  
since palloc itself will catch a value between 1Gb and 2Gb.)  
For "nitems", there's no very good reason to sum the inputs at all,  
since we can perfectly well use ArrayGetNItems' result instead of  
ignoring it.  
  
Per discussion of this bug, also remove redundant zeroing of the  
nulls bitmap in array_set_element and array_set_slice.  
  
Patch by Alexander Lakhin and myself, per bug #17858 from Alexander  
Lakhin; thanks also to Richard Guo.  These bugs are a dozen years old,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17858-8fd287fd3663d051@postgresql.org  

commit   : 701ec555796884f6bd5d3ce67d927f52707ef9e6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Mar 2023 15:29:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Mar 2023 15:29:28 -0400    

In such cases, get_xid_status() doesn't set its output parameter (the  
third argument), so we shouldn't fall through to code which will test  
the value of that parameter. There are five existing calls to  
get_xid_status(), three of which seem to already handle this case  
properly.  This commit tries to fix the other two.  
  
If we're checking xmin and find that it is invalid (i.e. 0) just  
report that as corruption, similar to what's already done in the  
three cases that seem correct. If we're checking xmax and find  
that's invalid, that's fine: it just means that the tuple hasn't  
been updated or deleted.  
  
Thanks to Andres Freund and valgrind for finding this problem, and  
also to Andres for having a look at the patch.  This bug seems to go  
all the way back to where verify_heapam was first introduced, but  
wasn't detected until recently, possibly because of the new test cases  
added for update chain verification.  Back-patch to v14, where this  
code showed up.  
  
Discussion: http://postgr.es/m/CA+TgmoZAYzQZqyUparXy_ks3OEOfLD9-bEXt8N-2tS1qghX9gQ@mail.gmail.com  

commit   : b6bf90edcd2f9a754a90a3c852d9e445d17a6555    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 23 Mar 2023 11:46:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 23 Mar 2023 11:46:16 +0530    

We fail to apply updates and deletes when the REPLICA IDENTITY FULL is  
used for the table having generated columns. We didn't use to ignore  
generated columns while doing tuple comparison among the tuples from  
the publisher and subscriber during apply of updates and deletes.  
  
Author: Onder Kalaci  
Reviewed-by: Shi yu, Amit Kapila  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com  

commit   : 560bb56c6eba5da7917e67783d46f0d5ca30e89a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 22 Mar 2023 09:26:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 22 Mar 2023 09:26:23 -0700    

RelationCopyStorageUsingBuffer() did not free the strategies used to access  
the source / target relation. They memory was released at the end of the  
transaction, but when using a template database with a lot of relations, the  
temporary leak can become big prohibitively big.  
  
RelationCopyStorageUsingBuffer() acquired the buffer for the target relation  
with RBM_NORMAL, therefore requiring a read of a block guaranteed to be  
zero. Use RBM_ZERO_AND_LOCK instead.  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20230321070113.o2vqqxogjykwgfrr@awork3.anarazel.de  
Backpatch: 15-, where STRATEGY WAL_LOG was introduced  

commit   : a70e6e430628fe5ee802f47f4b043d33a0d41dda    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Mar 2023 18:32:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Mar 2023 18:32:02 +0900    

This commit adds some documentation about two monitoring functions:  
- pg_stat_get_xact_blocks_fetched()  
- pg_stat_get_xact_blocks_hit()  
  
The description of these functions has been removed in ddfc2d9, later  
simplified by 5f2b089, assuming that all the functions whose  
descriptions were removed are used in system views.  Unfortunately, some  
of them were are not used in any system views, so they lacked  
documentation.  
  
This gap exists in the docs for a long time, so backpatch all the way  
down.  
  
Reported-by: Michael Paquier  
Author: Bertrand Drouvot  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/ZBeeH5UoNkTPrwHO@paquier.xyz  
Backpatch-through: 11  

commit   : 3c12407f4cf735e17a8af54ab4306cd199601619    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 21 Mar 2023 09:40:41 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 21 Mar 2023 09:40:41 +0530    

We fail to apply updates and deletes when the REPLICA IDENTITY FULL is  
used for the table having dropped columns. We didn't use to ignore dropped  
columns while doing tuple comparison among the tuples from the publisher  
and subscriber during apply of updates and deletes.  
  
Author: Onder Kalaci, Shi yu  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com  

commit   : c03c6e8cf6a9118a3d1219ec0cb06b439db54100    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 21 Mar 2023 14:29:34 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 21 Mar 2023 14:29:34 +1300    

With unlucky timing and parallel_leader_participation=off (not the  
default), PHJ could attempt to access per-batch shared state just as it  
was being freed.  There was code intended to prevent that by checking  
for a cleared pointer, but it was racy.  Fix, by introducing an extra  
barrier phase.  The new phase PHJ_BUILD_RUNNING means that it's safe to  
access the per-batch state to find a batch to help with, and  
PHJ_BUILD_DONE means that it is too late.  The last to detach will free  
the array of per-batch state as before, but now it will also atomically  
advance the phase, so that late attachers can avoid the hazard.  This  
mirrors the way per-batch hash tables are freed (see phases  
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).  
  
An earlier attempt to fix this (commit 3b8981b6, later reverted) missed  
one special case.  When the inner side is empty (the "empty inner  
optimization), the build barrier would only make it to  
PHJ_BUILD_HASHING_INNER phase before workers attempted to detach from  
the hashtable.  In that case, fast-forward the build barrier to  
PHJ_BUILD_RUNNING before proceeding, so that our later assertions hold  
and we can still negotiate who is cleaning up.  
  
Revealed by build farm failures, where BarrierAttach() failed a sanity  
check assertion, because the memory had been clobbered by dsa_free().  
In non-assert builds, the result could be a segmentation fault.  
  
Back-patch to all supported releases.  
  
Author: Thomas Munro <thomas.munro@gmail.com>  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Reported-by: David Geier <geidav.pg@gmail.com>  
Tested-by: David Geier <geidav.pg@gmail.com>  
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz  

commit   : 0c7726c2827e3ff685c460acd757a4b0c7ee09f7    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 20 Mar 2023 09:51:50 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 20 Mar 2023 09:51:50 +0100    

When calculating distance in brin_minmax_multi_distance_inet(), the  
netmask was applied incorrectly. This results in (seemingly) incorrect  
ordering of values, triggering an assert.  
  
For builds without asserts this is mostly harmless - we may merge other  
ranges, possibly resulting in slightly less efficient index. But it's  
still correct and the greedy algorithm doesn't guarantee optimality  
anyway.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Reported by Dmitry Dolgov, investigation and fix by me.  
  
Reported-by: Dmitry Dolgov  
Backpatch-through: 14  
Discussion: https://postgr.es/m/17774-c6f3e36dd4471e67@postgresql.org  

commit   : 8de4660a57e6e165debc949d2cb922f60f8aa921    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 20 Mar 2023 13:30:15 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 20 Mar 2023 13:30:15 +1300    

When probing the Memoize cache to check if the current cache key values  
exist in the cache, we perform an evaluation of the expressions making up  
the cache key before probing the hash table for those values.  This  
operation could leak memory as it is possible that the cache key is an  
expression which requires allocation of memory, as was the case in bug  
17844.  
  
Here we fix this by correctly switching to the per tuple context before  
evaluating the cache expressions so that the memory is freed next time the  
per tuple context is reset.  
  
Bug: 17844  
Reported-by: Alexey Ermakov  
Discussion: https://postgr.es/m/17844-d2f6f9e75a622bed@postgresql.org  
Backpatch-through: 14, where Memoize was introduced  

commit   : 8995eac6c42465c2e866d3670fdb63f7bfbbabc2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Mar 2023 16:11:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Mar 2023 16:11:22 -0400    

Per report from rsindlin  
  
Discussion: https://postgr.es/m/167907221210.1803488.5939223864945604536@wrigleys.postgresql.org  

commit   : 8b87e92919cd0e8e8ffbae543d996063149c3ccc    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 17 Mar 2023 11:47:35 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 17 Mar 2023 11:47:35 -0700    

Check whether the datctype is C to determine whether t_isspace() and  
related functions use isspace() or iswspace().  
  
Previously, t_isspace() checked whether the database default collation  
was C; which is incorrect when the default collation uses the ICU  
provider.  
  
Discussion: https://postgr.es/m/79e4354d9eccfdb00483146a6b9f6295202e7890.camel@j-davis.com  
Reviewed-by: Peter Eisentraut  
Backpatch-through: 15  

commit   : 2b216da1e55dc125ada193328e87e471d49b0938    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Mar 2023 13:31:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Mar 2023 13:31:40 -0400    

Hash partitioning on an enum is problematic because the hash codes are  
derived from the OIDs assigned to the enum values, which will almost  
certainly be different after a dump-and-reload than they were before.  
This means that some rows probably end up in different partitions than  
before, causing restore to fail because of partition constraint  
violations.  (pg_upgrade dodges this problem by using hacks to force  
the enum values to keep the same OIDs, but that's not possible nor  
desirable for pg_dump.)  
  
Users can work around that by specifying --load-via-partition-root,  
but since that's a dump-time not restore-time decision, one might  
find out the need for it far too late.  Instead, teach pg_dump to  
apply that option automatically when dealing with a partitioned  
table that has hash-on-enum partitioning.  
  
Also deal with a pre-existing issue for --load-via-partition-root  
mode: in a parallel restore, we try to TRUNCATE target tables just  
before loading them, in order to enable some backend optimizations.  
This is bad when using --load-via-partition-root because (a) we're  
likely to suffer deadlocks from restore jobs trying to restore rows  
into other partitions than they came from, and (b) if we miss getting  
a deadlock we might still lose data due to a TRUNCATE removing rows  
from some already-completed restore job.  
  
The fix for this is conceptually simple: just don't TRUNCATE if we're  
dealing with a --load-via-partition-root case.  The tricky bit is for  
pg_restore to identify those cases.  In dumps using COPY commands we  
can inspect each COPY command to see if it targets the nominal target  
table or some ancestor.  However, in dumps using INSERT commands it's  
pretty impractical to examine the INSERTs in advance.  To provide a  
solution for that going forward, modify pg_dump to mark TABLE DATA  
items that are using --load-via-partition-root with a comment.  
(This change also responds to a complaint from Robert Haas that  
the dump output for --load-via-partition-root is pretty confusing.)  
pg_restore checks for the special comment as well as checking the  
COPY command if present.  This will fail to identify the combination  
of --load-via-partition-root and --inserts in pre-existing dump files,  
but that should be a pretty rare case in the field.  If it does  
happen you will probably get a deadlock failure that you can work  
around by not using parallel restore, which is the same as before  
this bug fix.  
  
Having done this, there seems no remaining reason for the alarmism  
in the pg_dump man page about combining --load-via-partition-root  
with parallel restore, so remove that warning.  
  
Patch by me; thanks to Julien Rouhaud for review.  Back-patch to  
v11 where hash partitioning was introduced.  
  
Discussion: https://postgr.es/m/1376149.1675268279@sss.pgh.pa.us  

commit   : ce29cea17fb323b67a6772e9acd1ec63e5c9a4b7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 23:03:31 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 23:03:31 -0700    

Unfortunately it turns out that the logfile-only option added in b9f8d1cbad7  
is only available in openldap starting in 2.6.  
  
Luckily the option to control the log level (loglevel/-s) have been around for  
much longer. As it turns out loglevel/-s only control what goes into syslog,  
not what ends up in the file specified with 'logfile' and stderr.  
  
While we currently are specifying 'logfile', nothing ends up in it, as the  
option only controls debug messages, and we didn't set a debug level. The  
debug level can only be configured on the commandline and also prevents  
forking. That'd require larger changes, so this commit doesn't tackle that  
issue.  
  
Specify the syslog level when starting slapd using -s, as that allows to  
prevent all syslog messages if one uses '0' instead of 'none', while loglevel  
doesn't prevent the first message.  
  
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de  
Backpatch: 11-  

commit   : 371e3daaa53d09f1f265865dc9bf0dbff57c46ab    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 17 Mar 2023 15:51:00 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 17 Mar 2023 15:51:00 +1300    

The logic added in 9d9c02ccd to determine when a qual can be used as a  
WindowClause run condition failed to correctly check for subqueries in the  
qual.  This was being done correctly for normal subquery qual pushdowns,  
it's just that 9d9c02ccd failed to follow the lead on that.  
  
This also fixes various other cases where transforming the qual into a  
WindowClause run condition in the subquery should have been disallowed.  
  
Bug: #17826  
Reported-by: Anban Company  
Discussion: https://postgr.es/m/17826-7d8750952f19a5f5@postgresql.org  
Backpatch-through: 15, where 9d9c02ccd was introduced.  

commit   : fd65711f3b662b69d4594f3be502c2be0409a4dc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 17:48:47 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 17:48:47 -0700    

Until now the tests using slapd spammed syslog for every connection /  
query. Use logfile-only to prevent syslog activity. Unfortunately that only  
takes effect after logging the first message, but that's still much better  
than the prior situation.  
  
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de  
Backpatch: 11-  

commit   : e8a774d00779af85863d2f798e6256ef7fb59e23    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 14:44:12 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 14:44:12 +1300    

Further to commit 6a9229da, checking for NULL is now redundant.  An "out  
of memory" error would have been thrown already by palloc() and treated  
as FATAL, so we can delete a few more lines.  
  
Back-patch to all releases, like those other commits.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/4040668.1679013388%40sss.pgh.pa.us  

commit   : fb1132e50fb856df1561ab5e43abfe07b03847ef    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 14:08:44 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 14:08:44 -0700    

gcc 12+ has complaints like the following:  
  
../../../../../pgsql/src/backend/utils/adt/network.c: In function 'inetnot':  
../../../../../pgsql/src/backend/utils/adt/network.c:1893:34: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]  
 1893 |                         pdst[nb] = ~pip[nb];  
      |                         ~~~~~~~~~^~~~~~~~~~  
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16  
   27 |         unsigned char ipaddr[16];       /* up to 128 bits of address */  
      |                       ^~~~~~  
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16  
  
This is due to a compiler bug:  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986  
  
It has been a year since the bug has been reported without getting fixed. As  
the warnings are verbose and use of gcc 12 is becoming more common, it seems  
worth working around the bug. Particularly because a simple reformulation of  
the loop condition fixes the issue and isn't any less readable.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/144536.1648326206@sss.pgh.pa.us  
Backpatch: 11-  

commit   : 75e7378f6e15271385d50543a031b1a3bee6be13    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 09:44:42 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 09:44:42 +1300    

A comment was left behind claiming that we needed to use malloc() rather  
than palloc() because the corresponding free would run in another  
thread, but that's not true anymore.  Remove that comment.  And, with  
the reason being gone, we might as well actually use palloc().  
  
Back-patch to supported releases, like d41a178b.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2BpdM9v3Jv4tc2BFx2jh_daY3uzUyAGBhtDkotEQDNPYw%40mail.gmail.com  

commit   : b0488cb5113746a2847964c5cb26e5dc0e302b55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Mar 2023 16:50:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Mar 2023 16:50:56 -0400    

Clarify that ATTACH/DETACH PARTITION can be used to perform partition  
maintenance with less locking than straight CREATE TABLE/DROP TABLE.  
This was already stated in some places, but not emphasized.  
  
Back-patch to v14 where DETACH PARTITION CONCURRENTLY was added.  
(We had lower lock levels for ATTACH PARTITION before that, but  
this wording wouldn't apply.)  
  
Justin Pryzby, reviewed by Robert Treat and Jakub Wartak;  
a little further wordsmithing by me  
  
Discussion: https://postgr.es/m/20220718143304.GC18011@telsasoft.com  

commit   : 3908d6ae115801cc61486b286ab71d91c2cdbb99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Mar 2023 11:59:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Mar 2023 11:59:18 -0400    

preprocess_targetlist thought PHVs couldn't appear here.  
It was mistaken, as per report from Önder Kalacı.  
  
Surveying other pull_var_clause calls, I noted no similar errors,  
but I did notice that qual_is_pushdown_safe's assertion about  
!contain_window_function was pointless, because the following  
pull_var_clause call would complain about them anyway.  In HEAD  
only, remove the redundant Assert and improve the commentary.  
  
Discussion: https://postgr.es/m/CACawEhUuum-gC_2S3sXLTcsk7bUSPSHOD+g1ZpfKaDK-KKPPWA@mail.gmail.com  

commit   : 69b6032e0d1dd7ceb7b42fa046e6e78a4df56af9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Mar 2023 12:56:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Mar 2023 12:56:06 +0900    

The current implementation of _pgfstat64() is ineffective in detecting a  
terminal handle or an anonymous named pipe.  This commit improves our  
port of fstat() to detect more efficiently such cases by relying on  
GetFileType(), and returning more correct data when the type found is  
either a FILE_TYPE_PIPE (_S_IFIFO) or a FILE_TYPE_CHAR (_S_IFCHR).  
  
This is part of a more global fix to address failures when feeding the  
output generated by pg_dump to pg_restore through a pipe, for example,  
but not all of it.   We are also going to need to do something about  
fseek() and ftello() which are not reliable on WIN32 for the same cases  
where fstat() was incorrect.  Fixing fstat() is independent of the rest,  
though, which is why both fixes are handled separately, and this is the  
first part of it.  
  
Reported-by: Daniel Watzinger  
Author: Daniel Watzinger, Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/b1448cd7-871e-20e3-8398-895e2d1d3bf9@gmail.com  
Backpatch-through: 14  

commit   : d9c9c43af5c8d873f46a4b0c969a68deddd010b6    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:57:00 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:57:00 +1300    

Commit 4753ef37 changed vacuum_delay_point() to use the WaitLatch() API,  
to fix the problem that vacuum could keep running for a very long time  
after the postmaster died.  
  
Unfortunately, that broke commit caf626b2's support for fractional  
vacuum_cost_delay, which shipped in PostgreSQL 12.  WaitLatch() works in  
whole milliseconds.  
  
For now, revert the change from commit 4753ef37, but add an explicit  
check for postmaster death.  That's an extra system call on systems  
other than Linux and FreeBSD, but that overhead doesn't matter much  
considering that we willingly went to sleep and woke up again.  (In  
later work, we might add higher resolution timeouts to the latch API so  
that we could do this with our standard programming pattern, but that  
wouldn't be back-patched.)  
  
Back-patch to 14, where commit 4753ef37 arrived.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg%40mail.gmail.com  

commit   : 06066915d48f072dcc5add048569ee7206772275    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:17:18 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:17:18 +1300    

Our waitpid() emulation didn't prevent a PID from being recycled by the  
OS before the call to waitpid().  The postmaster could finish up  
tracking more than one child process with the same PID, and confuse  
them.  
  
Fix, by moving the guts of pgwin32_deadchild_callback() into waitpid(),  
so that resources are released synchronously.  The process and PID  
continue to exist until we close the process handle, which only happens  
once we're ready to adjust our book-keeping of running children.  
  
This seems to explain a couple of failures on CI.  It had never been  
reported before, despite the code being as old as the Windows port.  
Perhaps Windows started recycling PIDs more rapidly, or perhaps timing  
changes due to commit 7389aad6 made it more likely to break.  
  
Thanks to Alexander Lakhin for analysis and Andres Freund for tracking  
down the root cause.  
  
Back-patch to all supported branches.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de  

commit   : a67c75f8258742945f4f3703126a1222adeeb85b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 19:17:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 19:17:31 -0400    

The band-aid applied in commit f0bedf3e4 turns out to still need  
some work: it made sure we didn't set Np->last_relevant too small  
(to the left of the decimal point), but it didn't prevent setting  
it too large (off the end of the partially-converted string).  
This could result in fetching data beyond the end of the allocated  
space, which with very bad luck could cause a SIGSEGV, though  
I don't see any hazard of interesting memory disclosure.  
  
Per bug #17839 from Thiago Nunes.  The bug's pretty ancient,  
so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/17839-aada50db24d7b0da@postgresql.org  

commit   : 3b459444301c4c40e8d978ef6025c7177c85c017    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 11:10:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 11:10:45 -0400    

Scanning the expression for compatible Vars isn't really necessary,  
because the subsequent match against StatisticExtInfo entries will  
eliminate expressions containing other Vars just fine.  Moreover,  
this code hadn't stopped to think about what to do with  
PlaceHolderVars or Aggrefs in the clause; and at least for the PHV  
case, that demonstrably leads to failures.  Rather than work out  
whether it's reasonable to ignore those, let's just remove the  
whole stanza.  
  
Per report from Richard Guo.  Back-patch to v14 where this code  
was added.  
  
Discussion: https://postgr.es/m/CAMbWs48Mmvm-acGevXuwpB=g5JMqVSL6i9z5UaJyLGJqa-XPAA@mail.gmail.com  

commit   : 74a1a36d755bf5a5c656d78ef7f1df1cfeeeeb20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 15:19:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 15:19:00 -0400    

The majority of error exit cases in json_lex_string() failed to  
set lex->token_terminator, causing problems for the error context  
reporting code: it would see token_terminator less than token_start  
and do something more or less nuts.  In v14 and up the end result  
could be as bad as a crash in report_json_context().  Older  
versions accidentally avoided that fate; but all versions produce  
error context lines that are far less useful than intended,  
because they'd stop at the end of the prior token instead of  
continuing to where the actually-bad input is.  
  
To fix, invent some macros that make it less notationally painful  
to do the right thing.  Also add documentation about what the  
function is actually required to do; and in >= v14, add an assertion  
in report_json_context about token_terminator being sufficiently  
far advanced.  
  
Per report from Nikolay Shaplov.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/7332649.x5DLKWyVIX@thinkpad-pgpro  

commit   : 5fd61bdc114f85ce57da1f139c8bda0f41d1951b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 12:40:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 12:40:28 -0400    

check_agg_arguments_walker() supposed that it needn't descend into  
the arguments of a lower-level aggregate function, but this is  
just wrong in the presence of multiple levels of sub-select.  The  
oversight would lead to executor failures on queries that should  
be rejected.  (Prior to v11, they actually were rejected, thanks  
to a "redundant" execution-time check.)  
  
Per bug #17835 from Anban Company.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17835-4f29f3098b2d0ba4@postgresql.org  

commit   : da6257eee35db5d281a115838abaf285b46b52f3    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 11:11:10 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 11:11:10 +0000    

This ensures that the row count in the command tag for a MERGE is  
correctly computed in the case where UPDATEs or DELETEs are skipped  
due to a BEFORE ROW trigger returning NULL (the INSERT case was  
already handled correctly by ExecMergeNotMatched() calling  
ExecInsert()).  
  
Back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCU8XEmR0JWKDtyb7iZ%3DqCffxS9uyJt0iOZ4TV4RT%2Bow1w%40mail.gmail.com  

commit   : 7d9a75713ab91071a2110e25e7c86cbf2a6fdc4b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 10:23:42 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 10:23:42 +0000    

If MERGE attempts an UPDATE or DELETE on a table with BEFORE ROW  
triggers, or a cross-partition UPDATE (with or without triggers), and  
a concurrent UPDATE or DELETE happens, the merge code would fail.  
  
In some cases this would lead to a crash, while in others it would  
cause the wrong merge action to be executed, or no action at all. The  
immediate cause of the crash was the trigger code calling  
ExecGetUpdateNewTuple() as part of the EPQ mechanism, which fails  
because during a merge ri_projectNew is NULL, since merge has its own  
per-action projection information, which ExecGetUpdateNewTuple() knows  
nothing about.  
  
Fix by arranging for the trigger code to exit early, returning the  
TM_Result and TM_FailureData information, if a concurrent modification  
is detected, allowing the merge code to do the necessary EPQ handling  
in its own way. Similarly, prevent the cross-partition update code  
from doing any EPQ processing for a merge, allowing the merge code to  
work out what it needs to do.  
  
This leads to a number of simplifications in nodeModifyTable.c. Most  
notably, the ModifyTableContext->GetUpdateNewTuple() callback is no  
longer needed, and mergeGetUpdateNewTuple() can be deleted, since  
there is no longer any requirement for get-update-new-tuple during a  
merge. Similarly, ModifyTableContext->cpUpdateRetrySlot is no longer  
needed. Thus ExecGetUpdateNewTuple() and the retry_slot handling of  
ExecCrossPartitionUpdate() can be restored to how they were in v14,  
before the merge code was added, and ExecMergeMatched() no longer  
needs any special-case handling for cross-partition updates.  
  
While at it, tidy up ExecUpdateEpilogue() a bit, making it handle  
recheckIndexes locally, rather than passing it in as a parameter,  
ensuring that it is freed properly. This dates back to when it was  
split off from ExecUpdate() to support merge.  
  
Per bug #17809 from Alexander Lakhin, and follow-up investigation of  
bug #17792, also from Alexander Lakhin.  
  
Back-patch to v15, where MERGE was introduced, taking care to preserve  
backwards-compatibility of the trigger API in v15 for any extensions  
that might use it.  
  
Discussion:  
  https://postgr.es/m/17809-9e6650bef133f0fe%40postgresql.org  
  https://postgr.es/m/17792-0f89452029662c36%40postgresql.org  

commit   : 4493256c5c0b0dace8cec76d5c3962f50ea28144    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Mar 2023 16:36:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Mar 2023 16:36:28 +0900    

The error cases for TLS and GSS encryption were inconsistent.  After TLS  
fails, the connection is marked as dead and follow-up calls of  
PQconnectPoll() would return immediately, but GSS encryption was not  
doing that, so the connection would still have been allowed to enter the  
GSS handling code.  This was handled incorrectly when gssencmode was set  
to "require".  "prefer" was working correctly, and this could not happen  
under "disable" as GSS encryption would not be attempted.  
  
This commit makes the error handling of GSS encryption on par with TLS  
portion, fixing the case of gssencmode=require.  
  
Reported-by: Jacob Champion  
Author: Michael Paquier  
Reviewed-by: Jacob Champion, Stephen Frost  
Discussion: https://postgr.es/m/23787477-5fe1-a161-6d2a-e459f74c4713@timescale.com  
Backpatch-through: 12  

commit   : 9e236f94367639308cff62a33bc1ed815cf0f50c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 12 Mar 2023 09:00:32 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 12 Mar 2023 09:00:32 -0400    

This was an omission in the original creation of the module.  
  
Also slightly adjust some wording to avoid a double "is".  
  
Backpatch the non-meson piece of this to release 12, where the module  
was introduced.  
  
Discussion: https://postgr.es/m/be869e1c-8e3f-4cde-8609-212c899cccf9@dunslane.net  

commit   : e8a9750d03d70de4ecd5aee37971498d90aabca5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    

64bit xids can't represent xids before epoch 0 (see also be504a3e974). When  
FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit  
xid far into the future. Noticed while adding assertions in the course of  
investigating be504a3e974, as amcheck's test create such xids.  
  
To fix the issue, just return FirstNormalFullTransactionId in this case. A  
freshly initdb'd cluster already has a newer horizon. The most minimal version  
of this would make the messages for some detected corruptions differently  
inaccurate. To make those cases accurate, switch  
FullTransactionIdFromXidAndCtx() to use the 32bit modulo difference between  
xid and nextxid to compute the 64bit xid, yielding sensible "in the future" /  
"in the past" answers.  
  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de  
Backpatch: 14-, where heapam verification was introduced  

commit   : 6d9588108a5644800b0047ccb666f70373164f68    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    

The initialization order in update_cached_xid_range() was wrong, calling  
FullTransactionIdFromXidAndCtx() before setting  
->next_xid. FullTransactionIdFromXidAndCtx() uses ->next_xid.  
  
In most situations this will not cause visible issues, because the next call  
to update_cached_xid_range() will use a less wrong ->next_xid. It's rare that  
xids advance fast enough for this to be a problem.  
  
Found while adding more asserts to the 64bit xid infrastructure.  
  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de  
Backpatch: 14-, where heapam verification was introduced  

commit   : 6170386c7fc1c1cfd7c2a655b8107872d18a0193    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Mar 2023 12:15:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Mar 2023 12:15:41 -0500    

If the regex compiler can see that a regex is unsatisfiable  
(for example, '$foo') then it may emit an NFA having no arcs.  
pg_trgm's packGraph function did the wrong thing in this case;  
it would access off the end of a work array, and with bad luck  
could produce a corrupted output data structure causing more  
problems later.  This could end with wrong answers or crashes  
in queries using a pg_trgm GIN or GiST index with such a regex.  
  
Fix by not trying to de-duplicate if there aren't at least 2 arcs.  
  
Per bug #17830 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17830-57ff5f89bdb02b09@postgresql.org  

commit   : 59947bac7384ac56b5c95c69dee7655e2ed810df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Mar 2023 13:52:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Mar 2023 13:52:28 -0500    

The COPY documentation is quite clear that "COPY relation TO" copies  
rows from only the named table, not any inheritance children it may  
have.  However, if you enabled row-level security on the table then  
this stopped being true, because the code forgot to apply the ONLY  
modifier in the "SELECT ... FROM relation" query that it constructs  
in order to allow RLS predicates to be attached.  Fix that.  
  
Report and patch by Antonin Houska (comment adjustments and test case  
by me).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3472.1675251957@antos  

commit   : af397c6c27b70b422f81151452640ae8e1261e54    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Mar 2023 16:33:24 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Mar 2023 16:33:24 +1300    

Commit bdaabb9b started skipping doomed transactions when building the  
list of possible conflicts for SERIALIZABLE READ ONLY.  That makes  
sense, because doomed transactions won't commit, but a couple of subtle  
things broke:  
  
1.  If all uncommitted r/w transactions are doomed, a READ ONLY  
transaction would arbitrarily not benefit from the safe snapshot  
optimization.  It would not be taken immediately, and yet no other  
transaction would set SXACT_FLAG_RO_SAFE later.  
  
2.  In the same circumstances but with DEFERRABLE, GetSafeSnapshot()  
would correctly exit its wait loop without sleeping and then take the  
optimization in non-assert builds, but assert builds would fail a sanity  
check that SXACT_FLAG_RO_SAFE had been set by another transaction.  
  
This is similar to the case for PredXact->WritableSxactCount == 0.  We  
should opt out immediately if our possibleUnsafeConflicts list is empty  
after filtering.  
  
The code to maintain the serializable global xmin is moved down below  
the new opt out site, because otherwise we'd have to reverse its effects  
before returning.  
  
Back-patch to all supported releases.  Bug #17368.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org  
Discussion: https://postgr.es/m/20110707212159.GF76634%40csail.mit.edu  

commit   : 391f08fd68047881345a69e5a7fff173d8f9c897    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Mar 2023 21:36:48 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Mar 2023 21:36:48 -0800    

When vacuum_defer_cleanup_age is bigger than the current xid, including the  
epoch, the subtraction of vacuum_defer_cleanup_age would lead to a wrapped  
around xid. While that normally is not a problem, the subsequent conversion to  
a 64bit xid results in a 64bit-xid very far into the future. As that xid is  
used as a horizon to detect whether rows versions are old enough to be  
removed, that allows removal of rows that are still visible (i.e. corruption).  
  
If vacuum_defer_cleanup_age was never changed from the default, there is no  
chance of this bug occurring.  
  
This bug was introduced in dc7420c2c92.  A lesser version of it exists in  
12-13, introduced by fb5344c969a, affecting only GiST.  
  
The 12-13 version of the issue can, in rare cases, lead to pages in a gist  
index getting recycled too early, potentially causing index entries to be  
found multiple times.  
  
The fix is fairly simple - don't allow vacuum_defer_cleanup_age to retreat  
further than FirstNormalTransactionId.  
  
Patches to make similar bugs easier to find, by adding asserts to the 64bit  
xid infrastructure, have been proposed, but are not suitable for backpatching.  
  
Currently there are no tests for vacuum_defer_cleanup_age. A patch introducing  
infrastructure to make writing a test easier has been posted to the list.  
  
Reported-by: Michail Nikolaev <michail.nikolaev@gmail.com>  
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de  
Backpatch: 12-, but impact/fix is smaller for 12-13  

commit   : 76d2177fb693f8d35ee87a42d7801f4965ff3ad4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Mar 2023 18:21:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Mar 2023 18:21:37 -0500    

If a view is defined atop another view, and then CREATE OR REPLACE  
VIEW is used to add columns to the lower view, then when the upper  
view's referencing RTE is expanded by ApplyRetrieveRule we will have  
a subquery RTE with fewer eref->colnames than output columns.  This  
confuses various code that assumes those lists are always in sync,  
as they are in plain parser output.  
  
We have seen such problems before (cf commit d5b760ecb), and now  
I think the time has come to do what was speculated about in that  
commit: let's make ApplyRetrieveRule synthesize some column names to  
preserve the invariant that holds in parser output.  Otherwise we'll  
be chasing this class of bugs indefinitely.  Moreover, it appears from  
testing that this actually gives us better results in the test case  
d5b760ecb added, and likely in other corner cases that we lack  
coverage for.  
  
In HEAD, I replaced d5b760ecb's hack to make expandRTE exit early with  
an elog(ERROR) call, since the case is now presumably unreachable.  
But it seems like changing that in back branches would bring more risk  
than benefit, so there I just updated the comment.  
  
Per bug #17811 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17811-d31686b78f0dffc9@postgresql.org  

commit   : ae4860183213518c2578d0fabb365ac3a8214f45    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Mar 2023 19:30:14 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Mar 2023 19:30:14 +0100    

Missing documentation update for ca2e4472ba.  
  
Discussion: https://www.postgresql.org/message-id/CAApHDvrCwMgSD_93LZr4CLMas8Hc61fXAQ-Cd4%3D%2ByoRfHnYbJA%40mail.gmail.com  

commit   : 70ef509543fab4c35f79e73dd2b309cc75ceed51    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2023 18:31:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2023 18:31:16 -0500    

If UPDATE is forced to retry after an EvalPlanQual check, it neglected  
to repeat GENERATED-column computations, even though those might well  
have changed since we're dealing with a different tuple than before.  
Fixing this is mostly a matter of looping back a bit further when  
we retry.  In v15 and HEAD that's most easily done by altering the API  
of ExecUpdateAct so that it includes computing GENERATED expressions.  
  
Also, if an UPDATE in a partitioned table turns into a cross-partition  
INSERT operation, we failed to recompute GENERATED columns.  That's a  
bug since 8bf6ec3ba allowed partitions to have different generation  
expressions; although it seems to have no ill effects before that.  
Fixing this is messier because we can now have situations where the same  
query needs both the UPDATE-aligned set of GENERATED columns and the  
INSERT-aligned set, and it's unclear which set will be generated first  
(else we could hack things by forcing the INSERT-aligned set to be  
generated, which is indeed how fe9e658f4 made it work for MERGE).  
The best fix seems to be to build and store separate sets of expressions  
for the INSERT and UPDATE cases.  That would create ABI issues in the  
back branches, but so far it seems we can leave this alone in the back  
branches.  
  
Per bug #17823 from Hisahiro Kauchi.  The first part of this affects all  
branches back to v12 where GENERATED columns were added.  
  
Discussion: https://postgr.es/m/17823-b64909cf7d63de84@postgresql.org  

commit   : 349803b18fee2476c7c9c84039d04c900ce8d499    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 2 Feb 2023 12:04:16 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 2 Feb 2023 12:04:16 -0500    

We read blocks of data from files that we're backing up in chunks,  
some multiple of BLCKSZ for each read. If checksum verification fails,  
we then try rereading just the one block for which validation failed.  
If that block happened to be the first block of the chunk, and if  
the file was concurrently truncated to remove that block, then we'd  
reach a call to bbsink_archive_contents() with a buffer length of 0.  
That causes an assertion failure.  
  
As far as I can see, there are no particularly bad consequences if  
this happens in a non-assert build, and it's pretty unlikely to happen  
in the first place because it requires a series of somewhat unlikely  
things to happen in very quick succession. However, assertion failures  
are bad, so rearrange the code to avoid that possibility.  
  
Patch by me, reviewed by Michael Paquier.  
  
Discussion: http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com  

commit   : 055990904a179416453e024ae0be8791ba70a235    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 6 Mar 2023 15:07:15 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 6 Mar 2023 15:07:15 +1300    

1.  Make sure that we don't decrement SxactGlobalXminCount twice when  
the SXACT_FLAG_RO_SAFE optimization is reached in a parallel query.  
This could trigger a sanity check failure in assert builds.  Non-assert  
builds recompute the count in SetNewSxactGlobalXmin(), so the problem  
was hidden, explaining the lack of field reports.  Add a new isolation  
test to exercise that case.  
  
2.  Remove an assertion that the DOOMED flag can't be set on a partially  
released SERIALIZABLEXACT.  Instead, ignore the flag (our transaction  
was already determined to be read-only safe, and DOOMED is in fact set  
during partial release, and there was already an assertion that it  
wasn't set sooner).  Improve an existing isolation test so that it  
reaches that case (previously it wasn't quite testing what it was  
supposed to be testing; see discussion).  
  
Back-patch to 12.  Bug #17116.  Defects in commit 47a338cf.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org  

commit   : f61e60102f08305f3cb9e55a7958b8036a02fe39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Mar 2023 13:32:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Mar 2023 13:32:35 -0500    

Beginning in v15, if you apply ALTER TABLE ENABLE/DISABLE TRIGGER to  
a partitioned table, it also affects the partitions' cloned versions  
of the affected trigger(s).  The initial implementation of this  
located the clones by name, but that fails on foreign-key triggers  
which have names incorporating their own OIDs.  We can fix that, and  
also make the behavior more bulletproof in the face of user-initiated  
trigger renames, by identifying the cloned triggers by tgparentid.  
  
Following the lead of earlier commits in this area, I took care not  
to break ABI in the v15 branch, even though I rather doubt there  
are any external callers of EnableDisableTrigger.  
  
While here, update the documentation, which was not touched when  
the semantics were changed.  
  
Per bug #17817 from Alan Hodgson.  Back-patch to v15; older versions  
do not have this behavior.  
  
Discussion: https://postgr.es/m/17817-31dfb7c2100d9f3d@postgresql.org  

commit   : 9d41ecfcd9a7cb4ec6b20add4a55603ebba03f0d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Mar 2023 14:03:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Mar 2023 14:03:08 +0900    

Attempting to use this function with a raw page not coming from a GiST  
index would cause a crash, as it was missing the same sanity checks as  
gist_page_items_bytea().  This slightly refactors the code so as all the  
basic validation checks for GiST pages are done in a single routine,  
in the same fashion as the pageinspect functions for hash and BRIN.  
  
This fixes an issue similar to 076f4d9.  A test is added to stress for  
this case.  While on it, I have added a similar test for  
brin_page_items() with a combination make of a valid GiST index and a  
raw btree page.  This one was already protected, but it was not tested.  
  
Reported-by: Egor Chindyaskin  
Author: Dmitry Koval  
Discussion: https://postgr.es/m/17815-fc4a2d3b74705703@postgresql.org  
Backpatch-through: 14  

commit   : eae09137d53ecb9cb4c1ba7624723f1c1cbebeec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Mar 2023 11:30:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Mar 2023 11:30:17 -0500    

This is usually harmless, but if you were very unlucky it could  
provoke a segfault due to the "to" string being right up against  
the end of memory.  Found via valgrind testing (so we might've  
found it earlier, except that our regression tests lacked any  
exercise of translate()'s deletion feature).  
  
Fix by switching the order of the test-for-end-of-string and  
advance-pointer steps.  While here, compute "to_ptr + tolen"  
just once.  (Smarter compilers might figure that out for  
themselves, but let's just make sure.)  
  
Report and fix by Daniil Anisimov, in bug #17816.  
  
Discussion: https://postgr.es/m/17816-70f3d2764e88a108@postgresql.org  

commit   : b5784e6a5ecd81468462a91486266adc87d03110    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Mar 2023 08:38:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Mar 2023 08:38:55 +0900    

end_lsn was mentioned as an input parameter, but that should not be the  
case.  Error introduced in 58597ed.  
  
Author: Nathan Bossart  
Discussion: https://postgr.es/m/20230228195740.GA1397484@nathanxps13  
Backpatch-through: 15  

commit   : b15db7f6905acb0c40e651bef54d86ffe4b30d39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 20:27:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 20:27:48 -0500    

The view just added by commit 53fe7e6cb decompiles differently  
in v15 than HEAD (presumably as a consequence of 47bb9db75).  
That causes failures in cross-version upgrade testing.  
  
We could teach AdjustUpgrade.pm to compensate for that, but it  
seems less painful to just drop the view after we're done with it.  
  
Per buildfarm.  

commit   : bc77be7145e1dfa9296cd219a269c40b6c1d9f9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 16:29:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 16:29:51 -0500    

postgres_fdw will close its remote session if an sinval cache reset  
occurs, since it's possible that that means some FDW parameters  
changed.  We had two tests that were trying to ensure that the  
session remains alive by setting debug_discard_caches = 0; but  
that's not sufficient.  Even though the tests seem stable enough  
in the buildfarm, they flap a lot under CI.  
  
In the first test, which is checking the ability to recover from  
a lost connection, we can stabilize the results by just not  
caring whether pg_terminate_backend() finds a victim backend.  
If a reset did happen, there won't be a session to terminate  
anymore, but the test can proceed anyway.  (Arguably, we are  
then not testing the unintentional-disconnect case, but as long  
as that scenario is exercised in most runs I think it's fine;  
testing the reset-driven case is of value too.)  
  
In the second test, which is trying to verify the application_name  
displayed in pg_stat_activity by a remote session, we had a race  
condition in that the remote session might go away before we can  
fetch its pg_stat_activity entry.  We can close that race and make  
the test more certainly test what it intends to by arranging things  
so that the remote session itself fetches its pg_stat_activity entry  
(based on PID rather than a somewhat-circular assumption about the  
application name).  
  
Both tests now demonstrably pass under debug_discard_caches = 1,  
so we can remove that hack.  
  
Back-patch into relevant back branches.  
  
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de  

commit   : 696fa4749b98035f6d8967df77332496bdf970ac    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 Feb 2023 06:48:41 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 Feb 2023 06:48:41 -0500    

It's been this way for a very long time, but it appears to have been  
masking an issue that only manifests with different settings. Therefore,  
run the tests in the installation's default encoding/locale.  
  
Backpatch to all live branches.  

commit   : a6864751cd11ae99c16da48d603fafa55ce8e57e    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 26 Feb 2023 09:04:04 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 26 Feb 2023 09:04:04 +0000    

Update a few places in the documentation that should mention MERGE  
among the list of applicable commands. In a couple of places, a  
slightly more detailed description of what happens for MERGE seems  
appropriate.  
  
Reviewed by Alvaro Herrera.  
  
Discussion: http://postgr.es/m/CAEZATCWqHLcxab89ATMQZNGFG_mxDPM%2BjzkSbXKD3JYPfRGvtw%40mail.gmail.com  

commit   : a033f9165c2c024756d9cd3033263724d53fd9ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Feb 2023 14:44:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Feb 2023 14:44:14 -0500    

We already tried to fix this in commits 3f7323cbb et al (and follow-on  
fixes), but now it emerges that there are still unfixed cases;  
moreover, these cases affect all branches not only pre-v14.  I thought  
we had eliminated all cases of making multiple clones of an UPDATE's  
target list when we nuked inheritance_planner.  But it turns out we  
still do that in some partitioned-UPDATE cases, notably including  
INSERT ... ON CONFLICT UPDATE, because ExecInitPartitionInfo thinks  
it's okay to clone and modify the parent's targetlist.  
  
This fix is based on a suggestion from Andres Freund: let's stop  
abusing the ParamExecData.execPlan mechanism, which was only ever  
meant to handle initplans, and instead solve the execution timing  
problem by having the expression compiler move MULTIEXPR_SUBLINK steps  
to the front of their expression step lists.  This is feasible because  
(a) all branches still in support compile the entire targetlist of  
an UPDATE into a single ExprState, and (b) we know that all  
MULTIEXPR_SUBLINKs do need to be evaluated --- none could be buried  
inside a CASE, for example.  There is a minor semantics change  
concerning the order of execution of the MULTIEXPR's subquery versus  
other parts of the parent targetlist, but that seems like something  
we can get away with.  By doing that, we no longer need to worry  
about whether different clones of a MULTIEXPR_SUBLINK share output  
Params; their usage of that data structure won't overlap.  
  
Per bug #17800 from Alexander Lakhin.  Back-patch to all supported  
branches.  In v13 and earlier, we can revert 3f7323cbb and follow-on  
fixes; however, I chose to keep the SubPlan.subLinkId field added  
in ccbb54c72.  We don't need that anymore in the core code, but it's  
cheap enough to fill, and removing a plan node field in a minor  
release seems like it'd be asking for trouble.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/17800-ff90866b3906c964@postgresql.org  

commit   : 8e5b4e0013a8a24644243cdb9516ac52287a81c8    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Feb 2023 14:43:57 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Feb 2023 14:43:57 +0000    

If a rule action contains a subquery that refers to columns from OLD  
or NEW, then those are really lateral references, and the planner will  
complain if it sees such things in a subquery that isn't marked as  
lateral. However, at rule-definition time, the user isn't required to  
mark the subquery with LATERAL, and so it can fail when the rule is  
used.  
  
Fix this by marking such subqueries as lateral in the rewriter, at the  
point where they're used.  
  
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/5e09da43-aaba-7ea7-0a51-a2eb981b058b%40gmail.com  

commit   : cef1c9c0cf6e50ebe6d578d93a5d89e40774f764    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Feb 2023 15:40:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Feb 2023 15:40:28 -0500    

Multiple cycles of starting up and shutting down the plugin within a  
single session would eventually lead to "out of relcache_callback_list  
slots", because pgoutput_startup blindly re-registered its cache  
callbacks each time.  Fix it to register them only once, as all other  
users of cache callbacks already take care to do.  
  
This has been broken all along, so back-patch to all supported branches.  
  
Shi Yu  
  
Discussion: https://postgr.es/m/OSZPR01MB631004A78D743D68921FFAD3FDA79@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : 940b5474365fa87ef4aad7abeee070e8e49cc9d5    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 23 Feb 2023 10:54:51 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 23 Feb 2023 10:54:51 +0000    

Given an updatable view with a DO ALSO INSERT ... SELECT rule, a  
multi-row INSERT ... VALUES query on the view fails if the VALUES list  
contains any DEFAULTs that are not replaced by view defaults. This  
manifests as an "unrecognized node type" error, or an Assert failure,  
in an assert-enabled build.  
  
The reason is that when RewriteQuery() attempts to replace the  
remaining DEFAULT items with NULLs in any product queries, using  
rewriteValuesRTEToNulls(), it assumes that the VALUES RTE is located  
at the same rangetable index in each product query. However, if the  
product query is an INSERT ... SELECT, then the VALUES RTE is actually  
in the SELECT part of that query (at the same index), rather than the  
top-level product query itself.  
  
Fix, by descending to the SELECT in such cases. Note that we can't  
simply use getInsertSelectQuery() for this, since that expects to be  
given a raw rule action with OLD and NEW placeholder entries, so we  
duplicate its logic instead.  
  
While at it, beef up the checks in getInsertSelectQuery() by checking  
that the jointree->fromlist node is indeed a RangeTblRef, and that the  
RTE it points to has rtekind == RTE_SUBQUERY.  
  
Per bug #17803, from Alexander Lakhin. Back-patch to all supported  
branches.  
  
Dean Rasheed, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org  

commit   : 949ac32e12674d9c0bcd3d95ea5e56338a567a18    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 22 Feb 2023 15:24:09 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 22 Feb 2023 15:24:09 +0100    

Whe decoding a transactional logical message, logicalmsg_decode called  
SnapBuildGetOrBuildSnapshot. But we may not have a consistent snapshot  
yet at that point. We don't actually need the snapshot in this case  
(during replay we'll have the snapshot from the transaction), so in  
practice this is harmless. But in assert-enabled build this crashes.  
  
Fixed by requesting the snapshot only in non-transactional case, where  
we are guaranteed to have SNAPBUILD_CONSISTENT.  
  
Backpatch to 11. The issue exists since 9.6.  
  
Backpatch-through: 11  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/84d60912-6eab-9b84-5de3-41765a5449e8@enterprisedb.com  

commit   : 576b25bfd0e9a1d5bbc54931e888135bc6da8a2f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 13:24:51 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 13:24:51 +0000    

SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,  
and in v15 and later, it was missing support for SPI_OK_MERGE, as was  
pltcl_process_SPI_result().  
  
The last of those would trigger an error if a MERGE was executed from  
PL/Tcl. The others seem fairly innocuous, but worth fixing.  
  
Back-patch to all supported branches. Before v15, this is just adding  
SPI_OK_TD_REGISTER to SPI_result_code_string(), which is unlikely to  
be seen by anyone, but seems worth doing for completeness.  
  
Reviewed by Tom Lane.  
  
Discussion:  
  https://postgr.es/m/CAEZATCUg8V%2BK%2BGcafOPqymxk84Y_prXgfe64PDoopjLFH6Z0Aw%40mail.gmail.com  
  https://postgr.es/m/CAEZATCUMe%2B_KedPMM9AxKqm%3DSZogSxjUcrMe%2BsakusZh3BFcQw%40mail.gmail.com  

commit   : d8c3b65db58db0a074dc9f7e27846e22e9dc579f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 10:54:57 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 10:54:57 +0000    

In ExecInitPartitionInfo(), the Assert when building the WITH CHECK  
OPTION list for the new partition assumed that the command would be an  
INSERT or UPDATE, but it can also be a MERGE. This can be triggered by  
a MERGE into a partitioned table with RLS checks to enforce.  
  
Fix, and back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWWFtQmW67F3XTyMU5Am10Oxa_b8oe0x%2BNu5Mo%2BCdRErg%40mail.gmail.com  

commit   : 018af1cc1c8075346e6a5fe3bb77b7e31399be70    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 09:41:28 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 09:41:28 +0000    

This ensures that the row count in the command tag for a MERGE is  
correctly computed. Previously, if MERGE updated a partitioned table,  
the row count would be incorrect if any row was moved to a different  
partition, since such updates were counted twice.  
  
Back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWRMG7XX2QEsVL1LswmNo2d_YG8tKTLkpD3=Lp644S7rg@mail.gmail.com  

commit   : fa5dd460c1805a00a6fcc909b7e1f826663bcce3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Feb 2023 10:14:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Feb 2023 10:14:56 +0900    

WAL_LOG does a scan of the template's pg_class to determine the set of  
relations that need to be copied from a template database to the new  
one.  However, as coded in 9c08aea, this copy strategy would load the  
pages of pg_class without considering it as a permanent relation,  
causing the loaded pages to never be flushed when they should.  Any  
modification of the template's pg_class, mostly through DDLs, would then  
be missed, causing corruptions.  
  
STRATEGY = WAL_LOG is the default over FILE_COPY since it has been  
introduced, so any changes done to pg_class on a database template would  
be gone.  Updates of database templates should be a rare thing, so the  
impact of this bug should be hopefully limited.  The pre-14 default  
strategy FILE_COPY is safe, and can be used as a workaround.  
  
Ryo Matsumura has found and analyzed the issue, and Nathan has written a  
test able to reproduce the failure (with few tweaks from me).  
  
Backpatch down to 15, where STRATEGY = WAL_LOG has been introduced.  
  
Author: Nathan Bossart, Ryo Matsumura  
Reviewed-by: Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/TYCPR01MB6868677E499C9AD5123084B5E8A39@TYCPR01MB6868.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : f6a55c1d5593acdc2b35458d2229ae5ca38be709    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Feb 2023 18:47:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Feb 2023 18:47:46 -0500    

If asked to decrease the size of a large (>8K) palloc chunk,  
AllocSetRealloc could improperly change the Valgrind state of memory  
beyond the new end of the chunk: it would mark data UNDEFINED as far  
as the old end of the chunk after having done the realloc(3) call,  
thus tromping on the state of memory that no longer belongs to it.  
One would normally expect that memory to now be marked NOACCESS,  
so that this mislabeling might prevent detection of later errors.  
If realloc() had chosen to move the chunk someplace else (unlikely,  
but well within its rights) we could also mismark perfectly-valid  
DEFINED data as UNDEFINED, causing false-positive valgrind reports  
later.  Also, any malloc bookkeeping data placed within this area  
might now be wrongly marked, causing additional problems.  
  
Fix by replacing relevant uses of "oldsize" with "Min(size, oldsize)".  
It's sufficient to mark as far as "size" when that's smaller, because  
whatever remains in the new chunk size will be marked NOACCESS below,  
and we expect realloc() to have taken care of marking the memory  
beyond the new official end of the chunk.  
  
While we're here, also rename the function's "oldsize" variable  
to "oldchksize" to more clearly explain what it actually holds,  
namely the distance to the end of the chunk (that is, requested size  
plus trailing padding).  This is more consistent with the use of  
"size" and "chksize" to hold the new requested size and chunk size.  
Add a new variable "oldsize" in the one stanza where we're actually  
talking about the old requested size.  
  
Oversight in commit c477f3e44.  Back-patch to all supported branches,  
as that was, just in case anybody wants to do valgrind testing on back  
branches.  
  
Karina Litskevich  
  
Discussion: https://postgr.es/m/CACiT8iaAET-fmzjjZLjaJC4zwSJmrFyL7LAdHwaYyjjQOQ4hcg@mail.gmail.com  

commit   : 5bace41abc317ae8ecf3397e9e92f3b0e5444c69    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Feb 2023 20:02:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Feb 2023 20:02:09 +0900    

postgres_fdw.application_name relies on MyProcPort to define the data  
that should be added to escape sequences %u (user name) or %d (database  
name).  However this code could be run in processes that lack a  
MyProcPort, like an autovacuum process, causing crashes.  
  
The code generating the application name is made more flexible with this  
commit, so as it now generates no data for %u and %d if MyProcPort is  
missing, and a simple "unknown" if MyProcPort exists, but the expected  
fields are not set.  
  
Reported-by: Alexander Lakhin  
Author: Kyotaro Horiguchi, Michael Paquier  
Reviewed-by: Hayato Kuroda, Masahiko Sawada  
Discussion: https://postgr.es/m/17789-8b31c5a4672b74d9@postgresql.org  
Backpatch-through: 15  

commit   : 108a22bd14d4deb98340deec422cfec6d3b37840    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Feb 2023 10:56:37 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Feb 2023 10:56:37 +0100    

Failing to do so results in an error when a pgbench script tries to  
start a serializable transaction inside a pipeline, because by the time  
BEGIN ISOLATION LEVEL SERIALIZABLE is executed, we're already in a  
transaction that has acquired a snapshot, so the server rightfully  
complains.  
  
We can work around that by preparing all commands in the pipeline before  
actually starting the pipeline.  This changes the existing code in two  
aspects: first, we now prepare each command individually at the point  
where that command is about to be executed; previously, we would prepare  
all commands in a script as soon as the first command of that script  
would be executed.  It's hard to see that this would make much of a  
difference (particularly since it only affects the first time to execute  
each script in a client), but I didn't actually try to measure it.  
  
Secondly, we no longer use PQsendPrepare() in pipeline mode, but only  
PQprepare.  There's no specific reason for this change other than no  
longer needing to do differently in pipeline mode.  (Previously we had  
no choice, because in pipeline mode PQprepare could not be used.)  
  
Backpatch to 14, where pgbench got support for pipeline mode.  
  
Reported-by: Yugo NAGATA <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/20210716153013.fc53b1c780b06fccc07a7f0d@sraoss.co.jp  

commit   : ded5ede2779fec65ed0a4022296efa71e9c64aac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 16:55:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 16:55:59 -0500    

Historically we've accepted interval input like 'P.1e10D'.  This  
is probably an accident of having used strtod() to do the parsing,  
rather than something anyone intended, but it's been that way for  
a long time.  Commit e39f99046 broke this by trying to parse the  
integer and fractional parts separately, without accounting for  
the possibility of an exponent.  In principle that coding allowed  
for precise conversions of field values wider than 15 decimal  
digits, but that does not seem like a goal worth sweating bullets  
for.  So, rather than trying to manage an exponent on top of the  
existing complexity, let's just revert to the previous coding that  
used strtod() by itself.  We can still improve on the old code to  
the extent of allowing the value to range up to 1.0e15 rather than  
only INT_MAX.  (Allowing more than that risks creating problems  
due to precision loss: the converted fractional part might have  
absolute value more than 1.  Perhaps that could be dealt with in  
some way, but it really does not seem worth additional effort.)  
  
Per bug #17795 from Alexander Lakhin.  Back-patch to v15 where  
the faulty code came in.  
  
Discussion: https://postgr.es/m/17795-748d6db3ed95d313@postgresql.org  

commit   : e6d8639cf25ccfffe12695768a4f7a60130c426f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 15:18:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 15:18:22 -0500    

This was not something that required consideration before MERGE  
was invented; but MERGE builds a join tree that left-joins to the  
result relation, meaning that remove_useless_joins will consider  
removing it.  That should generally be stopped by the query's use  
of output variables from the result relation.  However, if the  
result relation is inherited (e.g. a partitioned table) then  
we don't add any row identity variables to the query until  
expand_inherited_rtentry, which happens after join removal.  
  
This was exposed as of commit 3c569049b, which made it possible  
to deduce that a partitioned table could contain at most one row  
matching a join key, enabling removal of the not-yet-expanded  
result relation.  Ooops.  
  
To fix, let's just teach join_is_removable that the query result  
rel is never removable.  It's a cheap enough test in any case,  
and it'll save some cycles that we'd otherwise expend in proving  
that it's not removable, even in the cases we got right.  
  
Back-patch to v15 where MERGE was added.  Although I think the  
case cannot be reached in v15, this seems like cheap insurance.  
  
Per investigation of a report from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/36bee393-b351-16ac-93b2-d46d83637e45@gmail.com  

commit   : da32a99df1f519622eee0d5c3ea61226468272a7    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 20 Feb 2023 11:29:31 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 20 Feb 2023 11:29:31 -0800    

GetWALRecordsInfo() and pg_get_wal_fpi_info() can leak memory across  
WAL record iterations. Fix this by using a temporary memory context  
that's reset for each WAL record iteraion.  
  
Also use a temporary context for loops in GetXLogSummaryStats(). The  
number of iterations is a small constant, so the previous behavior was  
not a leak, but fix for clarity (but no need to backport).  
  
Backport GetWALRecordsInfo() change to version  
15. pg_get_wal_fpi_info() didn't exist in version 15.  
  
Reported-by: Peter Geoghegan  
Author: Bharath Rupireddy  
Discussion: https://www.postgresql.org/message-id/CAH2-WznLEJjn7ghmKOABOEZYuJvkTk%3DGKU3m0%2B-XBAH%2BerPiJQ%40mail.gmail.com  
Backpatch-through: 15  

commit   : 305d89ad93ff6eb3eecae485bbfb2531a349906f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 19 Feb 2023 00:41:18 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 19 Feb 2023 00:41:18 +0100    

When evaluating clauses on multiple scan keys of a multi-column BRIN  
index, we can stop processing as soon as we find a scan key eliminating  
the range, and the range should not be added to tbe bitmap.  
  
That's how it worked before 14, but since a681e3c107a the code treated  
the range as matching if it matched at least the last scan key.  
  
Backpatch to 14, where this code was introduced.  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/ebc18613-125e-60df-7520-fcbe0f9274fc%40enterprisedb.com