PostgreSQL 15.0 (upcoming) commit log

commit   : 648aa6734fefb2cc2c9bba7d6444890e727eaca1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 May 2022 09:27:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 May 2022 09:27:34 +0200    

commit   : c4a4e760f6b0e7933e7d3bff0b589af9da49f8e6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 19 May 2022 17:14:23 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 19 May 2022 17:14:23 +1200    

Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/0635f5aa-4973-8dc2-4e4e-df9fd5778a65@enterprisedb.com  
Backpatch-through: 14, where Memoize was added  

commit   : 0ff20288e1cb3282efb43401896a939916fceb4d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 May 2022 08:20:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 May 2022 08:20:55 +0530    

Commit 923def9a53 and 52e4f0cd47 allowed to specify column lists and row  
filters for publication tables. This commit extends the  
pg_publication_tables view and pg_get_publication_tables function to  
display that information.  
  
This information will be useful to users and we also need this for the  
later commit that prohibits combining multiple publications with different  
column lists for the same table.  
  
Author: Hou Zhijie  
Reviewed By: Amit Kapila, Alvaro Herrera, Shi Yu, Takamichi Osumi  
Discussion: https://postgr.es/m/202204251548.mudq7jbqnh7r@alvherre.pgsql  

commit   : 62221ef187b0098c8f331f804b7c63859e5ee6ff    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 23:19:53 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 23:19:53 +0200    

Commit 0fbf01120023 should have updated them but didn't.  

commit   : 12e423e21d8ef47d95a099c12f625f6d191eaf92    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 21:20:49 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 21:20:49 +0200    

An 'else' clause was misplaced in commit 598ac10be1c2, making zero-rows  
output look a bit silly.  Add a test case for it.  
  
Pointed out by Tom Lane.  
  
Discussion: https://postgr.es/m/21030.1652893083@sss.pgh.pa.us  

commit   : 0fbf0112002355efb2bb525ab88edf891dbfd033    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 20:28:31 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 20:28:31 +0200    

We weren't checking the length of the column list in the alias clause of  
an XMLTABLE or JSON_TABLE function (a "tablefunc" RTE), and it was  
possible to make the server crash by passing an overly long one.  Fix it  
by throwing an error in that case, like the other places that deal with  
alias lists.  
  
In passing, modify the equivalent test used for join RTEs to look like  
the other ones, which was different for no apparent reason.  
  
This bug came in when XMLTABLE was born in version 10; backpatch to all  
stable versions.  
  
Reported-by: Wang Ke <krking@zju.edu.cn>  
Discussion: https://postgr.es/m/17480-1c9d73565bb28e90@postgresql.org  

commit   : 598ac10be1c20961baac44db773eb826f788fdfa    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 18:33:04 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 May 2022 18:33:04 +0200    

We can use a single line to print all tuple counts that MERGE processed,  
for conciseness, and elide those that are zeroes.  Non-text formats  
report all numbers, as is typical.  
  
Per comment from Justin Pryzby <pryzby@telsasoft.com>  
  
Discussion: https://postgr.es/m/20220511163350.GL19626@telsasoft.com  

commit   : 81e3c83d988daa8fd763ec5104d540713832dd1a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 May 2022 18:18:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 May 2022 18:18:22 +0200    

There is no need for a <literal> inside a <synopsis>, since the latter  
is already all "literal" implicitly.  Also, create_help.pl misparses  
it.  So just remove it.  
  
Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/20220517.174342.1884842412165214815.horikyota.ntt%40gmail.com  

commit   : 27f1366050c6cd8c1ea5f03b367a5a167ebf34b7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 May 2022 09:47:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 May 2022 09:47:38 +0900    

A value of 0 is allowed for this option since its creation, that would  
map with the default of having no partitions for pgbench_accounts, but  
6f164e6 broke that by enforcing an error.  This commit restores the  
original behavior.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqGAGobiiHR8nH382HJxqm1mzZs8=3oKPXnXivWoFSZmNA@mail.gmail.com  

commit   : bbf7c2d9e932db873469cd9cecf0e05e39c1962d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 May 2022 09:06:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 May 2022 09:06:22 +0900    

s/primary_slotname/primary_slot_name/.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACX3=pHkCpoGG-z+O=7Gp5YZv70jmfTyGnNV7YF3SkK73g@mail.gmail.com  

commit   : 05a5a1775c89f6beb326725282e7eea1373cbec8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 May 2022 17:10:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 May 2022 17:10:42 -0400    

commit   : 4bfa420075b4e85012837b6b6d376edf8af5ede5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 May 2022 10:18:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 May 2022 10:18:17 -0400    

commit   : 9499c0fcf488e2f8e0e3ae71b06003fe7735feb4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 May 2022 10:09:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 May 2022 10:09:36 -0400    

Reported-by: John Naylor  
  
Discussion: https://postgr.es/m/CAFBsxsE-US0sgVxVHjt99GCGky4TCD57gwMHWPF9XWo7R5rXPg@mail.gmail.com  

commit   : 6a8a7b1ccbc0e92ce2b301e9aad26a4caedfd9b5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 May 2022 11:12:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 May 2022 11:12:42 +0200    

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

commit   : cd690e07fd47f245df02ab461754755956bf3e00    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 May 2022 09:41:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 May 2022 09:41:02 +0200    

Forgot to add it in one place in the previous commit.  

commit   : cd46d42a515918e88ae8ccb5990d59b3ad451455    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 May 2022 08:55:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 May 2022 08:55:01 +0200    

prep_status_progress() is new.  

commit   : 1e731ed12aac3f2ed99cf13244f5a1571a6eb6e6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 16 May 2022 16:07:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 16 May 2022 16:07:56 +1200    

In order to estimate the cache hit ratio of a Memoize node, one of the  
inputs we require is the estimated number of times the Memoize node will  
be rescanned.  The higher this number, the large the cache hit ratio is  
likely to become.  Unfortunately, the value being passed as the number of  
"calls" to the Memoize was incorrectly using the Nested Loop's  
outer_path->parent->rows instead of outer_path->rows.  This failed to  
account for the fact that the outer_path might be parameterized by some  
upper-level Nested Loop.  
  
This problem could lead to Memoize plans appearing more favorable than  
they might actually be.  It could also lead to extended executor startup  
times when work_mem values were large due to the planner setting overly  
large MemoizePath->est_entries resulting in the Memoize hash table being  
initially made much larger than might be required.  
  
Fix this simply by passing outer_path->rows rather than  
outer_path->parent->rows.  Also, adjust the expected regression test  
output for a plan change.  
  
Reported-by: Pavel Stehule  
Author: David Rowley  
Discussion: https://postgr.es/m/CAFj8pRAMp%3DQsMi6sPQJ4W3hczoFJRvyXHJV3AZAZaMyTVM312Q%40mail.gmail.com  
Backpatch-through: 14, where Memoize was introduced  

commit   : 5bcc4d09332844ae369bcf99f18ace1c982b7301    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 14 May 2022 09:57:03 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 14 May 2022 09:57:03 +0200    

Reaction to a suggestion from jhebert@micron.com, though this doesn't  
directly address the complaint.  
  
Discussion: https://postgr.es/m/165117307860.683.10308862820133754390@wrigleys.postgresql.org  

commit   : dce7072e5106456a1f1f003c2fcc2d7901ab89d8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 14 May 2022 09:03:16 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 14 May 2022 09:03:16 +0200    

Suggested by David G. Johnston <david.g.johnston@gmail.com>  
  
Discussion: https://postgr.es/m/CAKFQuwYK4OqwoHscZi3yws-urv3NvVfoKHessyso5D=5qqChYQ@mail.gmail.com  

commit   : 93759c665d482b5bf76ca22c9cac91e713e9386e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 14 May 2022 11:58:10 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 14 May 2022 11:58:10 +1200    

Per BF animal chipmunk:  CREATE DATABASE could apparently fail due to an  
AV process being in the template database and not quitting fast enough  
for the 5 second timeout in CountOtherDBBackends().  The test script had  
autovacuum_naptime=1s to encourage more activity and opening of fds, but  
that wasn't strictly necessary for this test.  Take it out.  
  
Per BF animal skink:  there was a 300s timeout for all tests in the  
script, but apparently that was not enough under valgrind.  Let's use  
the standard timeout $PostgreSQL::Test::Utils::timeout_default, but  
restart it for each query we run.  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGKa8HNJaA24gqiiFoGy0ysndeVoJsHvX_q1-DVLFaGAmw%40mail.gmail.com  

commit   : fcab82a2d79b4533cfdc8e8d5e00dbdf6830d63a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 14 May 2022 08:27:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 14 May 2022 08:27:59 +0900    

pgstat_create_function() creates stats for a function in a transactional  
fashion, so the stats would be dropped if transaction creating the  
function is aborted, not committed.  
  
Author: Amul Sul  
Discussion: https://postgr.es/m/CAAJ_b97x1T3xgAMWNj4w7kSgN0nTuG-vLrQJ4NB-dsNr0Kudxw@mail.gmail.com  

commit   : c4f113e8fef900e9e7e7c77a3a21db1535e5be72    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 May 2022 23:52:35 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 May 2022 23:52:35 +0200    

Like commit c9d297751959.  

commit   : 3715850ecc524544546e696bb0a7bbc44095d12a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 May 2022 11:50:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 May 2022 11:50:24 -0400    

Also move system view item to logical replication, mention "infinite  
_error_ loops".  
  
Reported-by: Euler Taveira, Takamichi Osumi, Amit Langote  
  
Discussion: https://postgr.es/m/21e8ef3b-6ffb-49d8-867f-4622a4dffcf3@www.fastmail.com  

commit   : 3ab9a63cb638a1fd99475668e2da9c237495aeda    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 May 2022 11:40:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 May 2022 11:40:01 -0400    

I started out with the intention to rename value_type to item_type to  
avoid a collision with a typedef name that appears on some platforms.  
  
Along the way, I noticed that the adjacent field "format" was not being  
correctly handled by the backend/nodes/ infrastructure functions:  
copyfuncs.c erroneously treated it as a scalar, while equalfuncs,  
outfuncs, and readfuncs omitted handling it at all.  This looks like  
it might be cosmetic at the moment because the field is always NULL  
after parse analysis; but that's likely a bug in itself, and the code's  
certainly not very future-proof.  Let's fix it while we can still do so  
without forcing an initdb on beta testers.  
  
Further study found a few other inconsistencies in the backend/nodes/  
infrastructure for the recently-added JSON node types, so fix those too.  
  
catversion bumped because of potential change in stored rules.  
  
Discussion: https://postgr.es/m/526703.1652385613@sss.pgh.pa.us  

commit   : 2454cb07eed1ec7e68b9953b03d473d3c334ba05    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 May 2022 16:14:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 May 2022 16:14:16 +0200    

protocol.sgml had some unusual indentation that kept getting added on  
to with new additions in that file.  This reindents it to be more in  
line with the style elsewhere.  
  
Discussion: https://www.postgresql.org/message-id/flat/15113594-649b-ce82-24c8-7522f1373da4%40enterprisedb.com  

commit   : 4f2400cb3f10aa79f99fba680c198237da28dd38    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 13 May 2022 09:31:06 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 13 May 2022 09:31:06 -0400    

Currently, preloaded libraries are expected to request additional  
shared memory and LWLocks in _PG_init().  However, it is not unusal  
for such requests to depend on MaxBackends, which won't be  
initialized at that time.  Such requests could also depend on GUCs  
that other modules might change.  This introduces a new hook where  
modules can safely use MaxBackends and GUCs to request additional  
shared memory and LWLocks.  
  
Furthermore, this change restricts requests for shared memory and  
LWLocks to this hook.  Previously, libraries could make requests  
until the size of the main shared memory segment was calculated.  
Unlike before, we no longer silently ignore requests received at  
invalid times.  Instead, we FATAL if someone tries to request  
additional shared memory or LWLocks outside of the hook.  
  
Nathan Bossart and Julien Rouhaud  
  
Discussion: https://postgr.es/m/20220412210112.GA2065815%40nathanxps13  
Discussion: https://postgr.es/m/Yn2jE/lmDhKtkUdr@paquier.xyz  

commit   : 8c8d307f82976122980bbccf940319d1b8a71403    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 13 May 2022 18:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 13 May 2022 18:30:00 +0900    

It wasn't very clear that if this option was enabled, postgres_fdw would  
commit remote transactions in parallel at main-transaction end, and  
commit remote subtransactions in parallel at subtransaction end, due to  
the references to (sub)transaction and other too specific documentation.  
Clarify that.  Also reword to simplify.  
  
Follow-up for commit 04e706d42.  
  
Jonathan S. Katz, reviewed by Justin Pryzby, with some modifications by  
me.  
  
Discussion: https://postgr.es/m/1435bfd1-172b-de38-f590-4404a5a62eb0%40postgresql.org  

commit   : 30ed71e423ee63b263730b86326da2a629a29f84    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 May 2022 07:17:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 May 2022 07:17:29 +0200    

In the style of pgindent, done semi-manually.  
  
Discussion: https://www.postgresql.org/message-id/flat/7d062ecc-7444-23ec-a159-acd8adf9b586%40enterprisedb.com  

commit   : 0cf16cb8ca4853b084c40eca310c4c9c3ebf7e2a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 18:49:33 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 18:49:33 -0700    

pgstat_report_stat() is only supposed to be called outside of transactions. In  
5891c7a8ed8 I added a pgstat_report_stat() call into LogicalRepApplyLoop()'s  
timeout branch. While not commonly reached inside a transaction, it is  
reachable (e.g. due to network bottlenecks or the sender being stalled / slow  
for some reason).  
  
To fix, add a !IsTransactionState() check.  
  
No test added because there's no easy way to reproduce this case without  
patching the code.  
  
Reported-By: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/b3463b8c-2328-dcac-0136-af95715493c1@xs4all.nl  

commit   : 8d3341266508fc1aed1f1a6bdb4ed885821c81b0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 May 2022 09:39:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 May 2022 09:39:13 +0900    

Per discussion with Tom Lane and Andres Freund.  I have misunderstood  
the intention behind the choice done in 9a374b7.  
  
Discussion: https://postgr.es/m/20220512153737.6kbbcf4qyvwgq4s2@alap3.anarazel.de  

commit   : 07d683b54af854098cc559d4b8640905f9efa0ea    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:25:14 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:25:14 -0700    

The declaration is automatically generated. Noticed when experimenting with  
adding PGDLLIMPORT markers for functions.  
  
Discussion: https://postgr.es/m/20220512164513.vaheofqp2q24l65r@alap3.anarazel.de  

commit   : 0699b1ae2d8e7b8763a2019d9cd651ab55521779    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:20:36 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:20:36 -0700    

A few places used binary_upgrade_* variables without including the header,  
which worked without warnings because the variables are defined in those  
places. However that can cause linker complaints with MSVC - except that we  
don't see them right now, due to the use of a symbol export file.  
  
Discussion: https://postgr.es/m/20220512164513.vaheofqp2q24l65r@alap3.anarazel.de  

commit   : 09cd33f47bb32f904c32b5aabe607a5125159cc4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:19:04 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:19:04 -0700    

Noticed when comparing the set of exported symbols without / with  
-fvisibility=hidden after adding PGDLLIMPORT to intentionally exported  
symbols.  
  
Discussion: https://postgr.es/m/20220512164513.vaheofqp2q24l65r@alap3.anarazel.de  

commit   : 905c020bef99e16b37529203084cd93932e73805    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:17:14 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:17:14 -0700    

Postgres style is to spell out extern. Noticed while scripting adding  
PGDLLIMPORT markers to functions.  
  
Discussion: https://postgr.es/m/20220512164513.vaheofqp2q24l65r@alap3.anarazel.de  

commit   : c2f436151edc818601c2499e400e1ad53d0da66f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 15:35:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 15:35:15 -0400    

Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta  
tasks specified by RELEASE_CHANGES.  For reference, the command was  
  
./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6205  

commit   : 03501aceae5d27bf5a23942035299d52600e3279    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 15:22:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 15:22:20 -0400    

commit   : 23e7b38bfe396f919fdb66057174d29e17086418    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 15:17:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 15:17:30 -0400    

Run pgindent, pgperltidy, and reformat-dat-files.  
I manually fixed a couple of comments that pgindent uglified.  

commit   : 93909599cdba64c8759d646983c0a4ef93de1e50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 12:42:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 12:42:29 -0400    

The original coding did this in pqDropServerData(), which seems  
fairly backwards.  Pending commands are more like already-queued  
output data, which is dropped in pqDropConnection().  Moving the  
operation means that we clear the command queue immediately upon  
detecting connection drop, which improves the sanity of subsequent  
behavior.  In particular this eliminates duplicated error message  
text as a consequence of code added in b15f25446, which supposed  
that a nonempty command queue must mean the prior operation is  
still active.  
  
There might be an argument for backpatching this to v14; but as with  
b15f25446, I'm unsure about interactions with 618c16707.  For now,  
given the lack of complaints about v14's behavior, leave it alone.  
  
Per report from Peter Eisentraut.  
  
Discussion: https://postgr.es/m/de57761c-b99b-3435-b0a6-474c72b1149a@enterprisedb.com  

commit   : b5f44225b833a2fd07b4a7c77e33ae0c37e6a7d6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:10:03 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 May 2022 09:10:03 -0700    

Discussion: https://postgr.es/m/20220506234924.6mxxotl3xl63db3l@alap3.anarazel.de  

commit   : 79b58c6f684315d39dfdbd721da7576d90bd9f99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 11:31:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2022 11:31:46 -0400    

This follows in the footsteps of commit 2591ee8ec by removing one more  
ill-advised shortcut from planning of GroupingFuncs.  It's true that  
we don't intend to execute the argument expression(s) at runtime, but  
we still have to process any Vars appearing within them, or we risk  
failure at setrefs.c time (or more fundamentally, in EXPLAIN trying  
to print such an expression).  Vars in upper plan nodes have to have  
referents in the next plan level, whether we ever execute 'em or not.  
  
Per bug #17479 from Michael J. Sullivan.  Back-patch to all supported  
branches.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/17479-6260deceaf0ad304@postgresql.org  

commit   : 25285e5d4ee5b5655ddf93204180aedc873f19d6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 May 2022 10:11:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 May 2022 10:11:55 -0400    

Reported-by: Amit Langote, Amit Kapila, Takamichi Osumi  
  
Discussion: https://postgr.es/m/CAA4eK1KdAho_fNkYRe=o=XpxWs_TG4O0V8CJBAvTG8HamWt6OQ@mail.gmail.com  

commit   : 4036bcbbb92839f20ed6d0db418996954dd66470    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 12 May 2022 17:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 12 May 2022 17:30:00 +0900    

Expand the comment about the parallel_commit option to mention that the  
default is false.  
  
Also, since the comment about alteration of the keep_connections option,  
which was located above the expanded comment, holds true for the  
parallel_commit option, rewrite it to reflect this, and move it to after  
the expanded comment.  
  
Follow-up for commit 04e706d42.  
  
Discussion: https://postgr.es/m/CAPmGK16Kg2Bf90sqzcZ4YM5cN_G-4h7wFUS01qQpqNB%2B2BG5_w%40mail.gmail.com  

commit   : 5edeb574285ecbcc47f0b769a7e363404db0155b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 May 2022 15:08:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 May 2022 15:08:45 +0900    

Three variables in pqsignal.h (UnBlockSig, BlockSig and StartupBlockSig)  
were not marked with PGDLLIMPORT, as they are declared in a way that  
prevents mark_pgdllimport.pl to detect them.  These variables are  
redefined in a style more consistent with the other headers, allowing  
the script to find and mark them.  
  
PGDLLIMPORT was missing for __pg_log_level in logging.h, so add it  
back.  The marking got accidentally removed in 9a374b77, just after its  
addition in 8ec5694.  
  
While on it, add a comment in mark_pgdllimport.pl explaining what are  
the arguments needed by the script (aka a list of header paths).  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20220506234924.6mxxotl3xl63db3l@alap3.anarazel.de  

commit   : 6bfecf33f6ed558deee4f801e296b058261dbef3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 22:46:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 22:46:36 -0400    

Reported-by: Ian Lawrence Barwick  
  
Discussion: https://postgr.es/m/CAB8KJ=j9VhsFXuN+xv5qzxQV7gj-6TKqqwVLSgz5zU7F8nHCYw@mail.gmail.com  

commit   : 7761b9faabae15217fe0e5bbb54230b425222f81    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 12 May 2022 09:18:21 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 12 May 2022 09:18:21 +0700    

Also clarify that ApplySignedSortComparator() is not built on 32-bit machines.  
  
Folow-up to c90c16591  
  
Reviewed-by: David Rowley  
Discussion: https://www.postgresql.org/message-id/CAFBsxsFmt4_JUP8XgSJqwaAS9a9s8K8_PvMu%3Dj%3DDfwU%3D8QjNPw%40mail.gmail.com  

commit   : d70b95a7178af84212487438b5509871090f5b05    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 22:19:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 22:19:12 -0400    

Reported-by: Thomas Munro  
  
Discussion: https://postgr.es/m/CA+hUKGKha50-H2ye-9x3PJWU5wBq_MPc2rmVKM1xJ0tL+ntROw@mail.gmail.com  

commit   : da82c62469865e11c29881b42e955482194ca781    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 22:01:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 22:01:46 -0400    

Reported-by: Ian Lawrence Barwick  
  
Discussion: https://postgr.es/m/CAB8KJ=jmLBMAmxjcew12-yntb7m3FH-8A2+Qb7+RybZp1w9GOg@mail.gmail.com  

commit   : 922d1a27e9bd3415522a5ec5578c7c1324b16b93    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 20:55:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 20:55:01 -0400    

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

commit   : ab02d702ef08343fba30d90fdf7df5950063e8c9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 11 May 2022 15:27:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 11 May 2022 15:27:33 -0400    

The code for unloading a library has been commented-out for over 12  
years, ever since commit 602a9ef5a7c60151e10293ae3c4bb3fbb0132d03, and we're  
no closer to supporting it now than we were back then.  
  
Nathan Bossart, reviewed by Michael Paquier and by me.  
  
Discussion: http://postgr.es/m/Ynsc9bRL1caUSBSE@paquier.xyz  

commit   : 78ccd6cca48dab098fcce62528c2b471f7a0010a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 11:28:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 11:28:29 -0400    

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

commit   : 279d957efebb4fe0636981cf0354b310fd2a109b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 10:45:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 May 2022 10:45:17 -0400    

Reported-by: David Rowley, Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqFcEdbNinfK94aTgBJKmtkYGdtkPnjt3b0fVzKi+WZ+KA@mail.gmail.com  

commit   : 45edde037efc6ec76714e0be7309b348fe34351e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 May 2022 15:38:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 May 2022 15:38:55 +0900    

This fixes the grammar of some comments in a couple of tests (SQL and  
TAP), and in some C files.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20220511020334.GH19626@telsasoft.com  

commit   : 0d3431497dbe91ba1e428ace4e9537c109eaff07    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 11 May 2022 18:03:03 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 11 May 2022 18:03:03 +1200    

To enable diagnosis of systems that are not processing ProcSignalBarrier  
requests promptly, add a LOG message every 5 seconds if we seem to be  
wedged.  Although you could already see this state as a wait event in  
pg_stat_activity, the log message also shows the PID of the process that  
is preventing progress.  
  
Also add DEBUG1 logging around the whole wait loop.  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CA%2BTgmoYJ03r5359gQutRGP9BtigYCg3_UskcmnVjBf-QO3-0pQ%40mail.gmail.com  

commit   : f95d53eded55ecbf037f6416ced6af29a2c3caca    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 May 2022 11:11:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 May 2022 11:11:44 +0530    

The problem is that we don't send keep-alive messages for a long time  
while processing large transactions during logical replication where we  
don't send any data of such transactions. This can happen when the table  
modified in the transaction is not published or because all the changes  
got filtered. We do try to send the keep_alive if necessary at the end of  
the transaction (via WalSndWriteData()) but by that time the  
subscriber-side can timeout and exit.  
  
To fix this we try to send the keepalive message if required after  
processing certain threshold of changes.  
  
Reported-by: Fabrice Chapuis  
Author: Wang wei and Amit Kapila  
Reviewed By: Masahiko Sawada, Euler Taveira, Hou Zhijie, Hayato Kuroda  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAA5-nLARN7-3SLU_QUxfy510pmrYK6JJb=bk3hcgemAM_pAv+w@mail.gmail.com  

commit   : 8bbf8461a3a2a38ce5f2952a025385b6938a61f7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 May 2022 14:21:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 May 2022 14:21:06 +0900    

Presently, the server may emit a variety of log messages when inspecting  
a runtime-computed GUC, mostly in the shape of one LOG message with the  
default configuration, related to the startup sequence launched as such  
GUCs require a load of the control file and of external shared  
libraries.  
  
For example, the server will always emit a "database system is shut  
down" LOG (unless the user has set log_min_messages higher than LOG),  
which is an annoying behavior as "postgres -C" is expected to only emit  
in its output the parameter value we are looking for.  The parameter  
value is sent to stdout, while the logs are sent to stderr so we could  
recommend to use a redirection, but there was not much love for this  
workaround either.  
  
To avoid such extra log messages, per discussion, this change sets  
log_min_messages to FATAL internally when -C is used on a  
runtime-computed GUC (even if set to PANIC in postgresql.conf).  At  
FATAL, the user will still receive messages explaining why a GUC value  
cannot be inspected, and will know if the command is attempted on a  
server already running, something not supported yet for a  
runtime-computed GUC.  
  
Reported-by: Magnus Hagander, Bruce Momjian  
Author: Nathan Bossart, Michael Paquier  
Discussion: https://postgr.es/m/Yni6ZHkGotUU+RSf@paquier.xyz  

commit   : 3aa7a3d2a3d1177d32680b94541dc2db7f3d7b0b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 May 2022 06:16:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 May 2022 06:16:21 +0200    

commit   : 38fbbb5bb293c4cceebb130b42357a2d6ee8d294    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 23:41:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 23:41:26 -0400    

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20220511013117.GG19626@telsasoft.com  

commit   : 581c4e5b31853045473949822bcd0c90daf850fb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 22:10:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 22:10:45 -0400    

Reported-by: Mark Dilger  
  
Discussion: https://postgr.es/m/F3D44160-F41A-4F2E-AED5-5C15B6903AC4@enterprisedb.com  

commit   : a3c5f56c213e5799f7f5eb08890f6ddebacbb83c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 21:57:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 21:57:11 -0400    

Remove SSL item backpatched (Jonathan S. Katz), adjust logical  
replication item (Mark Dilger), adjust --compress wording (Justin  
Pryzby).  
  
Discussion: https://postgr.es/m/20220511012854.GF19626@telsasoft.com  

commit   : 0826ac89ac18ab05b9991cfbba72351a502ef12c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 May 2022 10:21:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 May 2022 10:21:52 +0900    

The current setup assumes that commands for lz4, zstd and gzip always  
exist by default if not enforced by a user's environment.  However,  
vcpkg, as one example, installs libraries but no binaries, so this  
default setup to assume that a command should always be present would  
cause failures.  This commit improves the detection of such external  
commands as follows:  
* If a ENV value is available, trust the environment/user and use it.  
* If a ENV value is not available, check its execution by looking in the  
current PATH, by launching a simple "$command --version" (that should be  
portable enough).  
** On execution failure, ignore ENV{command}.  
** On execution success, set ENV{command} = "$command".  
  
Note that this new rule applies to gzip, lz4 and zstd but not tar that  
we assume will always exist.  Those commands are set up in the  
environment only when using bincheck and taptest.  The CI includes all  
those commands and I have checked that their setup is correct there.  I  
have also tested this change in a MSVC environment where we have none of  
those commands.  
  
While on it, remove the references to lz4 from the documentation and  
vcregress.pl in ~v13.  --with-lz4 has been added in v14~ so there is no  
point to have this information in these older branches.  
  
Reported-by: Andrew Dunstan  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/14402151-376b-a57a-6d0c-10ad12608e12@dunslane.net  
Backpatch-through: 10  

commit   : c90c16591c438e4146b1d4b9e4539f80b58845ba    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 11 May 2022 11:38:13 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 11 May 2022 11:38:13 +1200    

697492434 added 3 new quicksort specialization functions for common  
datatypes.  
  
That commit was not very consistent in how it would determine if we're  
compiling for 32-bit or 64-bit machines.  It would sometimes use  
USE_FLOAT8_BYVAL and at other times check if SIZEOF_DATUM == 8.  This  
could cause theoretical problems due to the way USE_FLOAT8_BYVAL is now  
defined based on SIZEOF_VOID_P >= 8.  If pointers for some reason were  
ever larger than 8-bytes then we'd end up doing 32-bit comparisons  
mistakenly.  Let's just always check SIZEOF_DATUM >= 8.  
  
It also seems that ssup_datum_signed_cmp is just never used on 32-bit  
builds, so let's just ifdef that out to make sure we never accidentally  
use that comparison function on such machines.  This also allows us to  
ifdef out 1 of the 3 new specialization quicksort functions in 32-bit  
builds which seems to shrink down the binary by over 4KB on my machine.  
  
In passing, also add the missing DatumGetInt32() / DatumGetInt64() macros  
in the comparison functions.  
  
Discussion: https://postgr.es/m/CAApHDvqcQExRhtRa9hJrJB_5egs3SUfOcutP3m+3HO8A+fZTPA@mail.gmail.com  
Reviewed-by: John Naylor  

commit   : aff45c879e018d18951a9bc4cd8e2a395ee52c43    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 May 2022 18:42:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 May 2022 18:42:02 -0400    

In OpenLDAP 2.5 and later, libldap itself is always thread-safe and  
there's never a libldap_r.  Our existing coding dealt with that  
by assuming it wouldn't find libldap_r if libldap is thread-safe.  
But that rule fails to cope if there are multiple OpenLDAP versions  
visible, as is likely to be the case on macOS in particular.  We'd  
end up using shiny new libldap in the backend and a hoary libldap_r  
in libpq.  
  
Instead, once we've found libldap, check if it's >= 2.5 (by  
probing for a function introduced then) and don't bother looking  
for libldap_r if so.  While one can imagine library setups that  
this'd still give the wrong answer for, they seem unlikely to  
occur in practice.  
  
Per report from Peter Eisentraut.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com  

commit   : b0d4b3c386f5372474575a4eeba2450951d9b44a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 17:49:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 17:49:51 -0400    

Also improve postgres_fdw.application_name  
  
Reported-by: Justin Pryzby, Tatsuo Ishii  
  
Diagnosed-by: 20220510210235.GD19626@telsasoft.com  

commit   : 40131af573514d9915798f5fa6399ddc3d214937    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 16:47:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 16:47:48 -0400    

Reported-by: Jonathan Katz  
  
Discussion: per private email  

commit   : 653443ed83f03820d29604b65dca6a56f3f8ab06    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 16:34:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 16:34:11 -0400    

Reported-by: Nathan Bossart, Jonathan Katz  
  
Discussion: https://postgr.es/m/20220510194456.GA3716556@nathanxps13  

commit   : 9d89bb8a025d0374f7705cea9fead4eae9ae80ed    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 16:05:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 16:05:12 -0400    

Reported-by: Erik Rijkers, Justin Pryzby  
  
Discussion: https://postgr.es/m/20220510180935.GB19626@telsasoft.com  

commit   : 9700b250c5b84a083261add9f6e3507c9c72e076    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 May 2022 21:15:56 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 May 2022 21:15:56 +0200    

commit   : 93e6892f6717d5777c9decef301728e8bb3f011b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 May 2022 20:57:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 May 2022 20:57:37 +0200    

This is not handled uniformly throughout the code, but at least nearby  
code can be consistent.  

commit   : a9c018565eb306b5a884c31ca6e26efed4dfc774    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 May 2022 20:31:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 May 2022 20:31:13 +0200    

Several keywords were missing or misclassified in the original  
SQL:2016 standard.  This has been corrected in later technical  
corrigenda.  This change updates the PostgreSQL documentation  
accordingly.  
  
This also fixes a mistake in 606948b058d: The keywords JSON_SCALAR and  
JSON_SERIALIZE added there are not from SQL:2016 but from future  
SQL:202x, so they don't belong in that list yet.  
  
(606948b058d also added JSON to the reserved list, which is what the  
corrigendum also does, but failed to remove it from the nonreserved  
list.)  

commit   : 3c534949bbb0c7f312175879d1bf7de4f336c6e1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 12:51:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 12:51:25 -0400    

Reported-by: Geoff Winkless  
  
Discussion: https://postgr.es/m/CAEzk6fdF_J4jqicLz=FZ6R1u2EjpEtmzD55tFjVbxw-O-kR1=w@mail.gmail.com  

commit   : 9499606db00290562096d74f62cf47f953795b58    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 11:35:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 May 2022 11:35:28 -0400    

commit   : 7dd3ee508432730d15c5d3032f37362f6b6e4dd8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 May 2022 11:31:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 May 2022 11:31:31 +0900    

This commit addresses the following issues in the TAP tests of  
pg_upgrade, introduced in 322becb:  
- Remove --port and --host for commands that already rely on a node's  
environment PGHOST and PGPORT.  
- Switch from run_log() to command_ok(), as all the commands executed in  
the tests should succeed.  
- Change EXTRA_REGRESS_OPTS to make it count as a shell fragment (fixing  
s/OPT/OPTS on a way), to be compatible with the various Makefiles using  
it as well as 027_stream_regress.pl in the recovery tests.  The command  
built for the execution the pg_regress command is reformatted, while on  
it, to map with the recovery test doing the same thing (we should  
refactor and consolidate that in the future, perhaps).  
- Re-add the test for database names stressing the behavior of  
backslashes with double quotes, mostly here for Windows.  
  
Tests doable with the upgrade across different major versions still work  
the same way.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20220502042718.GB1565149@rfd.leadboat.com  

commit   : fe20afaee8aac7838ed6e4a76baa83e547629582    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2022 14:15:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2022 14:15:37 -0400    

The parser code that transformed VALUES from row-oriented to  
column-oriented lists failed if there were zero columns.  
You can't write that straightforwardly (though probably you  
should be able to), but the case can be reached by expanding  
a "tab.*" reference to a zero-column table.  
  
Per bug #17477 from Wang Ke.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17477-0af3c6ac6b0a6ae0@postgresql.org  

commit   : 29904f5f2fdafbbb96ef3685fd361053b061aeb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2022 11:02:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2022 11:02:36 -0400    

This reverts commit eafdf9de06e9b60168f5e47cedcfceecdc6d4b5f  
and its back-branch counterparts.  Corey Huinker pointed out that  
we'd discussed this exact change back in 2016 and rejected it,  
on the grounds that there's at least one usage pattern with LIMIT  
where an infinite endpoint can usefully be used.  Perhaps that  
argument needs to be re-litigated, but there's no time left before  
our back-branch releases.  To keep our options open, restore the  
status quo ante; if we do end up deciding to change things, waiting  
one more quarter won't hurt anything.  
  
Rather than just doing a straight revert, I added a new test case  
demonstrating the usage with LIMIT.  That'll at least remind us of  
the issue if we forget again.  
  
Discussion: https://postgr.es/m/3603504.1652068977@sss.pgh.pa.us  
Discussion: https://postgr.es/m/CADkLM=dzw0Pvdqp5yWKxMd+VmNkAMhG=4ku7GnCZxebWnzmz3Q@mail.gmail.com  

commit   : 0abc1a059e27c5a71a1a186c97d9c0af407469cc    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 May 2022 08:35:08 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 May 2022 08:35:08 -0700    

It intended to, but did not, achieve this.  Adopt the new standard of  
setting user ID just after locking the relation.  Back-patch to v10 (all  
supported versions).  
  
Reviewed by Simon Riggs.  Reported by Alvaro Herrera.  
  
Security: CVE-2022-1552  

commit   : a117cebd638dd02e5c2e791c25e43745f233111b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 May 2022 08:35:08 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 May 2022 08:35:08 -0700    

When a feature enumerates relations and runs functions associated with  
all found relations, the feature's user shall not need to trust every  
user having permission to create objects.  BRIN-specific functionality  
in autovacuum neglected to account for this, as did pg_amcheck and  
CLUSTER.  An attacker having permission to create non-temp objects in at  
least one schema could execute arbitrary SQL functions under the  
identity of the bootstrap superuser.  CREATE INDEX (not a  
relation-enumerating operation) and REINDEX protected themselves too  
late.  This change extends to the non-enumerating amcheck interface.  
Back-patch to v10 (all supported versions).  
  
Sergey Shinderuk, reviewed (in earlier versions) by Alexander Lakhin.  
Reported by Alexander Lakhin.  
  
Security: CVE-2022-1552  

commit   : f45f8b7ff3fe6c8b8139e177bb3fec7629ef9f05    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 May 2022 07:17:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 May 2022 07:17:08 +0200    

commit   : 7863ee4def653f2c2193cb0b0cf4a8f0f3ca6c56    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 May 2022 08:39:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 May 2022 08:39:59 +0900    

If a cluster is promoted (aka the control file shows a state different  
than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still  
processing, this function could miss an update of the control file for  
"checkPoint" and "checkPointCopy" but still do the recycling and/or  
removal of the past WAL segments, assuming that the to-be-updated LSN  
values should be used as reference points for the cleanup.  This causes  
a follow-up restart attempting crash recovery to fail with a PANIC on a  
missing checkpoint record if the end-of-recovery checkpoint triggered by  
the promotion did not complete while the cluster abruptly stopped or  
crashed before the completion of this checkpoint.  The PANIC would be  
caused by the redo LSN referred in the control file as located in a  
segment already gone, recycled by the previous restartpoint with  
"checkPoint" out-of-sync in the control file.  
  
This commit fixes the update of the control file during restartpoints so  
as "checkPoint" and "checkPointCopy" are updated even if the cluster has  
been promoted while a restartpoint is running, to be on par with the set  
of WAL segments actually recycled in the end of CreateRestartPoint().  
  
This problem exists in all the stable branches.  However, commit  
7ff23c6, by removing the last call of CreateCheckPoint() from the  
startup process, has made this bug much easier to reason about as  
concurrent checkpoints are not possible anymore.  No backpatch is done  
yet, mostly out of caution from me as a point release is close by, but  
we need to think harder about the case of concurrent checkpoints at  
promotion if the bgwriter is not considered as running by the startup  
process in ~v14, so this change is done only on HEAD for the moment.  
  
Reported-by: Fujii Masao, Rui Zhao  
Author: Kyotaro Horiguchi  
Reviewed-by: Nathan Bossart, Michael Paquier  
Discussion: https://postgr.es/m/20220316.102444.2193181487576617583.horikyota.ntt@gmail.com  

commit   : a22652ebbcb33a6a271cc69841ad61d971d7db30    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 8 May 2022 16:54:09 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 8 May 2022 16:54:09 +1200    

Add wait_for_catchup() call to the test added by commit e2f65f42.  Per  
slow build farm animal grison.  
  
Also fix a comment.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLJ2Vy8hVQmnYotmTaEKZK0%3D-GcXgNAgcHzArZvtS4L_g%40mail.gmail.com  

commit   : ad76c9708bd1a333c28e7be2178e34b745fb23d1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 7 May 2022 00:33:15 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 7 May 2022 00:33:15 -0700    

Per buildfarm members snapper and kittiwake.  Back-patch to v10 (all  
supported versions).  
  
Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com  

commit   : e2f65f42555ff531c6d7c8f151526b4ef7c016f8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 7 May 2022 15:19:52 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 7 May 2022 15:19:52 +1200    

Commits 4eb21763 and b74e94dc introduced a way to force every backend to  
close all relation files, to fix an ancient Windows-only bug.  
  
This commit extends that behavior to all operating systems and adds  
a couple of extra barrier points, to fix a totally different class of  
bug: the reuse of relfilenodes in scenarios that have no other kind of  
cache invalidation to prevent file descriptor mix-ups.  
  
In all releases, data corruption could occur when you moved a database  
to another tablespace and then back again.  Despite that, no back-patch  
for now as the infrastructure required is too new and invasive.  In  
master only, since commit aa010514, it could also happen when using  
CREATE DATABASE with a user-supplied OID or via pg_upgrade.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20220209220004.kb3dgtn2x2k2gtdm%40alap3.anarazel.de  

commit   : b74e94dc27fdbb13954f230b1d1298430afa6c0c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 7 May 2022 16:19:42 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 7 May 2022 16:19:42 +1200    

With sufficiently bad luck, it was possible for IssuePendingWritebacks()  
to reopen a file after we'd processed PROCSIGNAL_BARRIER_SMGRRELEASE and  
before the file was unlinked by some other backend.  That left a small  
hole in commit 4eb21763's plan to fix all spurious errors from DROP  
TABLESPACE and similar on Windows.  
  
Fix by closing md.c's segments, instead of just closing fd.c's  
descriptors, and then teaching smgrwriteback() not to open files that  
aren't already open.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20220209220004.kb3dgtn2x2k2gtdm%40alap3.anarazel.de  

commit   : 701d918a426b394620ce4d046533f77262c70829    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2022 09:24:06 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2022 09:24:06 -0400    

Since 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c, the maximum number  
of backends can't change as background workers are registered, but  
these comments still reflect the way things worked prior to that.  
  
Also, per recent discussion, some modules call SetConfigOption()  
from _PG_init(). It's not entirely clear to me whether we want to  
regard that as a fully supported operation, but since we know it's  
a thing that happens, it at least deserves a mention in the comments,  
so add that.  
  
Nathan Bossart, reviewed by Anton A. Melnikov  
  
Discussion: http://postgr.es/m/20220419154658.GA2487941@nathanxps13  

commit   : ee97d46cdb7e23f8ee98fe22648a1c3c75a80261    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 May 2022 14:41:36 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 May 2022 14:41:36 +0200    

The PXE_CIPHER_INIT error is used to report initialization errors, so  
appending a questionmark to the error isn't entirely accurate (using a  
space before the questionmark doubly so).  
  
Discussion: https://postgr.es/m/C89D932C-501E-4473-9750-638CFCD9095E@yesql.se  

commit   : 0250a167a07d4d2cff932e467d84306cbd3704fe    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 May 2022 14:41:33 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 May 2022 14:41:33 +0200    

Report OpenSSL errors during initialization as PXE_CIPHER_INIT since  
that's just what they were, and not generic unknown errors. This also  
removes the last users of the generic error, and thus it can be removed.  
  
Discussion: http://postgr.es/m/C89D932C-501E-4473-9750-638CFCD9095E@yesql.se  

commit   : 17ec5fa502d299b1919b1afacda839fb7d8206ad    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 May 2022 14:41:31 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 6 May 2022 14:41:31 +0200    

Setting up an EVP context for ciphers banned under FIPS generate  
two OpenSSL errors in the queue, and as we only consume one from  
the queue the other is at the head for the next invocation:  
  
  postgres=# select md5('foo');  
  ERROR:  could not compute MD5 hash: unsupported  
  postgres=# select md5('foo');  
  ERROR:  could not compute MD5 hash: initialization error  
  
Clearing the error queue when creating the context ensures that  
we don't pull in an error from an earlier operation.  
  
Discussion: https://postgr.es/m/C89D932C-501E-4473-9750-638CFCD9095E@yesql.se  

commit   : 59a32f00937c85fe944cf1fac3e8b98d091e2bc6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 May 2022 20:01:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 May 2022 20:01:15 +0900    

Introduced in 5aa2350.  
  
Author: Peter Smith  
Discussion: https://postgr.es/m/CAHut+PsuWz6_7aCmivNU5FahgQxDUTQtc3+__XnWkBzQcfn43w@mail.gmail.com  

commit   : 7e367924e33e47e0b0b135b0649c406a589bd496    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 May 2022 09:17:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 May 2022 09:17:38 +0200    

Update a few items that have become supported or mostly supported but  
weren't updated at the time.  

commit   : 7d6a4fdf3243a7a18e2cfc6cf03bce01cc6ce651    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 May 2022 09:14:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 May 2022 09:14:15 +0200    

commit   : a6f12520bed073d1d548a691e85d7f5371cc4ed4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 May 2022 09:07:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 May 2022 09:07:14 +0200    

introduced by 222b697ec077047024a96392a2f5cb9b1803ccf7  

commit   : ab3479bf55066f3dc827796f5bf1e957ffc97d2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2022 14:54:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2022 14:54:53 -0400    

DST law changes in Palestine.  Historical corrections for  
Chile and Ukraine.  

commit   : 9e6b7b45ca92cccd6b870fa4e0a98059a86ce79d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 May 2022 12:50:38 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 May 2022 12:50:38 -0700    

Per buildfarm members longfin and skink.  
  
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de  
Backpatch: 10-  

commit   : c40ba5f318f96a6a5a29729b987ead11c5dc65c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 May 2022 14:44:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 May 2022 14:44:40 -0400    

SubqueryScan was always getting labeled with a rowcount estimate  
appropriate for non-parallel cases.  However, nodes that are  
underneath a Gather should be treated as processing only one  
worker's share of the rows, whether the particular node is explicitly  
parallel-aware or not.  Most non-scan-level node types get this  
right automatically because they base their rowcount estimate on  
that of their input sub-Path(s).  But SubqueryScan didn't do that,  
instead using the whole-relation rowcount estimate as if it were  
a non-parallel-aware scan node.  If there is a parallel-aware node  
below the SubqueryScan, this is wrong, and it results in inflating  
the cost estimates for nodes above the SubqueryScan, which can cause  
us to not choose a parallel plan, or choose a silly one --- as indeed  
is visible in the one regression test whose results change with this  
patch.  (Although that plan tree appears to contain no SubqueryScans,  
there were some in it before setrefs.c deleted them.)  
  
To fix, use path->subpath->rows not baserel->tuples as the number  
of input tuples we'll process.  This requires estimating the quals'  
selectivity afresh, which is slightly annoying; but it shouldn't  
really add much cost thanks to the caching done in RestrictInfo.  
  
This is pretty clearly a bug fix, but I'll refrain from back-patching  
as people might not appreciate plan choices changing in stable branches.  
The fact that it took us this long to identify the bug suggests that  
it's not a major problem.  
  
Per report from bucoo, though this is not his proposed patch.  
  
Discussion: https://postgr.es/m/202204121457159307248@sohu.com  

commit   : dc2be6ed47e54004666a78e1592896c08f2be80e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 17:36:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 17:36:31 +0200    

It doesn't seem very useful, and it's a bit in the way of the planned  
node support automation.  
  
Discussion: https://www.postgresql.org/message-id/202204191140.3wsbevfhqmu3@alvherre.pgsql  

commit   : d47a11da9e5c5bad3eb0f353ab7b883d3f0eb48a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 17:34:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 17:34:22 +0200    

Similar to 983bdc4fac492a99bb8ab5a471ca7437139e5cf6.  
  
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/202204191140.3wsbevfhqmu3@alvherre.pgsql  

commit   : cfb63b994e91af8315f5262b3dc630c565f2420a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 13:33:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 13:33:59 +0200    

The test for lz4.h used AC_CHECK_HEADERS, but nothing was using the  
resulting symbol HAVE_LZ4_H.  Change this to use AC_CHECK_HEADER  
instead.  This was probably an oversight, seeing that the nearby  
similar tests do this correctly.  

commit   : 0432490d290f679cad773ce4735e8769e2c4db75    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 4 May 2022 14:15:25 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 4 May 2022 14:15:25 +0200    

The testclient and uri-regress programs in the libpq test suite had  
quite generic names which didn't convey much meaning. Since they are  
installed as part of the MSVC test runs, ensure that their purpose  
is a little bit clearer by renaming with a libpq_ prefix. While at  
it rename uri-regress to uri_regress to avoid mixing dash and under-  
score in the same filename.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20220501080706.GA1542365@rfd.leadboat.com  

commit   : 2e77180d4572ddb892f9c2e253ee95dc0fa26b5f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 07:57:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 May 2022 07:57:39 +0200    

commit   : 8f1537d10e83ad9c23ed2772cc28f74582b237ea    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 2 May 2022 18:25:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 2 May 2022 18:25:00 -0700    

The tests added in 9f8a050f68d failed nearly reliably on FreeBSD in CI, and  
occasionally on the buildfarm. That turns out to be caused not by a bug in the  
test, but by a longstanding bug in recovery conflict handling.  
  
The standby timeout handler, used by ResolveRecoveryConflictWithBufferPin(),  
executed SendRecoveryConflictWithBufferPin() inside a signal handler. A bad  
idea, because the deadlock timeout handler (or a spurious latch set) could  
have interrupted ProcWaitForSignal(). If unlucky that could cause a  
self-deadlock on ProcArrayLock, if the deadlock check is in  
SendRecoveryConflictWithBufferPin()->CancelDBBackends().  
  
To fix, set a flag in StandbyTimeoutHandler(), and check the flag in  
ResolveRecoveryConflictWithBufferPin().  
  
Subsequently the recovery conflict tests will be backpatched.  
  
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de  
Backpatch: 10-  

commit   : 21e184403bf92c52191d1f03dd6566a3d54dc907    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 2 May 2022 17:19:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 2 May 2022 17:19:11 -0700    

The recovery conflict tests added in 9f8a050f68d surfaced a bug in the  
interaction between buffer pin and deadlock recovery conflicts. To make sure  
that the bugfix won't break deadlock conflict detection, add a test for that  
scenario.  
  
031_recovery_conflict.pl will later be backpatched, with this included.  
  
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de  

commit   : 7307988abdff6c948d87e6d9dc9aaaa1f4c5283f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 May 2022 20:16:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 May 2022 20:16:19 +0900    

Oversight in c6306db24, as per a requirement from 88103567.  All the  
other modules in the tree, be they in contrib/ or src/test/modules/,  
already do that.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACUy7q_KwSMda+2SHPSWep32tNUM8cXGRS3=-Vfodo9OUg@mail.gmail.com  

commit   : d89f97e83efed4b2ac0a1803a1b6813c8277de73    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 2 May 2022 16:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 2 May 2022 16:45:00 +0900    

commit   : ed57cac84d1c5642737dab1e4c4b8cb4f0c4305f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 30 Apr 2022 08:28:33 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 30 Apr 2022 08:28:33 -0700    

Instability in the test for pg_walinspect revealed that  
pg_get_wal_records_info_till_end_of_wal(x) would try to decode all the  
records with a start LSN earlier than the flush LSN, even though that  
might include a partial record at the end of the range. In that case,  
read_local_xlog_page_no_wait() would return NULL when it tried to read  
past the flush LSN, which would be interpreted as an error by the  
caller. That caused a test failure only on a BF animal that had been  
restarted recently, but could be expected to happen in the wild quite  
easily depending on the alignment of various parameters.  
  
Fix by using private data in read_local_xlog_page_no_wait() to signal  
end-of-wal to the caller, so that it can be properly distinguished  
from a real error.  
  
Discussion: https://postgr.es/m/Ymd/e5eeZMNAkrXo%40paquier.xyz  
Discussion: https://postgr.es/m/111657.1650910309@sss.pgh.pa.us  
  
Authors: Thomas Munro, Bharath Rupireddy.  

commit   : ccd10a9bfa54c1aad3561232bf24222f1b455e1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2022 11:54:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2022 11:54:28 -0400    

I noticed that plpgsql would allow assignment of a new value to a  
variable even when that variable is marked CONSTANT, if the variable  
is used as an output parameter in CALL or is a refcursor variable  
that OPEN assigns a new value to.  Fix these oversights.  
  
In the CALL case, the check has to be done at runtime because we  
cannot know at parse time which parameters are OUT parameters.  
For OPEN, it seems best to likewise enforce at runtime because  
then we needn't throw error if the variable has a nonnull value  
(since OPEN will only try to overwrite a null value).  
  
Although this is surely a bug fix, no back-patch: it seems unlikely  
that anyone would thank us for breaking formerly-working code in  
minor releases.  
  
Discussion: https://postgr.es/m/214453.1651182729@sss.pgh.pa.us  

commit   : a79153b7a28579bda02e0d72464383dca4929e62    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2022 09:01:05 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2022 09:01:05 -0400    

Discussion: https://postgr.es/m/d03d809c-d0fb-fd6a-1476-d6dc18ec940e@dunslane.net  

commit   : 9c3d25e17894f35045a2d57dfb834e25c9dc4c21    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 28 Apr 2022 15:28:20 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 28 Apr 2022 15:28:20 -0400    

Commit f4fb45d15c contained a bug in removing items with null values when  
unique keys are required, where the leading items that are sorted  
contained such values. Fix that and add a test for it.  
  
Discussion: https://postgr.es/m/CAJA4AWQ_XbSmsNbW226UqNyRLJ+wb=iQkQMj77cQyoNkqtf=2Q@mail.gmail.com  

commit   : 5c854e7a2c8a6cd26040e0f9949e7a4a007f6366    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 28 Apr 2022 15:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 28 Apr 2022 15:15:00 +0900    

mark_async_capable_plan(), which is called from create_append_plan() to  
determine whether subplans are async-capable, failed to take into  
account that the given subplan created from a given subpath might  
include a gating Result node if the subpath is a SubqueryScanPath or  
ForeignPath, causing a segmentation fault there when the subplan created  
from a SubqueryScanPath includes the Result node, or causing  
ExecAsyncRequest() to throw an error about an unrecognized node type  
when the subplan created from a ForeignPath includes the Result node,  
because in the latter case the Result node was unintentionally  
considered as async-capable, but we don't currently support executing  
Result nodes asynchronously.  Fix by modifying mark_async_capable_plan()  
to disable asynchronous execution in such cases.  Also, adjust code in  
the ProjectionPath case in mark_async_capable_plan(), for consistency  
with other cases, and adjust/improve comments there.  
  
is_async_capable_path() added in commit 27e1f1456, which was rewritten  
to mark_async_capable_plan() in a later commit, has the same issue,  
causing the error at execution mentioned above, so back-patch to v14  
where the aforesaid commit went in.  
  
Per report from Justin Pryzby.  
  
Etsuro Fujita, reviewed by Zhihong Yu and Justin Pryzby.  
  
Discussion: https://postgr.es/m/20220408124338.GK24419%40telsasoft.com  

commit   : 55b56865115eccd6449e79d6f06fe49d6ba3b792    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Apr 2022 13:08:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Apr 2022 13:08:16 +0900    

This reverts commits 2c902bb and ccfbd92.  Per buildfarm members  
kestrel, rorqual and calliphoridae, the assertions checking that a TLI  
history file should not exist when created by a WAL receiver have been  
failing, and switching to durable_rename() over durable_rename_excl()  
would cause the newest TLI history file to overwrite the existing one.  
We need to think harder about such cases, so revert the new logic for  
now.  
  
Note that all the failures have been reported in the test  
025_stuck_on_old_timeline.  
  
Discussion: https://postgr.es/m/511362.1651116498@sss.pgh.pa.us  

commit   : e84f82ab5cff2811745ae8e2ac163a4b8b733394    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 28 Apr 2022 09:27:32 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 28 Apr 2022 09:27:32 +0700    

Euler Taveira  
  
Disussion: https://www.postgresql.org/message-id/25f95189-eef8-43c4-9d7b-419b651963c8%40www.fastmail.com  

commit   : 2c902bbf1911a3c3dd68b817209eca9be81e381c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Apr 2022 11:10:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Apr 2022 11:10:40 +0900    

ccfbd92 has replaced all existing in-core callers of this function in  
favor of durable_rename().  durable_rename_excl() is by nature unsafe on  
crashes happening at the wrong time, so just remove it.  
  
Author: Nathan Bossart  
Reviewed-by: Robert Haas, Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20220407182954.GA1231544@nathanxps13  

commit   : ccfbd9287d70038518bdd3e85d7f5fd3dd1bb880    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Apr 2022 10:11:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Apr 2022 10:11:45 +0900    

durable_rename_excl() attempts to avoid overwriting any existing files  
by using link() and unlink(), falling back to rename() on some platforms  
(e.g., Windows where link() followed by unlink() is not concurrent-safe,  
see 909b449).  Most callers of durable_rename_excl() use it just in case  
there is an existing file, but it happens that for all of them we never  
expect a target file to exist (WAL segment recycling, creation of  
timeline history file and basic_archive).  
  
basic_archive used durable_rename_excl() to avoid overwriting an archive  
concurrently created by another server.  Now, there is a stat() call to  
avoid overwriting an existing archive a couple of lines above, so note  
that this change opens a small TOCTOU window in this module between the  
stat() call and durable_rename().  
  
Furthermore, as mentioned in the top comment of durable_rename_excl(),  
this routine can result in multiple hard links to the same file and data  
corruption, with two or more links to the same file in pg_wal/ if a  
crash happens before the unlink() call during WAL recycling.  
Specifically, this would produce links to the same file for the current  
WAL file and the next one because the half-recycled WAL file was  
re-recycled during crash recovery of a follow-up cluster restart.  
  
This change replaces all calls to durable_rename_excl() with  
durable_rename().  This removes the protection against accidentally  
overwriting an existing file, but some platforms are already living  
without it, and all those code paths never expect an existing file (a  
couple of assertions are added to check after that, in case).  
  
This is a bug fix, but knowing the unlikeliness of the problem involving  
one of more crashes at an exceptionally bad moment, no backpatch is  
done.  This could be revisited in the future.  
  
Author: Nathan Bossart  
Reviewed-by: Robert Haas, Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20220407182954.GA1231544@nathanxps13  

commit   : 755df30e48b0a9ff8428f4c1ccb468dac29fc320    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Apr 2022 09:49:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Apr 2022 09:49:10 +0200    

commit   : 9ddf251f94090cebf1bd8fc18396cb8a4b580d04    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Apr 2022 09:15:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Apr 2022 09:15:09 +0200    

Unlike existing WRITE_*_ARRAY macros, WRITE_INDEX_ARRAY needs to  
handle the case that the field is NULL.  We already have the  
convention to print NULL fields as "<>", so we do that here as well.  
There is currently no corresponding read function for this, so reading  
this back in is not implemented, but it could be if needed.  
  
Reported-by: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/CAMbWs4-LN%3DbF8f9eU2R94dJtF54DfDvBq%2BovqHnOQqbinYDrUw%40mail.gmail.com  

commit   : 06cafd6f577ba251ac10d4f009fc3be424705a37    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Apr 2022 14:24:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Apr 2022 14:24:13 +0900    

Spotted while looking at the surroundings, introduced by 2258e76.  

commit   : 21a10368eb3fce73f146d7e48b4d81496f60d965    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Apr 2022 13:41:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Apr 2022 13:41:17 +0900    

This commit adds two isolation tests for CLUSTER, using:  
- A normal table, making sure that CLUSTER blocks and completes if the  
table is locked by a concurrent session.  
- A partitioned table with a partition owned by a different user.  If  
the partitioned table is locked by a concurrent session, CLUSTER on the  
partitioned table should block.  If the partition owned by a different  
user is locked, CLUSTER on its partitioned table should complete and  
skip the partition.  3f19e17 has added an early check to ignore such a  
partition with a SQL regression test, but this was not checking that  
CLUSTER should not block.  
  
Discussion: https://postgr.es/m/YlqveniXn9AI6RFZ@paquier.xyz  

commit   : b787c554c264cbed4de4eff2bb170a5224f0cfa5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Apr 2022 15:02:13 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Apr 2022 15:02:13 -0400    

For some reason by default the mingw C Runtime takes it upon itself to  
expand program arguments that look like shell globbing characters. That  
has caused much scratching of heads and mis-attribution of the causes of  
some TAP test failures, so stop doing that.  
  
This removes an inconsistency with Windows binaries built with MSVC,  
which have no such behaviour.  
  
Per suggestion from Noah Misch.  
  
Backpatch to all live branches.  
  
Discussion: https://postgr.es/m/20220423025927.GA1274057@rfd.leadboat.com  

commit   : dec8ad367e46180f826d5b6dc820fbecba1b71d2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Apr 2022 15:48:13 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Apr 2022 15:48:13 +0200    

Another test is constructed on top of regression tests, which does not  
work correctly with unlogged tables.  For now, cope with that by making  
sure no unlogged table is left behind.  
  
Per buildfarm pink after 4fb5c794e586.  

commit   : 4fb5c794e58613561f94ad5ea1197729be7791dc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Apr 2022 15:00:49 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Apr 2022 15:00:49 +0200    

Changing some TEMP or permanent tables to UNLOGGED is sufficient to  
invoke these ambuildempty routines, which were all not uncovered by any  
tests.  These changes do not otherwise affect the test suite.  
  
Author: Amul Sul <sulamul@gmail.com>  
Discussion: https://postgr.es/m/CAAJ_b95nneRCLM-=qELEdgCYSk6W_++-C+Q_t+wH3SW-hF50iw@mail.gmail.com  

commit   : 0bd56172b2871e94c0d7115ffbf430308317ac49    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Apr 2022 10:32:13 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Apr 2022 10:32:13 +0200    

Several places didn't do it, and in many cases it didn't matter because  
it would be a small allocation in a short-lived context; but other  
places may accumulate a few (for example, in CreateDatabaseUsingFileCopy,  
one per tablespace).  In most databases this is highly unlikely to be  
very serious either, but it seems better to make the code consistent in  
case there's future copy-and-paste.  
  
The only case of actual concern seems to be the aforementioned routine,  
which is new with commit 9c08aea6a309, so there's no need to backpatch.  
  
As pointed out by Coverity.  

commit   : f819020d400f1dbd96ee1a9fd44a1f6f44932b4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Apr 2022 12:16:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Apr 2022 12:16:12 -0400    

This function looks for a reference to the recursive WITH CTE,  
but it checked only the CTE name not ctelevelsup, so that it could  
seize on a lower CTE that happened to have the same name.  This  
would result in planner failures later, either weird errors such as  
"could not find attribute 2 in subquery targetlist", or crashes  
or assertion failures.  The code also merely Assert'ed that it found  
a matching entry, which is not guaranteed at all by the parser.  
  
Per bugs #17320 and #17318 from Zhiyong Wu.  
Thanks to Kyotaro Horiguchi for investigation.  
  
Discussion: https://postgr.es/m/17320-70e37868182512ab@postgresql.org  
Discussion: https://postgr.es/m/17318-2eb65a3a611d2368@postgresql.org  

commit   : c1da0acbb06e9175044b436d14c51cef03339109    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 22 Apr 2022 20:20:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 22 Apr 2022 20:20:11 -0700    

Today's test case detected alignment problems only when executing on  
AIX.  This change lets popular platforms detect the same problems.  
  
Reviewed by Masahiko Sawada.  
  
Discussion: https://postgr.es/m/20220415072601.GG862547@rfd.leadboat.com  

commit   : a66e722cc1180cd7a2046fb552195a7d7703a592    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Apr 2022 16:16:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Apr 2022 16:16:52 -0400    

Commit d2d35479796c3510e249d6fc72adbd5df918efbf included a pretty  
extensive set of test cases, and some of them don't work on all  
of our Windows machines. This happens because IPC::Run expands  
its arguments as shell globs on a few machines, but doesn't on most  
of the buildfarm. It might be good to fix that problem systematically  
somehow, but in the meantime, there are enough test cases for this  
commit that it seems OK to just remove the ones that are failing.  
  
Discussion: http://postgr.es/m/3a190754-b2b0-d02b-dcfd-4ec1610ffbcb@dunslane.net  
Discussion: http://postgr.es/m/CA+TgmoYRGUcFBy6VgN0+Pn4f6Wv=2H0HZLuPHqSy6VC8Ba7vdg@mail.gmail.com  

commit   : 826be1ffb28dde083552150243dbbdcac55ab28e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 22 Apr 2022 11:19:17 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 22 Apr 2022 11:19:17 +0200    

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

commit   : 99c754129d787ea4ce3b34b9f4c5f5e74c45ab6a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 22 Apr 2022 16:02:15 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 22 Apr 2022 16:02:15 +1200    

697492434 added 3 new qsort specialization functions aimed to improve the  
performance of sorting many of the common pass-by-value data types when  
they're the leading or only sort key.  
  
Unfortunately, that has caused a performance regression when sorting  
datasets where many of the values being compared were equal.  What was  
happening here was that we were falling back to the standard sort  
comparison function to handle tiebreaks.  When the two given Datums  
compared equally we would incur both the overhead of an indirect function  
call to the standard comparer to perform the tiebreak and also the  
standard comparer function would go and compare the leading key needlessly  
all over again.  
  
Here improve the situation in the 3 new comparison functions.  We now  
return 0 directly when the two Datums compare equally and we're performing  
a 1-key sort.  
  
Here we don't do anything to help the multi-key sort case where the  
leading key uses one of the sort specializations functions.  On testing  
this case, even when the leading key's values are all equal, there  
appeared to be no performance regression.  Let's leave it up to future  
work to optimize that case so that the tiebreak function no longer  
re-compares the leading key over again.  
  
Another possible fix for this would have been to add 3 additional sort  
specialization functions to handle single-key sorts for these  
pass-by-value types.  The reason we didn't do that here is that we may  
deem some other sort specialization to be more useful than single-key  
sorts.  It may be impractical to have sort specialization functions for  
every single combination of what may be useful and it was already decided  
that further analysis into which ones are the most useful would be delayed  
until the v16 cycle.  Let's not let this regression force our hand into  
trying to make that decision for v15.  
  
Author: David Rowley  
Reviewed-by: John Naylor  
Discussion: https://postgr.es/m/CA+hUKGJRbzaAOUtBUcjF5hLtaSHnJUqXmtiaLEoi53zeWSizeA@mail.gmail.com  

commit   : 92e7a537520927107742af654619e55f34072942    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 17:58:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 17:58:52 -0400    

inline_cte() expected to find exactly as many references to the  
target CTE as its cterefcount indicates.  While that should be  
accurate for the tree as emitted by the parser, there are some  
optimizations that occur upstream of here that could falsify it,  
notably removal of unused subquery output expressions.  
  
Trying to make the accounting 100% accurate seems expensive and  
doomed to future breakage.  It's not really worth it, because  
all this code is protecting is downstream assumptions that every  
referenced CTE has a plan.  Let's convert those assertions to  
regular test-and-elog just in case there's some actual problem,  
and then drop the failing assertion.  
  
Per report from Tomas Vondra (thanks also to Richard Guo for  
analysis).  Back-patch to v12 where the faulty code came in.  
  
Discussion: https://postgr.es/m/29196a1e-ed47-c7ca-9be2-b1c636816183@enterprisedb.com  

commit   : 914611ea738a3601717990faff0f5d71a0f14a3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 17:12:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 17:12:49 -0400    

Commit 618c16707 invented an "error_result" flag in PGconn, which  
intends to represent the state that we have an error condition and  
need to build a PGRES_FATAL_ERROR PGresult from the message text in  
conn->errorMessage, but have not yet done so.  (Postponing construction  
of the error object simplifies dealing with out-of-memory conditions  
and with concatenation of messages for multiple errors.)  For nearly all  
purposes, this "virtual" PGresult object should act the same as if it  
were already materialized.  But a couple of places in fe-protocol3.c  
didn't get that memo, and were only testing conn->result as they used  
to, without also checking conn->error_result.  
  
In hopes of reducing the probability of similar mistakes in future,  
I invented a pgHavePendingResult() macro that includes both tests.  
  
Per report from Peter Eisentraut.  
  
Discussion: https://postgr.es/m/b52277b9-fa66-b027-4a37-fb8989c73ff8@enterprisedb.com  

commit   : 2cb1272445d2a6616991fc6ede274d9f1f62ff73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 16:23:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 16:23:12 -0400    

Commit aa0105141 assigned fixed OIDs to template0 and postgres  
in a very ad-hoc way.  Notably, instead of teaching Catalog.pm  
about these OIDs, the unused_oids script was just hacked to  
not show them as unused.  That's problematic since, for example,  
duplicate_oids wouldn't report any future conflict.  Hence,  
invent a macro DECLARE_OID_DEFINING_MACRO() that can be used to  
define an OID that is known to Catalog.pm and will participate  
in duplicate-detection as well as renumbering by renumber_oids.pl.  
(We don't anticipate renumbering these particular OIDs, but we  
might as well build out all the Catalog.pm infrastructure while  
we're here.)  
  
Another issue is that aa0105141 neglected to touch IsPinnedObject,  
with the result that it now claimed template0 and postgres are  
pinned.  The right thing to do there seems to be to teach it that  
no database is pinned, since in fact DROP DATABASE doesn't check  
for pinned-ness (and at least for these cases, that is an  
intentional choice).  It's not clear whether this wrong answer  
had any visible effect, but perhaps it could have resulted in  
erroneous management of dependency entries.  
  
In passing, rename the TemplateDbOid macro to Template1DbOid  
to reduce confusion (likely we should have done that way back  
when we invented template0, but we didn't), and rename the  
OID macros for template0 and postgres to have a similar style.  
  
There are no changes to postgres.bki here, so no need for a  
catversion bump.  
  
Discussion: https://postgr.es/m/2935358.1650479692@sss.pgh.pa.us  

commit   : 586955dddecc95e0003262a3954ae83b68ce0372    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Apr 2022 19:12:21 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Apr 2022 19:12:21 +0200    

Some places used ZSTD, which isn't widely used anywhere.  Use ZSTD only  
to refer to the environment variable; use zstd (all lowercase) to refer  
to the utility.  
  
Per complaint from Justin Pryzby.  
  
Discussion: https://postgr.es/m/20220414003301.GT26620@telsasoft.com  

commit   : bb85eec6fe9178aa849b43414f2db440bb5edfbd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Apr 2022 18:57:40 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Apr 2022 18:57:40 +0200    

Prompted by a complaint from Justin Pryzby.  
  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/20220414003301.GT26620@telsasoft.com  

commit   : 40eba064b24d98e343b45ccef6907fe8c9784dc1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 12:02:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2022 12:02:23 -0400    

This is needed so that renumber_oids.pl can handle renumbering  
shared catalog declarations, which need to provide C macros for  
the OIDs of the shared toast table and index.  The previous  
method of writing a C macro separately was error-prone anyway.  
  
Also teach renumber_oids.pl about DECLARE_UNIQUE_INDEX_PKEY,  
as we missed doing when inventing that macro.  
  
There are no changes to postgres.bki here, so no need for a  
catversion bump.  
  
Discussion: https://postgr.es/m/2995325.1650487527@sss.pgh.pa.us  

commit   : 4eea2202beadbba67638bb129149abe5650aaaf6    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 21 Apr 2022 15:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 21 Apr 2022 15:30:00 +0900    

Previously, we allowed this, but such triggers might query the table to  
insert into and act differently if the tuples that have already been  
processed and prepared for insertion are not there, so disable it in  
such cases.  
  
Back-patch to v14 where batch insert was added.  
  
Discussion: https://postgr.es/m/CAPmGK16_uPqsmgK0-LpLSUk54_BoK13bPrhxhfjSoSTVz414hA%40mail.gmail.com  

commit   : ba6af6aa0b764d76cfca79d9dfbddc7134a16bfc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 20 Apr 2022 18:29:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 20 Apr 2022 18:29:02 -0700    

Oversights in commits 0b018fab and f3c15cbe.  

commit   : 8ab0ebb9a842dc6063d1374a38b47a3b7ee64afe    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 20 Apr 2022 17:17:43 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 20 Apr 2022 17:17:43 -0700    

CLUSTER sort won't use the datum1 SortTuple field when clustering  
against an index whose leading key is an expression.  This makes it  
unsafe to use the abbreviated keys optimization, which was missed by the  
logic that sets up SortSupport state.  Affected tuplesorts output tuples  
in a completely bogus order as a result (the wrong SortSupport based  
comparator was used for the leading attribute).  
  
This issue is similar to the bug fixed on the master branch by recent  
commit cc58eecc5d.  But it's a far older issue, that dates back to the  
introduction of the abbreviated keys optimization by commit 4ea51cdfe8.  
  
Backpatch to all supported versions.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Author: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/CA+hUKG+bA+bmwD36_oDxAoLrCwZjVtST2fqe=b4=qZcmU7u89A@mail.gmail.com  
Backpatch: 10-  

commit   : eafdf9de06e9b60168f5e47cedcfceecdc6d4b5f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2022 18:08:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2022 18:08:15 -0400    

Such cases will lead to infinite loops, so they're of no practical  
value.  The numeric variant of generate_series() already threw error  
for this, so borrow its message wording.  
  
Per report from Richard Wesley.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/91B44E7B-68D5-448F-95C8-B4B3B0F5DEAF@duckdblabs.com  

commit   : d2d35479796c3510e249d6fc72adbd5df918efbf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2022 11:02:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2022 11:02:35 -0400    

psql, pg_dump, and pg_amcheck share code to process object name  
patterns like 'foo*.bar*' to match all tables with names starting in  
'bar' that are in schemas starting with 'foo'. Before v14, any number  
of extra name parts were silently ignored, so a command line '\d  
foo.bar.baz.bletch.quux' was interpreted as '\d bletch.quux'.  In v14,  
as a result of commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868, we  
instead treated this as a request for table quux in a schema named  
'foo.bar.baz.bletch'. That caused problems for people like Justin  
Pryzby who were accustomed to copying strings of the form  
db.schema.table from messages generated by PostgreSQL itself and using  
them as arguments to \d.  
  
Accordingly, revise things so that if an object name pattern contains  
more parts than we're expecting, we throw an error, unless there's  
exactly one extra part and it matches the current database name.  
That way, thisdb.myschema.mytable is accepted as meaning just  
myschema.mytable, but otherdb.myschema.mytable is an error, and so  
is some.random.garbage.myschema.mytable.  
  
Mark Dilger, per report from Justin Pryzby and discussion among  
various people.  
  
Discussion: https://www.postgresql.org/message-id/20211013165426.GD27491%40telsasoft.com  

commit   : 836af9756b742f5a8ae77b4bef9d27311772a13c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2022 11:04:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2022 11:04:28 -0400    

Historically we've been lax about this, but seeing that we're not  
lax in C files, there doesn't seem to be a good reason to be so  
in the documentation.  Remove the existing occurrences (mostly  
though not entirely in copied-n-pasted psql output), and modify  
.gitattributes so that "git diff --check" will warn about future  
cases.  
  
While at it, add *.pm to the set of extensions .gitattributes  
knows about, and remove some obsolete entries for files that  
we don't have in the tree anymore.  
  
Per followup discussion of commit 5a892c9b1.  
  
Discussion: https://postgr.es/m/E1nfcV1-000kOR-E5@gemulon.postgresql.org  

commit   : 6c0f9f60f1c24aead1bfdd0ed294ac5b6f1d1ac1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 20 Apr 2022 16:11:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 20 Apr 2022 16:11:14 +0200    

commit   : e70813fbc4aaca35ec012d5a426706bd54e4acab    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Apr 2022 11:44:08 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Apr 2022 11:44:08 +0200    

Coverity complains that dpns->outer_plan is deferenced (to obtain  
->targetlist) when possibly NULL.  We can avoid this by using  
dpns->outer_tlist instead, which was already obtained a few lines up.  
  
The fact that we end up with  
  dpns->inner_tlist = dpns->outer_tlist  
is a bit suspicious-looking and maybe worthy of more investigation, but  
I'll leave that for another day.  
  
Reviewed-by: Michaël Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/202204191345.qerjy3kxi3eb@alvherre.pgsql  

commit   : a87e75956926f966d90bdd1a6bd495cf59cdc3ad    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Apr 2022 11:18:04 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Apr 2022 11:18:04 +0200    

Should have been done this way to start with, but I failed to notice  
This way we avoid some pointless initialization, and better contains the  
variable to exist in the scope where it is really used.  
  
Reviewed-by: Michaël Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/202204191345.qerjy3kxi3eb@alvherre.pgsql  

commit   : 3dcc6bf4068a29be2bebee80bb919f8057af0fd9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Apr 2022 10:34:58 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Apr 2022 10:34:58 +0200    

There's no reason to keep a separate local variable when we have a place  
for it elsewhere.  This allows to simplify some code.  
  
Reviewed-by: Michaël Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/202204191345.qerjy3kxi3eb@alvherre.pgsql  

commit   : 74547b9c23f9f7ecfc6511e055982b8d5f51ae88    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 20 Apr 2022 08:59:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 20 Apr 2022 08:59:55 +0530    

We have some streaming tests that rely on the size of changes which can  
fail if there are additional changes like invalidation messages by  
background activity like auto analyze. Avoid such failures by increasing  
autovacuum_naptime to a reasonably high value (1d).  
  
Author: Dilip Kumar  
Backpatch-through: 14  
Discussion: https://postgr.es/m/1958043.1650129119@sss.pgh.pa.us  

commit   : 7bdd489d3d32d6ab5af1d2b22eaf8cc7dc148027    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 20 Apr 2022 15:17:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 20 Apr 2022 15:17:56 +1200    

Similarly to what was done in 04539e73f, we standardized on SQL being  
pronounced "es-que-ell" rather than "sequel" in our documentation.  
  
Two inconsistencies have crept in during the v15 cycle.  The others  
existed before but were missed in 04539e73f due to none of the searches  
accounting for "SQL" being wrapped in tags.  
  
As with 04539e73f, we don't touch code comments here in order to not  
create unnecessary back-patching pain.  
  
Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com  

commit   : 344a225cb9d42f20df063e4d0e0d4559c5de7910    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2022 23:03:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2022 23:03:59 -0400    

An ALTER FUNCTION command that tried to update both the function's  
proparallel property and its proconfig list failed to do the former,  
because it stored the new proparallel value into a tuple that was  
no longer the interesting one.  Carelessness in 7aea8e4f2.  
  
(I did not bother with a regression test, because the only likely  
future breakage would be for someone to ignore the comment I added  
and add some other field update after the heap_modify_tuple step.  
A test using existing function properties could not catch that.)  
  
Per report from Bryn Llewellyn.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/8AC9A37F-99BD-446F-A2F7-B89AD0022774@yugabyte.com  

commit   : 83cca409edf276cfbd2ff691ceea1b10027c5205    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Apr 2022 11:05:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Apr 2022 11:05:34 +0900    

Oversight in 39969e2.  
  
Author: Martín Marqués  
Discussion: https://postgr.es/m/CABeG9LviA01oHC5h=ksLUuhMyXxmZR_tftRq6q3341CMT=j=4g@mail.gmail.com  

commit   : f2a2bf66c87e14f07aefe23cbbe2f2d9edcd9734    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 19 Apr 2022 20:38:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 19 Apr 2022 20:38:53 +0200    

The new numeric code for extract epoch from interval accidentally  
truncated the DAYS_PER_YEAR value to an integer, leading to results  
that mismatched the floating-point interval_part calculations.  
  
The commit a2da77cdb4661826482ebf2ddba1f953bc74afe4 that introduced  
this actually contains the regression test change that this reverts.  
I suppose this was missed at the time.  
  
Reported-by: Joseph Koshakow <koshy44@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/CAAvxfHd5n%3D13NYA2q_tUq%3D3%3DSuWU-CufmTf-Ozj%3DfrEgt7pXwQ%40mail.gmail.com  

commit   : a62bff74b135b191de0417d1cc8ec52f144c8fe7    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 19 Apr 2022 17:04:27 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 19 Apr 2022 17:04:27 +0900    

Remove meaningless "failures" column from the aggregate logging. It  
was just a sum of "serialization failures" and "deadlock failures".  
Pointed out by Tom Lane. Patch reviewed by Fabien COELHO.  
  
Discussion: https://postgr.es/m/4183048.1649536705%40sss.pgh.pa.us  

commit   : dd4ab6fd6528e160571986fa8817cee9f2645aa8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Apr 2022 08:49:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 19 Apr 2022 08:49:49 +0530    

We don't allow to invoke more sync workers once we have reached the sync  
worker limit per subscription. But the check to enforce this also doesn't  
allow to launch an apply worker if it gets restarted.  
  
This code was introduced by commit de43897122 but we caught the problem  
only with the test added by recent commit c91f71b9dc which started failing  
occasionally in the buildfarm.  
  
As per buildfarm.  
Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra  
Author: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com  
	    https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e797c8@enterprisedb.com  

commit   : 587de223f03e6086d511dab16b17406eb21277ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2022 20:04:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2022 20:04:55 -0400    

It failed to provide an error string as expected for the  
admittedly-unlikely case of OOM in pg_cryptohash_create().  
Also, make it initialize *errstr to NULL for success,  
as pg_md5_binary() does.  
  
Also add missing comments.  Readers should not have to  
reverse-engineer the API spec for a publicly visible routine.  

commit   : 36d4efe779bfc7190ea1c1cf8deb0d945b726663    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2022 12:16:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2022 12:16:45 -0400    

Don't try to look at the attidentity field of system attributes,  
because they're not there in the TupleDescAttr array.  Sometimes  
this is harmless because we accidentally pick up a zero, but  
otherwise we'll report "no owned sequence found" from an attempt  
to alter a system attribute.  (It seems possible that a SIGSEGV  
could occur, too, though I've not seen it in testing.)  
  
It's not in this function's charter to complain that you can't  
alter a system column, so instead just hard-wire an assumption  
that system attributes aren't identities.  I didn't bother with  
a regression test because the appearance of the bug is very  
erratic.  
  
Per bug #17465 from Roman Zharkov.  Back-patch to all supported  
branches.  (There's not actually a live bug before v12, because  
before that get_attidentity() did the right thing anyway.  
But for consistency I changed the test in the older branches too.)  
  
Discussion: https://postgr.es/m/17465-f2a554a6cb5740d3@postgresql.org  

commit   : 1a8b110539efe18803c1fa8aa452a2178dbad9a9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Apr 2022 13:41:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Apr 2022 13:41:40 +0900    

Checking the execution of archive_cleanup_command on a standby requires  
a valid checkpoint coming from its primary, but the logic did not check  
that the standby replayed up to the point of the checkpoint, causing the  
test checking for the execution of archive_cleanup_command to fail.  
This race was more visible in slow environments.  
  
Issue introduced in 46dea24, so no backpatch is needed.  
  
Author: Tom Lane  
Discussion: https://postgr.es/m/4015413.1649454951@sss.pgh.pa.us  

commit   : 676eeb6dd1655f7a3ee783b7ca0d645580630acc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 Apr 2022 08:42:37 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 Apr 2022 08:42:37 +0530    

Commit 52e4f0cd47 added a feature to allow specifying row filters for  
logical replication of tables. This patch adds detailed documentation on  
that feature including examples to make it easier for users to understand.  
  
Author: Peter Smith, Euler Taveira  
Reviewed By: Greg Nancarrow, Aleksander Alekseev, Amit Kapila, Ajin Cherian, Alvaro Herrera  
Discussion: https://postgr.es/m/CAHut+PtnsBr59=_NvxXp_=S-em0WxyuDOQmSTuHGb4sVhkHffg@mail.gmail.com  

commit   : e61efafcb82c605dcc78f668685223e20d2f7ad8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Apr 2022 11:39:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Apr 2022 11:39:50 +0900    

This test, introduced in df86e52, uses a second standby to check that  
it is able to remove correctly RECOVERYHISTORY and RECOVERYXLOG at the  
end of recovery.  This standby uses the archives of the primary to  
restore its contents, with some of the archive's contents coming from  
the first standby previously promoted.  In slow environments, it was  
possible that the test did not check what it should, as the history file  
generated by the promotion of the first standby may not be stored yet on  
the archives the second standby feeds on.  So, it could be possible that  
the second standby selects an incorrect timeline, without restoring a  
history file at all.  
  
This commits adds a wait phase to make sure that the history file  
required by the second standby is archived before this cluster is  
created.  This relies on poll_query_until() with pg_stat_file() and an  
absolute path, something not supported in REL_10_STABLE.  
  
While on it, this adds a new test to check that the history file has  
been restored by looking at the logs of the second standby.  This  
ensures that a RECOVERYHISTORY, whose removal needs to be checked,  
is created in the first place.  This should make the test more robust.  
  
This test has been introduced by df86e52, but it came in light as an  
effect of the bug fixed by acf1dd42, where the extra restore_command  
calls made the test much slower.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/YlT23IvsXkGuLzFi@paquier.xyz  
Backpatch-through: 11  

commit   : 42e44f3b3830cbc051a5d83956546e2ef553b047    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Apr 2022 10:18:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Apr 2022 10:18:34 +0900    

The new option set of pg_receivewal introduced in 042a923 to control the  
compression method makes it now easy to pass down various options,  
including the compression level.  The change to be able to do is simple,  
and requires one LZ4F_preferences_t fed to LZ4F_compressBegin().  
  
Note that LZ4F_INIT_PREFERENCES could be used to initialize the contents  
of LZ4F_preferences_t as required by LZ4, but this is only available  
since v1.8.3.  memset()'ing its structure to 0 is enough.  
  
Discussion: https://postgr.es/m/YlPQGNAAa04raObK@paquier.xyz  

commit   : 42dbbca58e8e87e461bb0a4fe48a450e90e1e932    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Apr 2022 17:43:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Apr 2022 17:43:54 -0700    

The target failed, tested $PATH binaries, or tested a stale temporary  
installation.  Commit c66b438db62748000700c9b90b585e756dd54141 missed  
this.  Back-patch to v10 (all supported versions).  

commit   : acf1dd42342d6d84ca8e7a1998335e2e8809759e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 17 Apr 2022 10:22:03 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 17 Apr 2022 10:22:03 +1200    

Suppress further attempts to read ahead in the WAL if we run out of  
data, until the records already decoded have been replayed.  This  
restores the traditional behavior for continuous archive recovery, which  
is to retry the failing restore_command only every 5 seconds.  With the  
coding in 5dc0418f, we would start retrying every time through the  
recovery loop when our WAL decoding window hit the end of the current  
segment and we tried to look ahead into a not-yet-available next file.  
That was very slow.  
  
Also change the no_readahead_until mechanism to use <= rather than <,  
which seems more useful.  Otherwise we'd either get one extra unwanted  
retry of restore_command, or we'd need to add 1 to an LSN.  
  
No change in behavior for regular streaming.  That was already limited  
by the flushedUpto variable, which won't be updated until we replay what  
we have already.  
  
Reported by Andres Freund while analyzing the failure of a TAP test on  
build farm animal skink (investigation ongoing but probably due to  
otherwise unrelated timing bugs triggered by this slowness magnified by  
valgrind).  
  
Discussion: https://postgr.es/m/20220409005910.alw46xqmmgny2sgr%40alap3.anarazel.de  

commit   : 4a736a161c306fcfed970e6b649f2f03f465ac24    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 16 Apr 2022 12:13:31 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 16 Apr 2022 12:13:31 -0700    

Previously we didn't, which lead to an assertion failure when resetting  
partially loaded statistics. This was encountered on the buildfarm, for  
as-of-yet unknown reasons.  
  
Ttighten up a validity check when reading the stats file, verifying 'E'  
signals the end of the file (rather than just stopping reading). That's then  
used in a test appending to the stats file that crashed before the fix in  
pgstat_drop_all_entries().  
  
Reported by buildfarm animals mylodon and kestrel, via Tom Lane.  
  
Discussion: https://postgr.es/m/1656446.1650043715@sss.pgh.pa.us  

commit   : 9f4f0a0dad4c7422a97d94e4051c08ec6d181dd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Apr 2022 16:04:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Apr 2022 16:04:50 -0400    

This function gave the wrong answer when there's more than one  
RegisteredSnapshots entry, whether or not any of them is the  
CatalogSnapshot.  This leads to assertion failure in some scenarios  
involving fetching toasted data using a cursor.  (As per discussion,  
I'm dubious that this is the right contract to be enforcing at all;  
but it surely doesn't help to be enforcing it incorrectly.)  
  
Fetching toasted data using a cursor is evidently under-tested,  
so add a test case too.  
  
Per report from Erik Rijkers.  This is new code, so no need for  
back-patch.  
  
Discussion: https://postgr.es/m/dc9dd229-ed30-6c62-4c41-d733ffff776b@xs4all.nl  

commit   : a17fd67d2f2861ae0ce00d1aeefdf2facc47cd5e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 16 Apr 2022 09:35:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 16 Apr 2022 09:35:15 -0400    

This allows the newly added TAP tests to run.  

commit   : 5a892c9b154f513a42c4a42cdfdae524ce33c86a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 16 Apr 2022 09:05:07 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 16 Apr 2022 09:05:07 +0200    

commit   : 5fbb2d8f105efee1d059a7edb86f45e38616d329    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 15 Apr 2022 23:15:38 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 15 Apr 2022 23:15:38 -0700    

Per buildfarm member mandrill.  The test is new in v15, so no back-patch.  

commit   : d3609dd2547b3ed807bc3b6dd27a008d65e86668    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 15 Apr 2022 15:48:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 15 Apr 2022 15:48:39 -0700    

Per-backend global variables like VacuumPageHit are initialized once per  
VACUUM command.  This was missed by commit 49c9d9fc, which unified  
VACUUM VERBOSE and autovacuum logging.  As a result of that oversight,  
incorrect values were shown when multiple relations were processed by a  
single VACUUM VERBOSE command.  
  
Relations that happened to be processed later on would show "buffer  
usage:" values that incorrectly included buffer accesses made while  
processing earlier unrelated relations.  The same accesses were counted  
multiple times.  
  
To fix, take initial values for the tracker variables at the start of  
heap_vacuum_rel(), and report delta values later on.  

commit   : 7129a9791eafdd825eae0187b7dd7b99ed48fdc7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2022 18:31:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2022 18:31:01 -0400    

With a pre-v15 server, show NULL for the "ICU Locale" column,  
matching what you see in v15 when the database locale isn't ICU.  
The previous coding incorrectly repeated datcollate here.  
  
(There's an unfinished discussion about whether to consolidate  
these columns in \l output, but in any case we'd want this fix  
for \l+ output.)  
  
Euler Taveira, per report from Christoph Berg  
  
Discussion: https://postgr.es/m/YlmIFCqu+TZSW4rB@msg.df7cb.de  

commit   : 6fea65508a1aa6a1caa5f3e7b4d27bcccb0740d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2022 17:50:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2022 17:50:01 -0400    

ComputeXidHorizons (nee GetOldestXmin) thought that it could identify  
walsenders by checking for proc->databaseId == 0.  Perhaps that was  
safe when the code was written, but it's been wrong at least since  
autovacuum was invented.  Background processes that aren't connected  
to any particular database, such as the autovacuum launcher and  
logical replication launcher, look like that too.  
  
This imprecision is harmful because when such a process advertises an  
xmin, the result is to hold back dead-tuple cleanup in all databases,  
though it'd be sufficient to hold it back in shared catalogs (which  
are the only relations such a process can access).  Aside from being  
generally inefficient, this has recently been seen to cause regression  
test failures in the buildfarm, as a consequence of the logical  
replication launcher's startup transaction preventing VACUUM from  
marking pages of a user table as all-visible.  
  
We only want that global hold-back effect for the case where a  
walsender is advertising a hot standby feedback xmin.  Therefore,  
invent a new PGPROC flag that says that a process' xmin should be  
considered globally, and check that instead of using the incorrect  
databaseId == 0 test.  Currently only a walsender sets that flag,  
and only if it is not connected to any particular database.  (This is  
for bug-compatibility with the undocumented behavior of the existing  
code, namely that feedback sent by a client who has connected to a  
particular database would not be applied globally.  I'm not sure this  
is a great definition; however, such a client is capable of issuing  
plain SQL commands, and I don't think we want xmins advertised for  
such commands to be applied globally.  Perhaps this could do with  
refinement later.)  
  
While at it, I rewrote the comment in ComputeXidHorizons, and  
re-ordered the commented-upon if-tests, to make them match up  
for intelligibility's sake.  
  
This is arguably a back-patchable bug fix, but given the lack of  
complaints I think it prudent to let it age awhile in HEAD first.  
  
Discussion: https://postgr.es/m/1346227.1649887693@sss.pgh.pa.us  

commit   : bdb71dbe80d0560f84255e05b73f449e11007325    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 15 Apr 2022 14:20:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 15 Apr 2022 14:20:56 -0700    

Be consistent about the lines that VACUUM VERBOSE outputs by including  
an "index scan not needed: " line for completely empty tables. This  
makes the output more readable, especially with multiple distinct VACUUM  
operations processed by the same VACUUM command.  It's also more  
consistent; even empty tables can use the failsafe, which wasn't  
reported in the standard way until now.  
  
Follow-up to commit 6e20f460, which taught VACUUM VERBOSE to be more  
consistent about reporting on scanned pages with empty tables.  

commit   : 357c8455e64915f2d8f50ca5853eb91b74470d96    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 15 Apr 2022 13:21:43 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 15 Apr 2022 13:21:43 -0700    

The age of OldestXmin (a.k.a. "removable cutoff") when VACUUM ends often  
indicates the approximate number of XIDs consumed while VACUUM ran.  
However, there is at least one important exception: the cutoff could be  
held back by a snapshot that was acquired before our VACUUM even began.  
Successive VACUUM operations may even use exactly the same old cutoff in  
extreme cases involving long held snapshots.  
  
The log messages that described how removable cutoff aged (which were  
added by commit 872770fd) created the impression that we were reporting  
on how VACUUM's usable cutoff advanced while VACUUM ran, which was  
misleading in these extreme cases.  Fix by using a more general wording.  
  
Per gripe from Tom Lane.  
  
In passing, relocate related instrumentation code for clarity.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/1643035.1650035653@sss.pgh.pa.us  

commit   : 91998539b227dfc6dd091714da7d106f2c95a321    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2022 13:29:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2022 13:29:39 -0400    

This reverts commit 5bb2b6abc8d6cf120a814317816e4384bcbb9c1e.  
Not needed anymore.