PostgreSQL 14.0 (upcoming) commit log

commit   : 6206454bdac1ccd6f6ed9d811e1a1139e663a8b9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 14:36:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 14:36:21 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 1c361d3ac016b61715d99f2055dee050397e3f13  

commit   : fa8fbadb934b4727a7aeff074995e799f4685a75    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 11:36:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 11:36:26 +0200    

When building without --enable-dtrace, emit dummy  
  
    do {} while (0)  
  
statements for the stubbed-out TRACE_POSTGRESQL_foo() macros  
instead of empty macros that totally elide the original probe  
statement.  
  
This fixes the  
  
    warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]  
  
introduced by b94409a02f.  
  
Author: Craig Ringer <craig.ringer@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/20210504221531.cfvpmmdfsou6eitb%40alap3.anarazel.de  

commit   : 3c554100307f4e57c0881e205dbdbc173bb84d56    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 10:02:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 10:02:33 +0200    

Was present in original commit  
198b3716dba68544b55cb97bd120738a86d5df2d but apparently never used.  

commit   : 829daab4bbe356a2f9ae0b2ee0fc98bc2279d754    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 15:45:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 15:45:54 +0900    

Author: Kyotaro Horiguchi, Justin Pryzby  
Discussion: https://postgr.es/m/20210428.173633.1525059946206239295.horikyota.ntt@gmail.com  

commit   : dc0260861063b125d297c0f3caca359feb381c6a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 10 May 2021 01:58:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 10 May 2021 01:58:59 -0400    

commit   : 45aa88fe1d4028ea50ba7d26d390223b6ef78acc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 14:34:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 14:34:07 +0900    

"make dist", in charge of creating a distribution tarball, failed when  
attempting to generate ./INSTALL as a new reference added to  
guc-default-toast-compression on the documentation for the installation  
details was not getting translated properly to plain text.  Like all the  
other link references on this page, this adds a new entry to  
standalone-profile.xsl to allow the generation of ./INSTALL to finish  
properly.  
  
Oversight in 02a93e7, per buildfarm member guaibasaurus.  

commit   : c2dc19342e05e081dc13b296787baa38352681ef    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 10 May 2021 16:00:53 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 10 May 2021 16:00:53 +1200    

This set of commits has some bugs with known fixes, but at this late  
stage in the release cycle it seems best to revert and resubmit next  
time, along with some new automated test coverage for this whole area.  
  
Commits reverted:  
  
dc88460c: Doc: Review for "Optionally prefetch referenced data in recovery."  
1d257577: Optionally prefetch referenced data in recovery.  
f003d9f8: Add circular WAL decoding buffer.  
323cbe7c: Remove read_page callback from XLogReader.  
  
Remove the new GUC group WAL_RECOVERY recently added by a55a9847, as the  
corresponding section of config.sgml is now reverted.  
  
Discussion: https://postgr.es/m/CAOuzzgrn7iKnFRsB4MHp3UisEQAGgZMbk_ViTN4HV4-Ksq8zCg%40mail.gmail.com  

commit   : 63db0ac3f9e6bae313da67f640c95c0045b7f0ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 11:12:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 11:12:07 +0900    

Some relations with LZ4 used as the toast compression methods have been  
left around in the main regression test suite to stress pg_upgrade, but  
pg_dump, that includes tests much more picky in terms of output  
generated, had no actual coverage with this feature.  
  
Similarly to collations, tests only working with LZ4 are tracked with an  
additional flag, and this uses TestLib::check_pg_config() to check if  
the build supports LZ4 or not.  This stresses more scenarios with  
tables, materialized views and pg_dump --no-toast-compression.  
  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAFiTN-twgPmohG7qj1HXhySq16h123y5OowsQR+5h1YeZE9fmQ@mail.gmail.com  

commit   : 02a93e7ef9612788081ef07ea1bbd0a8cc99ae99    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 09:30:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 10 May 2021 09:30:35 +0900    

The upstream project is officially named "LZ4", and the documentation  
was confused with the option value that can be used with DDLs supporting  
this option, and the project name.  
  
Documentation related to the configure option --with-lz4 was missing, so  
add something for that.  
  
Author: Dilip Kumar, Michael Paquier  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/YJaOZQDXBVySq+Cc@paquier.xyz  

commit   : 8dc3d68cbe676deb5e74d1b1b565f57fffaf107e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 May 2021 19:33:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 May 2021 19:33:24 -0400    

These comments left the impression that USE_VALGRIND isn't really  
essential for valgrind testing.  But that's wrong, as I learned  
the hard way today.  
  
Discussion: https://postgr.es/m/512778.1620588546@sss.pgh.pa.us  

commit   : 92c4c269d24d016c19858a21347ff25a7de1f486    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 9 May 2021 11:37:18 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 9 May 2021 11:37:18 +1200    

In 9eacee2e6, I included some code to verify the cache's memory tracking  
is correct by counting up the number of entries and the memory they use  
each time we evict something from the cache.  Those values are then  
compared to the expected values using Assert.  The problem is that this  
requires looping over the entire cache hash table each time we evict an  
entry from the cache.  That can be pretty expensive, as noted by Pavel  
Stehule.  
  
Here we move this memory accounting checking code so that we only verify  
it on cassert builds once when shutting down the Result Cache node.  
  
Aside from the performance increase, this has two distinct advantages:  
  
1) We do the memory checks at the last possible moment before destroying  
   the cache.  This means we'll now catch accounting problems that might  
   sneak in after a cache eviction.  
  
2) We now do the memory Assert checks when there were no cache evictions.  
   This increases the coverage.  
  
One small disadvantage is that we'll now miss any memory tracking issues  
that somehow managed to resolve themselves by the end of execution.  
However, it seems to me that such a memory tracking problem would be quite  
unlikely, and likely somewhat less harmful if one were to exist.  
  
In passing, adjust the loop over the hash table to use the standard  
simplehash.h method of iteration.  
  
Reported-by: Pavel Stehule  
Discussion: https://postgr.es/m/CAFj8pRAzgoSkdEiqrKbT=7yG9FA5fjUAP3jmJywuDqYq6Ki5ug@mail.gmail.com  

commit   : a55a98477b690dedb9b4368d7e5710c8e7fa534e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 May 2021 12:13:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 May 2021 12:13:33 -0400    

It seems that various people have moved GUCs around in the config.sgml  
listing without bothering to make the code agree.  Ensure that the  
config_group codes assigned to GUCs match where they are listed in  
config.sgml.  Likewise ensure that postgresql.conf.sample lists GUCs  
in the same sub-section and same ordering as they appear in config.sgml.  
  
(I've got some doubts about some of these choices, but for the purposes  
of this patch, we'll treat config.sgml as gospel.)  
  
Notably, this requires adding a WAL_RECOVERY config_group value,  
because 1d257577e didn't.  As long as we're renumbering that enum  
anyway, let's take out the values corresponding to major groups  
that are divided into sub-groups.  No GUC should be assigned to the  
major group itself, so those values just create a temptation to  
do the wrong thing, while adding work for translators.  
  
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs  
to uniformly use the phrasing "Shows XYZ.", removing the impression  
some of these strings left that you can set the value.  
  
While some of these errors are old, no back-patch, as changing the  
contents of the pg_settings view in stable branches seems more likely  
to be seen as a compatibility break than anything helpful.  
  
Bharath Rupireddy, Justin Pryzby, Tom Lane  
  
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org  
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com  

commit   : f9b809e7fbe36cd3fe1ce33edb277288a31da386    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 May 2021 11:33:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 May 2021 11:33:13 -0400    

I came to fix "useful only useful", but the more I looked at the text  
the more things I thought could be improved.  

commit   : 9681f2160dcbe2a02fd2e2db2322ea204eff6562    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 8 May 2021 10:18:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 8 May 2021 10:18:05 +0900    

Specifying an incorrect value for the compression method of an attribute  
caused ERRCODE_FEATURE_NOT_SUPPORTED to be raised as error.  Use instead  
ERRCODE_INVALID_PARAMETER_VALUE to be more consistent.  
  
Author: Dilip Kumar  
Discussion: https://postgr.es/m/CAFiTN-vH84fE-8C4zGZw4v0Wyh4Y2v=5JWg2fGE5+LPaDvz1GQ@mail.gmail.com  

commit   : c6a01d924939306e95c8deafd09352be6a955648    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 22:29:43 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 22:29:43 +0200    

When executing the INSERT with batching, we may need to rebuild the  
query when the batch size changes, in which case we pfree the current  
string. We must not release the original string, stored in fdw_private,  
because that may be needed in EXPLAIN ANALYZE. So make copy of the SQL,  
but only for INSERT queries.  
  
Reported-by: Pavel Stehule  
Discussion: https://postgr.es/m/CAFj8pRCL_Rjw-MCR6J7VX9OF7MR6PA5K8qUbrMvprW_e-aHkfQ%40mail.gmail.com  

commit   : 8292c0675a793a5afd0a8eedbeb0db7abfb844f3    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 7 May 2021 14:27:18 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 7 May 2021 14:27:18 -0400    

Discussion: https://postgr.es/m/20210506035602.3akutfvvojngj3nb@alap3.anarazel.de  

commit   : 9f989a8581cc37879d493a5a78b0f01ec0e3245a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 7 May 2021 17:47:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 7 May 2021 17:47:22 +0200    

commit   : 4e8c0f1a0d0d095a749a329a216c88a340a455b6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 May 2021 11:46:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 May 2021 11:46:37 -0400    

This patch replaces use of the global "wrconn" variable in  
AlterSubscription_refresh with a local variable of the same name, making  
it consistent with other functions in subscriptioncmds.c (e.g.  
DropSubscription).  
  
The global wrconn is only meant to be used for logical apply/tablesync worker.  
Abusing it this way is known to cause trouble if an apply worker  
manages to do a subscription refresh, such as reported by Jeremy Finzel  
and diagnosed by Andres Freund back in November 2020, at  
https://www.postgresql.org/message-id/20201111215820.qihhrz7fayu6myfi@alap3.anarazel.de  
  
Backpatch to 10.  In branch master, also move the connection establishment  
to occur outside the PG_TRY block; this way we can remove a test for NULL in  
PG_FINALLY, and it also makes the code more consistent with similar code in  
the same file.  
  
Author: Peter Smith <peter.b.smith@fujitsu.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/CAHut+Pu7Jv9L2BOEx_Z0UtJxfDevQSAUW2mJqWU+CtmDrEZVAg@mail.gmail.com  

commit   : 8b82de0164c13eb3b113a525dc7eda7887f5238b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 7 May 2021 11:37:37 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 7 May 2021 11:37:37 -0400    

commit   : 8fa6e6919c1aaa6f74c74e16452aaf0b5f3b4cd5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 7 May 2021 10:56:14 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 7 May 2021 10:56:14 -0400    

commit   : 44f90ad092f95fe19bebb51465193bc63849c15f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 14:02:22 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 14:02:22 +0200    

The docs mentioned expression indexes as a way to improve selectivity  
estimates for functions, but we have a second option to improve that by  
creating extended statistics. So mention that too.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210505210947.GA27406%40telsasoft.com  

commit   : 93f9af138795a7d12366187de95f4961fb07ed98    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 13:57:29 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 13:57:29 +0200    

Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210505210947.GA27406%40telsasoft.com  

commit   : 8d4b311d2494ca592e30aed03b29854d864eb846    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 13:56:32 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 7 May 2021 13:56:32 +0200    

The usual behavior for functions in ruleutils.c is to return NULL when  
the object does not exist. pg_get_statisticsobjdef_expressions raised an  
error instead, so correct that.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210505210947.GA27406%40telsasoft.com  

commit   : b65431ca5e12a475ba7cf68afb63edb070c2ce08    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 7 May 2021 21:47:08 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 7 May 2021 21:47:08 +1200    

The per-index collation version tracking feature was reverted, but we  
still have the ability to ask Windows (352f6f2d) and FreeBSD  
(ca051d8b) for collation versions to store in pg_collation.collversion.  
So, from the reverted patch, take a few words of documentation about  
libc on all three supported OSes to replace the pre-existing note that  
mentioned only glibc.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLhj5t1fcjqAu8iD9B3ixJtsTNqyCCD4V0aTO9kAKAjjA%40mail.gmail.com  

commit   : ec48314708262d8ea6cdcb83f803fc83dd89e721    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 7 May 2021 20:17:42 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 7 May 2021 20:17:42 +1200    

Design problems were discovered in the handling of composite types and  
record types that would cause some relevant versions not to be recorded.  
Misgivings were also expressed about the use of the pg_depend catalog  
for this purpose.  We're out of time for this release so we'll revert  
and try again.  
  
Commits reverted:  
  
1bf946bd: Doc: Document known problem with Windows collation versions.  
cf002008: Remove no-longer-relevant test case.  
ef387bed: Fix bogus collation-version-recording logic.  
0fb0a050: Hide internal error for pg_collation_actual_version(<bad OID>).  
ff942057: Suppress "warning: variable 'collcollate' set but not used".  
d50e3b1f: Fix assertion in collation version lookup.  
f24b1569: Rethink extraction of collation dependencies.  
257836a7: Track collation versions for indexes.  
cd6f479e: Add pg_depend.refobjversion.  
7d1297df: Remove pg_collation.collversion.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLhj5t1fcjqAu8iD9B3ixJtsTNqyCCD4V0aTO9kAKAjjA%40mail.gmail.com  

commit   : a288d94c91e345ebeb10ac30f247270c8c8e380a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 17:28:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 17:28:36 -0400    

Author: Amul Sul <sulamul@gmail.com>  
Reviewed-by: Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/CAAJ_b94HaNcrPVREUuB9-qUn2uB+gfcoX3FG_Vx0S6aFse+yhw@mail.gmail.com  

commit   : 469116389e18dbf6be0bd555bc2055a26be91a48    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 17:17:57 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 17:17:57 -0400    

Backpatch all the way back to 9.6.  
  
Author: Simon Riggs <simon.riggs@enterprisedb.com>  
Discussion: https://postgr.es/m/CANbhV-EwxvdhHuOLdfG2ciYrHOHXV=mm6=fD5aMhqcH09Li3Tg@mail.gmail.com  

commit   : db6e1aeb952e9aed26ba2a56b4145293c72b8068    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 16:42:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 16:42:30 -0400    

This was forgotten in 71f4c8c6f74b.  
  
Reported-by: Pavel Luzanov <p.luzanov@postgrespro.ru>  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/0688e7c3-8bc8-a3e4-9d8e-3bcbbf3e1f4d@postgrespro.ru  

commit   : c9787385db47ba423d845b34d58e158551c6335d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 May 2021 13:17:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 May 2021 13:17:39 -0700    

The all_visible_according_to_vm variable's value is inherently prone to  
becoming invalidated concurrently, since it is set before we even  
acquire a lock on a related heap page buffer.  
  
Oversight in commit 7136bf34, which added the assertion in passing.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reported-By: Tang <tanghy.fnst@fujitsu.com>  
Diagnosed-By:: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoDzgc8_MYrA5m1fyydomw_eVKtQiYh7sfDK4KEhdMsf_g@mail.gmail.com  

commit   : 3fe773b149755977d2ffde2afd89557b39d0afd9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 12:47:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 12:47:30 -0400    

In d6b8d29419df I (Álvaro) was sloppy about recording whether a  
partition descripor does or does not include detached partitions, when  
the snapshot checking does not see the pg_inherits row marked detached.  
In that case no partition was omitted, yet in the relcache entry we were  
saving the partdesc as omitting partitions.  Flip that (so we save it as  
a partdesc not omitting partitions, which indeed it doesn't), which  
hopefully makes the code easier to reason about.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/CA+HiwqE7GxGU4VdzwZzfiz+Ont5SsopoFkgtrZGEdPqWRL+biA@mail.gmail.com  

commit   : c38cadc0907a8d071b043b2b32b83efa09db38ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 May 2021 09:59:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 May 2021 09:59:11 -0400    

Improve self-referential foreign key example, per suggestion  
from David Johnston.  
  
Discussion: https://postgr.es/m/CAKFQuwZTke7+HUn4YUGqu2+gAPi4Cy18TXMrg_Z5nADkxfPNMw@mail.gmail.com  

commit   : 448b02c00515ba9d6683a8a97fe4305604d80028    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 May 2021 08:27:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 May 2021 08:27:20 -0400    

The grammar changes in commit bbe0a81db69bd10bd166907c3701492a29aca294  
allow SET COMPRESSION to be used with ALTER MATERIALIZED VIEW as  
well as with ALTER TABLE, so update those docs to say that it works.  
  
Also, update the documentation for the pg_column_compression()  
to explain that it will return NULL when there's no relevant value.  
  
Patch by me, per concerns from Michael Paquier.  
  
Discussion: http://postgr.es/m/CA+Tgmob9h5u4iNL9KM0drZgkY-JL4oCVW0dWrMqtLPQ1zHkquA@mail.gmail.com  

commit   : 2d0f662402635d591cac9f1daae5e81e7c4374fc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 May 2021 08:22:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 May 2021 08:22:45 -0400    

Justin Pryzby, per a complaint from Michael Paquier. Reviewed by  
Dilip Kumar and by me.  
  
Discussion: http://postgr.es/m/20210429040132.GF27406@telsasoft.com  

commit   : 592f00f8dec68038301467a904ac514eddabf6cd    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 May 2021 11:21:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 May 2021 11:21:26 +0530    

Currently, replication slot statistics are updated at prepare, commit, and  
rollback. Now, if the transaction is interrupted the stats might not get  
updated. Fixed this by updating replication statistics after every  
stream/spill.  
  
In passing update the docs to change the description of some of the slot  
stats.  
  
Author: Vignesh C, Sawada Masahiko  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : 7f2e10baa2482494dbcf70e0ae6f0469771e0b4c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 5 May 2021 22:07:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 5 May 2021 22:07:40 -0700    

Reported-By: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/833107370.1313189.1619647621213@webmailclassic.xs4all.nl  
Backpatch: 13, where b059d2f45685 introduced the issue.  

commit   : e8ce68b0b9ae2757c6153a88bf869904d2d5ac0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 May 2021 23:10:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 May 2021 23:10:33 -0400    

Update checklist to reflect current practice:  
  
* The platform-specific FAQ files are long gone.  
  
* We've never routinely updated the libbind code we borrowed, either,  
and there seems no reason to start now.  
  
* Explain current practice of running pgindent twice per cycle.  
  
Discussion: https://postgr.es/m/4038398.1620238684@sss.pgh.pa.us  

commit   : 2ce353fc19024d62e59ad99850d7592ebc9abecf    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 May 2021 08:26:42 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 May 2021 08:26:42 +0530    

During decoding of an in-progress or prepared transaction, we detect  
concurrent abort with an error code ERRCODE_TRANSACTION_ROLLBACK. That is  
not sufficient because a callback can decide to throw that error code  
at other times as well.  
  
Reported-by: Tom Lane  
Author: Amit Kapila  
Reviewed-by: Dilip Kumar  
Discussion: https://postgr.es/m/CAA4eK1KCjPRS4aZHB48QMM4J8XOC1+TD8jo-4Yu84E+MjwqVhA@mail.gmail.com  

commit   : c250062df42ffd3e252471f6205bfb6cbef67b7b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 May 2021 12:27:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 May 2021 12:27:39 -0400    

Commit 0325d7a5957b made this unused but forgot to remove it. Do so now.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/209c99fe-b9a2-94f4-cd68-a8304186a09e@lab.ntt.co.jp  

commit   : 6f70d7ca1d1937a9f7b79eff6fb18ed1bb2a4c47    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 May 2021 12:14:21 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 May 2021 12:14:21 -0400    

When ALTER TABLE .. ALTER CONSTRAINT changes deferrability properties  
changed in a partitioned table, we failed to propagate those changes  
correctly to partitions and to triggers.  Repair by adding a recursion  
mechanism to affect all derived constraints and all derived triggers.  
(In particular, recurse to partitions even if their respective parents  
are already in the desired state: it is possible for the partitions to  
have been altered individually.)  Because foreign keys involve tables in  
two sides, we cannot use the standard ALTER TABLE recursion mechanism,  
so we invent our own by following pg_constraint.conparentid down.  
  
When ALTER TABLE .. ALTER CONSTRAINT is invoked on the derived  
pg_constraint object that's automaticaly created in a partition as a  
result of a constraint added to its parent, raise an error instead of  
pretending to work and then failing to modify all the affected triggers.  
Before this commit such a command would be allowed but failed to affect  
all triggers, so it would silently misbehave.  (Restoring dumps of  
existing databases is not affected, because pg_dump does not produce  
anything for such a derived constraint anyway.)  
  
Add some tests for the case.  
  
Backpatch to 11, where foreign key support was added to partitioned  
tables by commit 3de241dba86f.  (A related change is commit f56f8f8da6af  
in pg12 which added support for FKs *referencing* partitioned tables;  
this is what forces us to use an ad-hoc recursion mechanism for this.)  
  
Diagnosed by Tom Lane from bug report from Ron L Johnson.  As of this  
writing, no reviews were offered.  
  
Discussion: https://postgr.es/m/75fe0761-a291-86a9-c8d8-4906da077469@gmail.com  
Discussion: https://postgr.es/m/3144850.1607369633@sss.pgh.pa.us  

commit   : f33a178a34809a2bae7a5f4c00984d87771f4204    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 May 2021 11:26:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 May 2021 11:26:48 -0400    

Previously, a lot of information about type regclass existed only  
in the discussion of the sequence functions.  Maybe that made sense  
in the beginning, because I think originally those were the only  
functions taking regclass.  But it doesn't make sense anymore.  
Move that material to the "Object Identifier Types" section in  
datatype.sgml, generalize it to talk about the other reg* types  
as well, and add more examples.  
  
Per bug #16991 from Federico Caselli.  
  
Discussion: https://postgr.es/m/16991-bcaeaafa17e0a723@postgresql.org  

commit   : 38f36aad8c55c8f91e3fb8720fae1847c8fa0552    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 May 2021 08:18:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 May 2021 08:18:22 +0200    

commit   : 1273a15bf91fa322915e32d3b6dc6ec916397268    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 May 2021 13:36:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 May 2021 13:36:26 -0400    

Commit 93f414614 improved a pre-existing test case so that it would  
show whether or not termination of the "remote" worker process happened.  
This soon exposed that, when debug_invalidate_system_caches_always  
(nee CLOBBER_CACHE_ALWAYS) is enabled, no such termination occurs.  
That's because cache invalidation forces postgres_fdw connections  
to be dropped at end of transaction, so that there's no worker to  
terminate.  There's a race condition as to whether the worker will  
manage to get out of the BackendStatusArray before we look, but at  
least on buildfarm member hyrax, it's failed twice in two attempts.  
  
Rather than re-lobotomizing the test, let's fix this by transiently  
disabling debug_invalidate_system_caches_always.  (Hooray for that  
being just a GUC nowadays, rather than a compile-time option.)  
If this proves not to be enough to make the test stable, we can  
do the other thing instead.  
  
Discussion: https://postgr.es/m/3854538.1620081771@sss.pgh.pa.us  

commit   : e798d095da3a4a4bb5c50bb3dff886f07ef52f55    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 May 2021 10:09:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 May 2021 10:09:12 -0400    

The OID of the constraint is used instead of the OID of the trigger --  
an easy mistake to make.  Apparently the object-alter hooks are not very  
well tested :-(  
  
Backpatch to 12, where this typo was introduced by 578b229718e8  
  
Discussion: https://postgr.es/m/20210503231633.GA6994@alvherre.pgsql  

commit   : c98a6d7887ea6588b4e9797903182312a2b46f67    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 15:45:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 15:45:13 +0200    

commit   : feb270d1005f3d7b3705dec9e04c9a205750ea97    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 14:03:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 14:03:54 +0200    

The previous fix for dumping of inherited generated columns  
(0bf83648a52df96f7c8677edbbdf141bfa0cf32b) must not be applied to  
partitions, since, unlike normal inherited tables, they are always  
dumped separately and reattached.  
  
Reported-by: Santosh Udupi <email@hitha.net>  
Discussion: https://www.postgresql.org/message-id/flat/CACLRvHZ4a-%2BSM_159%2BtcrHdEqxFrG%3DW4gwTRnwf7Oj0UNj5R2A%40mail.gmail.com  

commit   : a970edbed306354b0079bdcdc2fc74312122ad89    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 11:45:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 11:45:37 +0200    

When running ALTER TABLE t2 INHERIT t1, we must check that columns in  
t2 that correspond to a generated column in t1 are also generated and  
have the same generation expression.  Otherwise, this would allow  
creating setups that a normal CREATE TABLE sequence would not allow.  
  
Discussion: https://www.postgresql.org/message-id/22de27f6-7096-8d96-4619-7b882932ca25@2ndquadrant.com  

commit   : ae9492a61bbf575e2862cf9323c7f02806382093    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 4 May 2021 03:56:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 4 May 2021 03:56:16 +0300    

We don't usually mention the version number in similar situations.  So, neither  
mention it here.  
  
Reported-by: Bruce Momjian  
Discussion: https://postgr.es/m/20210503234914.GO6180%40momjian.us  

commit   : f7a97b6ec31f3f57a6154d0039c4de81ad517064    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 May 2021 14:59:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 May 2021 14:59:30 -0400    

Properly fix:  
  
- the "ONLY" in FROM [ONLY] isn't hashed  
- the agglevelsup field in GROUPING isn't hashed  
- WITH TIES not being hashed (new in PG 13)  
- "DISTINCT" in "GROUP BY [DISTINCT]" isn't hashed (new in PG 14)  
  
Reported-by: Julien Rouhaud  
  
Discussion: https://postgr.es/m/20210425081119.ulyzxqz23ueh3wuj@nol  

commit   : 5df6aeab42279eaea8e9ff92744645b155c85b03    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 20:14:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 20:14:03 +0200    

Before now, looking up "multirange" in the index only led to the  
multirange() function.  To make this more useful, also add an entry  
pointing to the range types section.  

commit   : 50529e5b4e39ad80a637ba0905277f9691eb4a15    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 3 May 2021 12:32:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 3 May 2021 12:32:05 -0400    

Don't phrase reports in terms of the number of tuples thus-far  
returned by the index scan, but rather in terms of the chunk_seq  
values found inside the tuples.  
  
Patch by me, reviewed by Mark Dilger.  
  
Discussion: http://postgr.es/m/CA+TgmoZUONCkdcdR778EKuE+f1r5Obieu63db2OgMPHaEvEPTQ@mail.gmail.com  

commit   : f68970e33f4dc48094c24c78c452ad730ae9ae12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 May 2021 11:42:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 May 2021 11:42:31 -0400    

Commit 824bf7190 introduced a new search of the NFAs generated by  
regex compilation.  I failed to think hard about the performance  
characteristics of that search, with the predictable outcome  
that it's bad: weird regexes can trigger exponential search time.  
Worse, there's no check-for-interrupt in that code, so you can't  
even cancel the query if this happens.  
  
Fix by introducing memo-ization of the search results, so that any one  
NFA state need be examined in detail just once.  This potentially uses  
a lot of memory, but we can bound the memory usage by putting a limit  
on the number of states for which we'll try to prove match-all-ness.  
That is sane because we already have a limit (DUPINF) on the maximum  
finite string length that a matchall regex can match; and patterns  
that involve much more than DUPINF states would probably exceed that  
limit anyway.  
  
Also, rearrange the logic so that we check the basic is-the-graph-  
all-RAINBOW-arcs property before we start the recursive search to  
determine path lengths.  This will ensure that we fall out quickly  
whenever the NFA couldn't possibly be matchall.  
  
Also stick in a check-for-interrupt, just in case these measures  
don't completely eliminate the risk of slowness.  
  
Discussion: https://postgr.es/m/3483895.1619898362@sss.pgh.pa.us  

commit   : b94409a02f6122d77b5154e481c0819fed6b4c95    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 12:11:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 12:11:33 +0200    

If dtrace is compiled in but disabled, the lwlock dtrace probes still  
evaluate their arguments.  Since PostgreSQL 13, T_NAME(lock) does  
nontrivial work, so it should be avoided if not needed.  To fix, make  
these calls conditional on the *_ENABLED() macro corresponding to each  
probe.  
  
Reviewed-by: Craig Ringer <craig.ringer@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/CAGRY4nwxKUS_RvXFW-ugrZBYxPFFM5kjwKT5O+0+Stuga5b4+Q@mail.gmail.com  

commit   : c285babf8f44d86b7fd1e73e9e4f94456b825bfb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 09:05:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 09:05:58 +0200    

became unused by 04942bffd0aa9bd0d143d99b473342eb9ecee88b  

commit   : ced12b73a9bc76b887cb7137df3d56222e2b5263    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 08:51:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 08:51:30 +0200    

commit   : 853c8c75571558f4b474eeac3ef9e6fcf9be62ba    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 07:27:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 07:27:31 +0200    

One more that ought to have been part of  
82c3cd974131d7fa1cfcd07cebfb04fffe26ee35.  

commit   : 205f466282be11ec97506f73341e47b72e0aee5d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 3 May 2021 07:22:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 3 May 2021 07:22:08 +0530    

Previously, we were using the size of all the changes present in  
ReorderBuffer to compute total_bytes after decoding a transaction and that  
can lead to counting some of the transactions' changes more than once. Fix  
it by using the size of the changes decoded for a transaction to compute  
'total_bytes'.  
  
Author: Sawada Masahiko  
Reviewed-by: Vignesh C, Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : eb086056fec44516efdd5db71244a079fed65c7f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 3 May 2021 03:58:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 3 May 2021 03:58:03 +0300    

websearch_to_tsquery() splits text in quotes into tokens and connects them with  
phrase operator on its own.  However, that leads to surprising results when the  
token contains no words.  
  
For instance, websearch_to_tsquery('"aaa: bbb"') is 'aaa <2> bbb', because  
it is equivalent of to_tsquery(E'aaa <-> \':\' <-> bbb').  But  
websearch_to_tsquery('"aaa: bbb"') has to be 'aaa <-> bbb' in order to match  
to_tsvector('aaa: bbb').  
  
Since 0c4f355c6a, we anyway connect lexemes of complex tokens with phrase  
operators.  Thus, let's just websearch_to_tsquery() parse text in quotes as  
a single token.  Therefore, websearch_to_tsquery() should process the quoted  
text in the same way phraseto_tsquery() does.  This solution is what we exactly  
need and also simplifies the code.  
  
This commit is an incompatible change, so we don't backpatch it.  
  
Reported-by: Valentin Gatien-Baron  
Discussion: https://postgr.es/m/CA%2B0DEqiZs7gdOd4ikmg%3D0UWG%2BSwWOLxPsk_JW-sx9WNOyrb0KQ%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Tom Lane, Zhihong Yu  

commit   : 651d005e76bc0b9542615f609b4d0d946035dc58    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 1 May 2021 10:42:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 1 May 2021 10:42:44 -0400    

Turns out you can specify negative values using plurals:  
  
	https://english.stackexchange.com/questions/9735/is-1-followed-by-a-singular-or-plural-noun  
  
so the previous code was correct enough, and consistent with other usage  
in our code.  Also add comment in the two places where this could be  
confused.  
  
Reported-by: Noah Misch  
  
Diagnosed-by: 20210425115726.GA2353095@rfd.leadboat.com  

commit   : e6f9539dc32473793c03cbe95bc099ee0a199c73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:37:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:37:56 -0400    

While we've always allowed such cases, the documentation didn't  
say you could do it.  
  
Discussion: https://postgr.es/m/161969805833.690.13680986983883602407@wrigleys.postgresql.org  

commit   : 386e64ea5abf346d887c21ea8869317838ba19b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:10:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:10:06 -0400    

Mention specifically that you can't call aggregates, window functions,  
or procedures this way (the inability to call SRFs was already  
mentioned).  
  
Also, the claim that PQfn doesn't support NULL arguments or results  
has been a lie since we invented protocol 3.0.  Not sure why this  
text was never updated for that, but do it now.  
  
Discussion: https://postgr.es/m/2039442.1615317309@sss.pgh.pa.us  

commit   : 2efcd502e56a528f75ec8e88c02a287ad3457d77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 14:10:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 14:10:26 -0400    

Reject aggregates, window functions, and procedures.  Aggregates  
failed anyway, though with a somewhat obscure error message.  
Window functions would hit an Assert or null-pointer dereference.  
Procedures seemed to work as long as you didn't try to do  
transaction control, but (a) transaction control is sort of the  
point of a procedure, and (b) it's not entirely clear that no  
bugs lurk in that path.  Given the lack of testing of this area,  
it seems safest to be conservative in what we support.  
  
Also reject proretset functions, as the fastpath protocol can't  
support returning a set.  
  
Also remove an easily-triggered assertion that the given OID  
isn't 0; the subsequent lookups can handle that case themselves.  
  
Per report from Theodor-Arsenij Larionov-Trichkin.  
Back-patch to all supported branches.  (The procedure angle  
only applies in v11+, of course.)  
  
Discussion: https://postgr.es/m/2039442.1615317309@sss.pgh.pa.us  

commit   : ee4ba01dbbc31daa083f434ecd603a80bbe50501    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 30 Apr 2021 10:49:52 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 30 Apr 2021 10:49:52 +0530    

There were two problems:  
a. We were always selecting the next available txn instead of selecting it  
when it is larger than the previous transaction.  
b. We were selecting the transactions which haven't made any changes to  
the database (base snapshot is not set). Later it was hitting an Assert  
because we don't decode such transactions and the changes in txn remain as  
it is. It is better not to choose such transactions for streaming in the  
first place.  
  
Reported-by: Haiying Tang  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/OS0PR01MB61133B94E63177040F7ECDA1FB429@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : 3c80e96dffd4df7f66fffa5f265cbd87becb7ef5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 30 Apr 2021 14:46:42 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 30 Apr 2021 14:46:42 +1200    

Here we adjust the EXPLAIN ANALYZE output for Result Cache so that we  
don't show any Result Cache stats for parallel workers who don't  
contribute anything to Result Cache plan nodes.  
  
I originally had ideas that workers who don't help could still have their  
Result Cache stats displayed.  The idea with that was so that I could  
write some parallel Result Cache regression tests that show the EXPLAIN  
ANALYZE output.  However, I realized a little too late that such tests  
would just not be possible to have run in a stable way on the buildfarm.  
  
With that knowledge, before 9eacee2e6 went in, I had removed all of the  
tests that were showing the EXPLAIN ANALYZE output of a parallel Result  
Cache plan, however, I forgot to put back the code that adjusts the  
EXPLAIN output to hide the Result Cache stats for parallel workers who  
were not fast enough to help out before query execution was over. All  
other nodes behave this way and so should Result Cache.  
  
Additionally, with this change, it now seems safe enough to remove the SET  
force_parallel_mode = off that I had added to the regression tests.  
  
Also, perform some cleanup in the partition_prune tests. I had adjusted  
the explain_parallel_append() function to sanitize the Result Cache  
EXPLAIN ANALYZE output.  However, since I didn't actually include any  
parallel Result Cache tests that show their EXPLAIN ANALYZE output, that  
code does nothing and can be removed.  
  
In passing, move the setting of memPeakKb into the scope where it's used.  
  
Reported-by: Amit Khandekar  
Author: David Rowley, Amit Khandekar  
Discussion: https://postgr.es/m/CAJ3gD9d8SkfY95GpM1zmsOtX2-Ogx5q-WLsf8f0ykEb0hCRK3w@mail.gmail.com  

commit   : 51ef9173030cc196c6633ae82b7b32f404b0f768    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 30 Apr 2021 07:55:42 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 30 Apr 2021 07:55:42 +0530    

As per analysis, it appears that the 'drop slot' message from the previous  
test and 'create slot' message of the new test are either missed or not  
yet delivered to the stats collector due to which we will still see the  
stats from the old slot. This can happen rarely which could be the reason  
that we are seeing some failures in the buildfarm randomly. To avoid that  
we are using a different slot name for the tests in  
test_decoding/sql/stats.sql.  
  
Reported-by: Tom Lane based on buildfarm reports  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila, Vignesh C  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : c9c37ae03fea0c8ad467392ddf03940b61974935    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Apr 2021 15:40:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Apr 2021 15:40:34 -0400    

Don't advocate dropping a whole table when dropping a column would  
serve.  While at it, try to make the layout of these messages a  
bit cleaner and more consistent.  
  
Per suggestion from Daniel Gustafsson.  No back-patch, as we generally  
don't like to churn translatable messages in released branches.  
  
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us  

commit   : 57c081de0afcd01bf47c46f015bf8886b01c2c21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Apr 2021 15:24:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Apr 2021 15:24:37 -0400    

Commits 29aeda6e4 et al closed up some oversights involving not checking  
for non-upgradable types within container types, such as arrays and  
ranges.  However, I only looked at version.c, failing to notice that  
there were substantially-equivalent tests in check.c.  (The division  
of responsibility between those files is less than clear...)  
  
In addition, because genbki.pl does not guarantee that auto-generated  
rowtype OIDs will hold still across versions, we need to consider that  
the composite type associated with a system catalog or view is  
non-upgradable.  It seems unlikely that someone would have a user  
column declared that way, but if they did, trying to read it in another  
PG version would likely draw "no such pg_type OID" failures, thanks  
to the type OID embedded in composite Datums.  
  
To support the composite and reg*-type cases, extend the recursive  
query that does the search to allow any base query that returns  
a column of pg_type OIDs, rather than limiting it to exactly one  
starting type.  
  
As before, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us  

commit   : 94b9cb722552c37da78c8320bac1d5b55e34def6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Apr 2021 11:31:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Apr 2021 11:31:24 -0400    

Backpatch to 12, where 87259588d0ab introduced the current behavior.  
  
Per note from Justin Pryzby.  
  
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20210416143135.GI3315@telsasoft.com  

commit   : d9a9f4b4b92ad39e3c4e6600dc61d5603ddd6e24    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Apr 2021 09:04:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Apr 2021 09:04:31 +0200    

This was broken by a silly mistake in  
e717a9a18b2e34c9c40e5259ad4d31cd7e420750.  
  
Reported-by: Jeff Janes <jeff.janes@gmail.com>  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://www.postgresql.org/message-id/CAMkU=1zKGWEJdBbYKw7Tn7cJmYR_UjgdcXTPDqJj=dNwCETBCQ@mail.gmail.com  

commit   : 3a948ea0a2ced719f26e725b030558f2e4ab1d8e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Apr 2021 06:51:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Apr 2021 06:51:42 +0200    

Improve the wording in the connection type section of  
pg_hba.conf.sample a bit.  After the hostgssenc part was added on, the  
whole thing became a bit wordy, and it's also a bit inaccurate for  
example in that the current wording for "host" appears to say that it  
does not apply to GSS-encrypted connections.  
  
Discussion: https://www.postgresql.org/message-id/flat/fc06dcc5-513f-e944-cd07-ba51dd7c6916%40enterprisedb.com  

commit   : 2977f244bc7e64e046364122be3fef08aa6efef9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Apr 2021 11:44:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Apr 2021 11:44:24 +0900    

If no standbys can be found in the set of connection points provided,  
the fallback behavior is "any", and not "all" that does not exist.  
  
Author: Greg Nancarrow  
Reviewed-by: Laurenz Albe  
Discussion: https://postgr.es/m/CAJcOf-fDaCv8qCpWH7k5Yh6zFxZeUwZowu4sCWQ2zFx4CdkHpA@mail.gmail.com  

commit   : 9626325da5e8e23ff90091bc96535495d350f06e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Apr 2021 15:50:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Apr 2021 15:50:42 -0400    

We had a report of confusing server behavior caused by a client bug  
that sent junk to the server: the server thought the junk was a  
very long message length and waited patiently for data that would  
never come.  We can reduce the risk of that by being less trusting  
about message lengths.  
  
For a long time, libpq has had a heuristic rule that it wouldn't  
believe large message size words, except for a small number of  
message types that are expected to be (potentially) long.  This  
provides some defense against loss of message-boundary sync and  
other corrupted-data cases.  The server does something similar,  
except that up to now it only limited the lengths of messages  
received during the connection authentication phase.  Let's  
do the same as in libpq and put restrictions on the allowed  
length of all messages, while distinguishing between message  
types that are expected to be long and those that aren't.  
  
I used a limit of 10000 bytes for non-long messages.  (libpq's  
corresponding limit is 30000 bytes, but given the asymmetry of  
the FE/BE protocol, there's no good reason why the numbers should  
be the same.)  Experimentation suggests that this is at least a  
factor of 10, maybe a factor of 100, more than we really need;  
but plenty of daylight seems desirable to avoid false positives.  
In any case we can adjust the limit based on beta-test results.  
  
For long messages, set a limit of MaxAllocSize - 1, which is the  
most that we can absorb into the StringInfo buffer that the message  
is collected in.  This just serves to make sure that a bogus message  
size is reported as such, rather than as a confusing gripe about  
not being able to enlarge a string buffer.  
  
While at it, make sure that non-mainline code paths (such as  
COPY FROM STDIN) are as paranoid as SocketBackend is, and validate  
the message type code before believing the message length.  
This provides an additional guard against getting stuck on corrupted  
input.  
  
Discussion: https://postgr.es/m/2003757.1619373089@sss.pgh.pa.us  

commit   : d6b8d29419df0efad57f95c80b871745d1b55da6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Apr 2021 15:44:35 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Apr 2021 15:44:35 -0400    

Makes partition descriptor acquisition faster during the transient  
period in which a partition is in the process of being detached.  
  
This also adds the restriction that only one partition can be in  
pending-detach state for a partitioned table.  
  
While at it, return find_inheritance_children() API to what it was  
before 71f4c8c6f74b, and create a separate  
find_inheritance_children_extended() that returns detailed info about  
detached partitions.  
  
(This incidentally fixes a bug in 8aba9322511 whereby a memory context  
holding a transient partdesc is reparented to a NULL PortalContext,  
leading to permanent leak of that memory.  The fix is to no longer rely  
on reparenting contexts to PortalContext.   Reported by Amit Langote.)  
  
Per gripe from Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqFgpP1LxJZOBYGt9rpvTjXXkg5qG2+Xch2Z1Q7KrqZR1A@mail.gmail.com  

commit   : c93f8f3b8d3bc780892e2bf11192fbdd136fddfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Apr 2021 10:03:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Apr 2021 10:03:28 -0400    

Somehow I'd convinced myself that rotating to UTC-12 was the way  
to do this, but upon further review, it's definitely UTC+12.  
  
Discussion: https://postgr.es/m/1197050.1619123213@sss.pgh.pa.us  

commit   : f93f0b5b25068807051edb2f3510614b69bb79ff    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:58:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:58:08 +0900    

Spotted by buildfarm member prion, with -DRELCACHE_FORCE_RELEASE.  
  
Introduced in f7aab36.  
  
Discussion: https://postgr.es/m/2759018.1619577848@sss.pgh.pa.us  
Backpatch-through: 9.6  

commit   : f7aab36d61fd2fdbd949d5880247e8cae9ee4be0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:17:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:17:58 +0900    

Attempting to use this function with event triggers failed, as, since  
its introduction in a676201, this code has never associated an object  
name with event triggers.  This addresses the failure by adding the  
event trigger name to the set defining its object address.  
  
Note that regression tests are added within event_trigger and not  
object_address to avoid issues with concurrent connections in parallel  
schedules.  
  
Author: Joel Jacobson  
Discussion: https://postgr.es/m/3c905e77-a026-46ae-8835-c3f6cd1d24c8@www.fastmail.com  
Backpatch-through: 9.6  

commit   : fa26eba221a9e837493df47d0255ce615129e9a8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 27 Apr 2021 08:21:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 27 Apr 2021 08:21:15 -0400    

Handle the situation where perl swaps the order of operands of  
the comparison operator. See `perldoc overload` for details:  
  
The third argument is set to TRUE if (and only if) the two  
operands have been swapped. Perl may do this to ensure that the  
first argument ($self) is an object implementing the overloaded  
operation, in line with general object calling conventions.  

commit   : 0c8f40863acb94963df9fd6a4369eb71efe9a93b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 27 Apr 2021 18:39:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 27 Apr 2021 18:39:30 +0900    

Typos, corrections and language improvements in the docs.  
  
Author: Justin Pryzby, Fujii Masao  
Reviewed-by: Bharath Rupireddy, Justin Pryzby, Fujii Masao  
Discussion: https://postgr.es/m/20210411041658.GB14564@telsasoft.com  

commit   : 8e9ea08bae93a754d5075b7bc9c0b2bc71958bfd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 27 Apr 2021 14:41:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 27 Apr 2021 14:41:27 +0900    

Commit 8ff1c94649 allowed TRUNCATE command to truncate foreign tables.  
Previously the information about "ONLY" options specified in TRUNCATE  
command were passed to the foreign data wrapper. Then postgres_fdw  
constructed the TRUNCATE command to issue the remote server and  
included "ONLY" options in it based on the passed information.  
  
On the other hand, "ONLY" options specified in SELECT, UPDATE or DELETE  
have no effect when accessing or modifying the remote table, i.e.,  
are not passed to the foreign data wrapper. So it's inconsistent to  
make only TRUNCATE command pass the "ONLY" options to the foreign data  
wrapper. Therefore this commit changes the TRUNCATE command so that  
it doesn't pass the "ONLY" options to the foreign data wrapper,  
for the consistency with other statements. Also this commit changes  
postgres_fdw so that it always doesn't include "ONLY" options in  
the TRUNCATE command that it constructs.  
  
Author: Fujii Masao  
Reviewed-by: Bharath Rupireddy, Kyotaro Horiguchi, Justin Pryzby, Zhihong Yu  
Discussion: https://postgr.es/m/551ed8c1-f531-818b-664a-2cecdab99cd8@oss.nttdata.com  

commit   : 3fa17d37716f978f80dfcdab4e7c73f3a24e7a48    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Apr 2021 09:09:11 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Apr 2021 09:09:11 +0530    

Previously, we used to use the array of size max_replication_slots to  
store stats for replication slots. But that had two problems in the cases  
where a message for dropping a slot gets lost: 1) the stats for the new  
slot are not recorded if the array is full and 2) writing beyond the end  
of the array if the user reduces the max_replication_slots.  
  
This commit uses HTAB for replication slot statistics, resolving both  
problems. Now, pgstat_vacuum_stat() search for all the dead replication  
slots in stats hashtable and tell the collector to remove them. To avoid  
showing the stats for the already-dropped slots, pg_stat_replication_slots  
view searches slot stats by the slot name taken from pg_replication_slots.  
  
Also, we send a message for creating a slot at slot creation, initializing  
the stats. This reduces the possibility that the stats are accumulated  
into the old slot stats when a message for dropping a slot gets lost.  
  
Reported-by: Andres Freund  
Author: Sawada Masahiko, test case by Vignesh C  
Reviewed-by: Amit Kapila, Vignesh C, Dilip Kumar  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : e7eea52b2d61917fbbdac7f3f895e4ef636e935b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Apr 2021 08:28:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Apr 2021 08:28:26 +0530    

The Truncate operation acquires an exclusive lock on the target relation  
and indexes. It then waits for logical replication of the operation to  
finish at commit. Now because we are acquiring the shared lock on the  
target index to get index attributes in pgoutput while sending the  
changes for the Truncate operation, it leads to a deadlock.  
  
Actually, we don't need to acquire a lock on the target index as we build  
the cache entry using a historic snapshot and all the later changes are  
absorbed while decoding WAL. So, we wrote a special purpose function for  
logical replication to get a bitmap of replica identity attribute numbers  
where we get that information without locking the target index.  
  
We decided not to backpatch this as there doesn't seem to be any field  
complaint about this issue since it was introduced in commit 5dfd1e5a in  
v11.  
  
Reported-by: Haiying Tang  
Author: Takamichi Osumi, test case by Li Japin  
Reviewed-by: Amit Kapila, Ajin Cherian  
Discussion: https://postgr.es/m/OS0PR01MB6113C2499C7DC70EE55ADB82FB759@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : 6dd1042eda0acdabaab352c19b783288de62b587    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Apr 2021 16:37:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Apr 2021 16:37:46 -0400    

New keywords per 71f4c8c6f74b.  
  
Discussion: https://postgr.es/m/20210422204035.GA25929@alvherre.pgsql  

commit   : 04942bffd0aa9bd0d143d99b473342eb9ecee88b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Apr 2021 13:58:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Apr 2021 13:58:00 -0400    

Commit 2ec993a7c, which added triggers on views, modified the rewriter  
to add dummy entries like "SET x = x" for all columns that weren't  
actually being updated by the user in any UPDATE directed at a view.  
That was needed at the time to produce a complete "NEW" row to pass  
to the trigger.  Later it was found to cause problems for ordinary  
updatable views, so commit cab5dc5da restricted it to happen only for  
trigger-updatable views.  But in the wake of commit 86dc90056, we  
really don't need it at all.  nodeModifyTable.c populates the trigger  
"OLD" row from the whole-row variable that is generated for the view,  
and then it computes the "NEW" row using that old row and the UPDATE  
targetlist.  So there is no need for the UPDATE tlist to have dummy  
entries, any more than it needs them for regular tables or other  
types of views.  
  
(The comments for rewriteTargetListIU suggest that we must do this  
for correct expansion of NEW references in rules, but I now think  
that that was just lazy comment editing in 2ec993a7c.  If we didn't  
need it for rules on views before there were triggers, we don't need  
it after that.)  
  
This essentially propagates 86dc90056's decision that we don't need  
dummy column updates into the view case.  Aside from making the  
different cases more uniform and hence possibly forestalling future  
bugs, it ought to save a little bit of rewriter/planner effort.  
  
Discussion: https://postgr.es/m/2181213.1619397634@sss.pgh.pa.us  

commit   : 79a5928ebcb726b7061bf265b5c6990e835e8c4f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Apr 2021 11:50:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Apr 2021 11:50:35 -0400    

For some reason, the "julian" option for extract()/date_part() has  
never gotten listed in the manual.  Also, while Appendix B mentioned  
in passing that we don't conform to the usual astronomical definition  
that a Julian date starts at noon UTC, it was kind of vague about what  
we do instead.  Clarify that, and add an example showing how to get  
the astronomical definition if you want it.  
  
It's been like this for ages, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1197050.1619123213@sss.pgh.pa.us  

commit   : 38c9a5938ac5e1409b42677fee970a12632852ee    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Apr 2021 12:10:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Apr 2021 12:10:46 +0200    

The verification of permissions doesn't succeed on Cygwin, because the  
required feature is not implemented for Cygwin at the moment.  So skip  
this part of the test, like MinGW already does.  

commit   : 2ecfeda3e916f2a1123f818018d9d35908a499ac    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Apr 2021 15:22:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Apr 2021 15:22:48 +0900    

The tuple routing logic used by a logical replication worker can fire  
triggers on relations part of a partition tree, but there was no test  
coverage in this area.  The existing script 003_constraints.pl included  
something, but nothing when a tuple is applied across partitioned tables  
on a subscriber.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/OS0PR01MB611383FA0FE92EB9DE21946AFB769@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : f25a4584c6f56f3407f8f8734c78f2a87e4b77e8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Apr 2021 11:27:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Apr 2021 11:27:44 +0530    

We send the prepare for the concurrently aborted xacts so that later when  
rollback prepared is decoded and sent, the downstream should be able to  
rollback such a xact. For 'streaming' case (when we send changes for  
in-progress transactions), we were sending prepare twice when concurrent  
abort was detected.  
  
Author: Peter Smith  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/f82133c6-6055-b400-7922-97dae9f2b50b@enterprisedb.com  

commit   : 3cbea581c76e86d51b8f2babf116e643847e7712    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Apr 2021 07:05:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Apr 2021 07:05:21 +0200    

This was already unused in the initial commit  
257836a75585934cc05ed7a80bccf8190d41e056.  Apparently, it was used in  
an earlier proposed patch version.  

commit   : 6d2e87a077b3c2394e4adb8eb226b3dcfe3f3346    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Apr 2021 08:42:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Apr 2021 08:42:46 +0530    

Author: Peter Smith  
Discussion: https://postgr.es/m/CAHut+PtvzuYY0zu=dVRK_WVz5WGos1+otZWgEWqjha1ncoSRag@mail.gmail.com  

commit   : 08a986966524e522914b96e4398a4bebf942b298    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Apr 2021 18:02:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Apr 2021 18:02:03 -0400    

This function's behavior for UPDATE on a trigger-updatable view was  
justified by analogy to what preptlist.c used to do for UPDATE on  
regular tables.  Since preptlist.c hasn't done that since 86dc90056,  
that argument is no longer sensible, let alone convincing.  I think  
we do still need it to act that way, so update the comment to explain  
why.  

commit   : 59773da2b132ced19c84ff1f69b53b5cf95fd69e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 25 Apr 2021 01:08:05 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 25 Apr 2021 01:08:05 -0700    

commit   : b859d94c638968ccbb517ac7e151bdd94ed7c16a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 24 Apr 2021 10:13:07 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 24 Apr 2021 10:13:07 -0400    

This will install amcheck in the database if not present. The default  
schema is for the extension is pg_catalog, but this can be overridden by  
providing a value for the option.  
  
Mark Dilger, slightly editorialized by me.  
  
(rather divergent)  
Discussion: https://postgr.es/m/bdc0f7c2-09e3-ee57-8471-569dfb509234@dunslane.net  

commit   : aa271209f6d995488fc5cba9731415f974823990    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 24 Apr 2021 09:37:20 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 24 Apr 2021 09:37:20 -0400    

As well as 'devel' version_stamp.pl provides for 'alphaN'  
'betaN' and 'rcN', so teach PostgresVersion about those.  
  
Also stash the version string instead of trying to reconstruct it during  
stringification.  
  
Discussion: https://postgr.es/m/YIHlw5nSgAHs4dK1@paquier.xyz  

commit   : 9b5558e7ad4706bbd53947e5b4d7c06e150390a5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Apr 2021 15:07:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Apr 2021 15:07:04 +0900    

1375422 has refactored this area of the executor code, and some comments  
went out-of-sync.  
  
Author: Yukun Wang  
Reviewed-by: Amul Sul  
Discussion: https://postgr.es/m/OS0PR01MB60033394FCAEF79B98F078F5B4459@OS0PR01MB6003.jpnprd01.prod.outlook.com  

commit   : 0d0049c58b4970183a102fc1f7dc1e9bef2a7149    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Apr 2021 10:44:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Apr 2021 10:44:13 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210423184338.GL7256@telsasoft.com  

commit   : 4aba61b87026b43fb37fc8e9ec5d9ae208e07b6b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Apr 2021 09:09:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Apr 2021 09:09:02 +0900    

6f6f284 has introduced a specific macro to make printf()-ing of LSNs  
easier.  This takes care of what looks like the remaining code paths  
that did not get the call.  
  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi, Tom Lane  
Discussion: https://postgr.es/m/YIJS9x6K8ruizN7j@paquier.xyz  

commit   : bb3ecc8c961896ecb2ad3d5ba705c2877b933945    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 23 Apr 2021 15:37:03 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 23 Apr 2021 15:37:03 -0700    

This isn't strictly necessary, but in theory it might matter if in the  
future the width of the nbtree special area changes -- its total size  
might not be an even number of MAXALIGN() quantums, even with padding.  
PageInit() MAXALIGN()s all special area offsets, but amcheck uses the  
offset to perform initial basic validation of line pointers, so we don't  
rely on the offset from the page header.  
  
The real reason to do this is to set a good example for new code that  
adds amcheck coverage for other index AMs.  
  
Reported-By: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://postgr.es/m/CALj2ACUMqTR9nErh99FbOBmzCXE9=gXNqhBiwYOhejJJS1LXqQ@mail.gmail.com  

commit   : 82c3cd974131d7fa1cfcd07cebfb04fffe26ee35    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 14:18:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 14:18:11 +0200    

Instead, put them in via a format placeholder.  This reduces the  
number of distinct translatable messages and also reduces the chances  
of typos during translation.  We already did this for the system call  
arguments in a number of cases, so this is just the same thing taken a  
bit further.  
  
Discussion: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com  

commit   : 9486844f301e265a3ad11b612decaba2462c3c15    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 13:27:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 13:27:01 +0200    

Some code thought this was unsigned, but it's signed int.  

commit   : 6bbcff096f932a1fe43ac3208c5c8b0acac29cda    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 23 Apr 2021 12:57:33 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 23 Apr 2021 12:57:33 +0300    

These functions shouldn't receive null arguments: multirange_constructor0()  
doesn't have any arguments while multirange_constructor2() has a single array  
argument, which is never null.  
  
But mark them strict anyway for the sake of uniformity.  
  
Also, make checks for null arguments use elog() instead of ereport() as these  
errors should normally be never thrown.  And adjust corresponding comments.  
  
Catversion is bumped.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/0f783a96-8d67-9e71-996b-f34a7352eeef%40enterprisedb.com  

commit   : 3f20d5f37086e548c32ddb9d6ae09c2e1ce300ce    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 23 Apr 2021 19:10:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 23 Apr 2021 19:10:24 +0900    

Commit bbe0a81db6 introduced "INCLUDING COMPRESSION" option  
in CREATE TABLE command, but previously TableLikeOption in gram.y and  
parsenodes.h didn't classify this new option in alphabetical order  
with the rest.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/YHerAixOhfR1ryXa@paquier.xyz  

commit   : 7531fcb1fcf5b3ea2f49959a3f095c083e3fc4c4    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 23 Apr 2021 11:41:36 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 23 Apr 2021 11:41:36 +0200    

While at it, also document that toplevel is always true if  
pg_stat_statements.track is set to top.  
  
Author: Julien Rouhaud  
Reported-By: Fujii Masao  
Discussion: https://postgr.es/m/a878d5ea-64a7-485e-5d2f-177618ebc52d@oss.nttdata.com  

commit   : add5fad78aac8da96aeeb730155d35b16ff9b55a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 09:55:23 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 09:55:23 +0200    

This was already mostly done, but some error messages were printed the  
long way.  

commit   : 9bd563aa9f0694994a6640946a7ee3dc0431d507    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 09:28:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 09:28:44 +0200    

Author: Justin Pryzby <pryzby@telsasoft.com>  

commit   : eaec48b3c54eec222d64468b57af80ee4ddf76a9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 23 Apr 2021 15:45:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 23 Apr 2021 15:45:46 +0900    

Previously it was documented that if using "-X none" option there was  
no guarantee that all required WAL files were archived at the end of  
pg_basebackup when taking a backup from the standby. But this limitation  
was removed by commit 52f8a59dd9. Now, even when taking a backup  
from the standby, pg_basebackup can wait for all required WAL files  
to be archived. Therefore this commit removes such obsolete  
description from the docs.  
  
Also this commit adds new description about the limitation when  
taking a backup from the standby, into the docs. The limitation is that  
pg_basebackup cannot force the standbfy to switch to a new WAL file  
at the end of backup, which may cause pg_basebackup to wait a long  
time for the last required WAL file to be switched and archived,  
especially when write activity on the primary is low.  
  
Back-patch to v10 where the issue was introduced.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi, Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/20210420.133235.1342729068750553399.horikyota.ntt@gmail.com  

commit   : 7776a23a4bdeb7215e4f8ddea5989cb143becc12    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 07:21:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Apr 2021 07:21:13 +0200    

commit   : 45c0c5f70eb5e22d31be8bb9a8b4d9c66a3e9b37    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Apr 2021 13:34:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Apr 2021 13:34:02 +0900    

Oversight in 2a0faed.  
  
Author: Hou Zhijie  
Discussion: https://postgr.es/m/OS0PR01MB5716405E2464D85E6DB6DC0794469@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 62aa2bb293148c13851484e63db4835e3c53147f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Apr 2021 13:25:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Apr 2021 13:25:49 +0900    

%lld with (long long), or %llu with (unsigned long long) are more  
adapted.  This is similar to 3286065.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20210421.200000.1462448394029407895.horikyota.ntt@gmail.com  

commit   : bb684c82f73316b88f9bcb321128a4347b5206fe    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 23 Apr 2021 12:00:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 23 Apr 2021 12:00:00 +0900    

This is cleanup for commit 27e1f1456:  
  
* ExecAppendAsyncEventWait(), which was modified a bit further by commit  
  a8af856d3, duplicated the same nevents calculation.  Simplify the code  
  a little bit to avoid the duplication.  Update comments there.  
* Add an assertion to ExecAppendAsyncRequest().  
* Update a comment about merging the async_capable options from input  
  relations in merge_fdw_options(), per complaint from Kyotaro Horiguchi.  
* Add a comment for fetch_more_data_begin().  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK1637W30Wx3MnrReewhafn6F_0J76mrJGoFXFnpPq4QfvA%40mail.gmail.com  

commit   : d479d00285255d422a2b38f1cfaa35808968a08c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 17:30:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 17:30:42 -0400    

Adopt a more consistent policy about what slot-type-specific  
getsysattr functions should do when system attributes are not  
available.  To wit, they should all throw the same user-oriented  
error, rather than variously crashing or emitting developer-oriented  
messages.  
  
This closes a identifiable problem in commits a71cfc56b and  
3fb93103a (in v13 and v12), so back-patch into those branches,  
along with a test case to try to ensure we don't break it again.  
It is not known that any of the former crash cases are reachable  
in HEAD, but this seems like a good safety improvement in any case.  
  
Discussion: https://postgr.es/m/141051591267657@mail.yandex.ru  

commit   : 197d33ccbe888fc84ae4e49bb241e88ea3c81f15    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Apr 2021 22:47:57 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Apr 2021 22:47:57 +0200    

commit   : 43b55ec4bc3bc06596d966391f16defe016310ec    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Apr 2021 16:04:48 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Apr 2021 16:04:48 -0400    

Have interested callers of find_inheritance_children set the  
detached_exist value to false prior to calling it, so that that routine  
only has to set it true in the rare cases where it is necessary.  Don't  
touch it otherwise.  
  
Per buildfarm member thorntail (which reported a UBSan failure here).  

commit   : 84f15ccd4c25c4ffc4de6ed82f7658a3a199a1d7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 22 Apr 2021 16:01:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 22 Apr 2021 16:01:17 -0400    

This was discussed in commit 9081bddbd.  
  
Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/flat/87o8pco34z.fsf@wibble.ilmari.org  

commit   : 502dc6df8f6eeba06812ce09488efc7e684f5ec9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 22 Apr 2021 15:25:37 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 22 Apr 2021 15:25:37 -0400    

per gripe from Alvaro Herrera.  

commit   : 8aba9322511f718f12b618470d8c07f0ee5f0700    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Apr 2021 15:13:25 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Apr 2021 15:13:25 -0400    

During queries coming from ri_triggers.c, we need to omit partitions  
that are marked pending detach -- otherwise, the RI query is tricked  
into allowing a row into the referencing table whose corresponding row  
is in the detached partition.  Which is bogus: once the detach operation  
completes, the row becomes an orphan.  
  
However, the code was not doing that in repeatable-read transactions,  
because relcache kept a copy of the partition descriptor that included  
the partition, and used it in the RI query.  This commit changes the  
partdesc cache code to only keep descriptors that aren't dependent on  
a snapshot (namely: those where no detached partition exist, and those  
where detached partitions are included).  When a partdesc-without-  
detached-partitions is requested, we create one afresh each time; also,  
those partdescs are stored in PortalContext instead of  
CacheMemoryContext.  
  
find_inheritance_children gets a new output *detached_exist boolean,  
which indicates whether any partition marked pending-detach is found.  
Its "include_detached" input flag is changed to "omit_detached", because  
that name captures desired the semantics more naturally.  
CreatePartitionDirectory() and RelationGetPartitionDesc() arguments are  
identically renamed.  
  
This was noticed because a buildfarm member that runs with relcache  
clobbering, which would not keep the improperly cached partdesc, broke  
one test, which led us to realize that the expected output of that test  
was bogus.  This commit also corrects that expected output.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/3269784.1617215412@sss.pgh.pa.us  

commit   : 82b13dbc4d4b46f71ca95ce1cc15c425deff5957    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 14:47:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 14:47:26 -0400    

Back-patch to v13; the table layout in older branches is unfriendly  
to adding such details.  
  
Laurenz Albe  
  
Discussion: https://postgr.es/m/161881920775.685.12293798764864559341@wrigleys.postgresql.org  

commit   : 4c4eaf3d19201c5e2d9efebc590903dfaba0d3e5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 22 Apr 2021 10:56:28 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 22 Apr 2021 10:56:28 -0400    

A new PostgresVersion object type is created and this is used in  
PostgresNode using the output of `pg_config --version` and the result  
stored in the PostgresNode object.  This object can be compared to other  
PostgresVersion objects, or to a number or string.  
  
PostgresNode is currently believed to be compatible with versions down  
to release 12, so PostgresNode will issue a warning if used with a  
version prior to that.  
  
No attempt has been made to deal with incompatibilities in older  
versions - that remains work to be undertaken in a subsequent  
development cycle.  
  
Based on code from Mark Dilger and Jehan-Guillaume de Rorthais.  
  
Discussion: https://postgr.es/m/a80421c0-3d7e-def1-bcfe-24777f15e344@dunslane.net  

commit   : f3b141c482552a57866c72919007d6481cd59ee3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Apr 2021 12:48:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Apr 2021 12:48:54 +0900    

Creating a trigger on a relation to which an apply operation is  
triggered would cause a relation leak once the change gets committed,  
as the executor would miss that the relation needs to be closed  
beforehand.  This issue got introduced with the refactoring done in  
1375422c, where it becomes necessary to track relations within  
es_opened_result_relations to make sure that they are closed.  
  
We have discussed using ExecInitResultRelation() coupled with  
ExecCloseResultRelations() for the relations in need of tracking by the  
apply operations in the subscribers, which would simplify greatly the  
opening and closing of indexes, but this requires a larger rework and  
reorganization of the worker code, particularly for the tuple routing  
part.  And that's not really welcome post feature freeze.  So, for now,  
settle down to the same solution as TRUNCATE which is to fill in  
es_opened_result_relations with the relation opened, to make sure that  
ExecGetTriggerResultRel() finds them and that they get closed.  
  
The code is lightly refactored so as a relation is not registered three  
times for each DML code path, making the whole a bit easier to follow.  
  
Reported-by: Tang Haiying, Shi Yu, Hou Zhijie  
Author: Amit Langote, Masahiko Sawada, Hou Zhijie  
Reviewed-by: Amit Kapila, Michael Paquier  
Discussion: https://postgr.es/m/OS0PR01MB611383FA0FE92EB9DE21946AFB769@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : 1599e7b375127cac81b539d2c69d3faf7598509b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Apr 2021 09:47:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Apr 2021 09:47:43 +0900    

parallel_leader_participation got introduced in e5253fd, where it was  
listed under RESOURCES_ASYNCHRONOUS in guc.c, but the documentation  
did not reflect that and listed it with the other planner-related  
options.  This commit fixes this inconsistency as the parameter is  
intended to be an asynchronous one.  
  
While on it, reorganize a bit the section dedicated to asynchronous  
parameters, backend_flush_after being moved first to do better in terms  
of alphabetical order of the options listed.  
  
Reported-by: Yanliang Lei  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/16972-42d4b0c15aa1d5f5@postgresql.org  

commit   : 7c298c6573a0f181963ddcb40c850fa9c7da0ada    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Apr 2021 18:36:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Apr 2021 18:36:12 -0400    

Per observation from Tom Lane.  
  
Discussion: https://postgr.es/m/1901125.1617904665@sss.pgh.pa.us  

commit   : 7b357cc6ae553c0ecacdc11b2e5278b7bf477dba    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Apr 2021 18:12:05 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Apr 2021 18:12:05 -0400    

On ALTER TABLE .. DETACH CONCURRENTLY, we add a new table constraint  
that duplicates the partition constraint.  But if the partition already  
has another constraint that implies that one, then that's unnecessary.  
We were already avoiding the addition of a duplicate constraint if there  
was an exact 'equal' match -- this just improves the quality of the check.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210410184226.GY6592@telsasoft.com  

commit   : e014d25deade08df082d2b37de45adb0c984f563    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 11:12:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 11:12:04 -0400    

commit   : 26ac261ee4033710cad44f7924d53753129b60c7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 16:02:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 16:02:03 +0200    

commit   : d064afc7204b52cb78a83fea0e686693ce5ba00c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 10:21:22 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 10:21:22 -0400    

This has been found to cause hangs where tcp usage is forced.  
  
Alexey Kodratov  
  
Discussion: https://postgr.es/m/82e271a9a11928337fcb5b5e57b423c0@postgrespro.ru  
  
Backpatch to all live branches  

commit   : d84ffffe582b8e036a14c6bc2378df29167f3a00    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 11:54:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 11:54:47 +0200    

Since pg_depend can contain duplicate entries, we need to eliminate  
those in information schema views that build on pg_depend, using  
DISTINCT.  Some of the older views already did that correctly, but  
some of the more recently added ones didn't.  (In some of these views,  
it might not be possible to reproduce the issue because of how the  
implementation happens to deduplicate dependencies while recording  
them, but it seems better to keep this consistent in all cases.)  

commit   : 39d0928a0e88426ee64189898565c40d4af9ad96    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 08:26:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 08:26:18 +0200    

Should be %u rather than %d.  

commit   : 544b28088f9d41750ccf193812da62bdfe4bd98a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 08:14:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Apr 2021 08:14:43 +0200    

commit   : 3286065651477c2060910dfb42b3cedbd79a7980    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Apr 2021 22:48:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Apr 2021 22:48:13 +0200    

Use %lld and cast to long long int instead.  

commit   : f0ec598b4323d8b29df5c67f2cd0000547a507ed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Apr 2021 22:47:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Apr 2021 22:47:43 +0200    

commit   : 64087eb5def7786bd49e60eb5d984ec6e4a872a9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 21 Apr 2021 12:02:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 21 Apr 2021 12:02:41 +0900    

Not enabling compute_query_id would disable pg_stat_statements even if  
the module is listed in shared_preload_libraries, so add it to the  
minimum configuration set as listed in its documentation.  
  
Author: Greg Nancarrow  
Reviewed-by: Julien Rouhaud, Bharath Rupireddy  
Discussion: https://postgr.es/m/CAJcOf-fXyb2QiDbwftD813UF70w-+BsK-03bFp1GrijXU9GQYQ@mail.gmail.com  

commit   : 22b2dec31b2ef4dfee299290b16375e9fa6e6932    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 21 Apr 2021 10:34:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 21 Apr 2021 10:34:43 +0900    

This compatibility has been added in 45b9805, but psql forgot the call.  
  
Author: Wei Wang  
Reviewed-by: Aleksander Alekseev  
Discussion: https://postgr.es/m/OS3PR01MB6275935F62E161BCD393D6559E489@OS3PR01MB6275.jpnprd01.prod.outlook.com  

commit   : 783be78ca91166ac7f80c953f2bbc5af1f61c6cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 17:01:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 17:01:43 -0400    

While tracking down the bug fixed in the preceding commit, I got quite  
annoyed by the low quality of spg_desc's output.  Add missing fields,  
try to make the formatting consistent.  

commit   : 9e41148229192dccc4bcc40f53af588b73d8ffea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 16:58:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 16:58:30 -0400    

Commit f003d9f87 left this macro with inadequate (or, one could say,  
too much) parenthesization.  Which was catastrophic to the correctness  
of calls such as "if (!XLogRecHasBlockRef(record, 1)) ...".  There  
are only a few of those, which perhaps explains why we didn't notice  
immediately (with our general weakness of WAL replay testing being  
another factor).  I found it by debugging intermittent replay failures  
like  
  
2021-04-08 14:33:30.191 EDT [29463] PANIC:  failed to locate backup block with ID 1  
2021-04-08 14:33:30.191 EDT [29463] CONTEXT:  WAL redo at 0/95D3438 for SPGist/ADD_NODE: off 1; blkref #0: rel 1663/16384/25998, blk 1  

commit   : db01f797dd48f826c62e1b8eea70f11fe7ff3efc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Apr 2021 12:57:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Apr 2021 12:57:59 -0400    

log_statement is issued before query_id can be computed, so properly  
clear the value, and document the interaction.  
  
Reported-by: Fujii Masao, Michael Paquier  
  
Discussion: https://postgr.es/m/YHPkU8hFi4no4NSw@paquier.xyz  
  
Author: Julien Rouhaud  

commit   : 9660834dd8bf5b093f7b49eef846666201d45a35    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Apr 2021 12:22:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Apr 2021 12:22:26 -0400    

Previously, it was pg_stat_activity.queryid to match the  
pg_stat_statements queryid column.  This is an adjustment to patch  
4f0b0966c8.  This also adjusts some of the internal function calls to  
match.  Catversion bumped.  
  
Reported-by: Álvaro Herrera, Julien Rouhaud  
  
Discussion: https://postgr.es/m/20210408032704.GA7498@alvherre.pgsql  

commit   : 7645376774c8532159f5f0f905e5e734d4ccbb18    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 11:37:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 11:37:36 -0400    

I didn't particularly like this function name, as it fails to  
express what's going on.  Also, returning the sort expression  
alone isn't too helpful --- typically, a caller would also  
need some other fields of the EquivalenceMember.  But the  
sole caller really only needs a bool result, so let's make  
it "bool relation_can_be_sorted_early()".  
  
Discussion: https://postgr.es/m/91f3ec99-85a4-fa55-ea74-33f85a5c651f@swarm64.com  

commit   : 375398244168add84a884347625d14581a421e71    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 11:32:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 11:32:02 -0400    

An oversight introduced by the incremental-sort patches caused  
"could not find pathkey item to sort" errors in some situations  
where a sort key involves an aggregate or window function.  
  
The basic problem here is that find_em_expr_usable_for_sorting_rel  
isn't properly modeling what prepare_sort_from_pathkeys will do  
later.  Rather than hoping we can keep those functions in sync,  
let's refactor so that they actually share the code for  
identifying a suitable sort expression.  
  
With this refactoring, tlist.c's tlist_member_ignore_relabel  
is unused.  I removed it in HEAD but left it in place in v13,  
in case any extensions are using it.  
  
Per report from Luc Vlaming.  Back-patch to v13 where the  
problem arose.  
  
James Coleman and Tom Lane  
  
Discussion: https://postgr.es/m/91f3ec99-85a4-fa55-ea74-33f85a5c651f@swarm64.com  

commit   : 95c3a1956ec9eac686c1b69b033dd79211b72343    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 20 Apr 2021 10:14:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 20 Apr 2021 10:14:16 -0400    

Commit b34ca595ab provided for installation-aware instances of  
PostgresNode. However, it turns out that IPC::Run works against this by  
caching the path to a binary and not consulting the path again, even if  
it has changed. We work around this by calling Postgres binaries with  
the installed path rather than just a bare name to be looked up in the  
environment path, if there is an installed path. For the common case  
where there is no installed path we continue to use the bare command  
name.  
  
Diagnosis and solution from Mark Dilger  
  
Discussion: https://postgr.es/m/E8F512F8-B4D6-4514-BA8D-2E671439DA92@enterprisedb.com  

commit   : 8b4b5669cde2b17bd6b5d68f584d97078f3296ac    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 20 Apr 2021 14:35:16 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 20 Apr 2021 14:35:16 +0200    

Author: Julien Rouhaud  
Backpatch-through: 11  
Discussion: https://postgr.es/m/20210420121659.odjueyd4rpilorn5@nol  

commit   : 7136bf34f28892362144ae2e350714836a5c0c0c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Apr 2021 18:55:31 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Apr 2021 18:55:31 -0700    

Document VACUUM's soft assumption that any LP_DEAD items encountered  
during pruning will become LP_UNUSED items before VACUUM finishes up.  
This is integral to the accounting used by VACUUM to generate its final  
report on the table to the stats collector.  It also affects how VACUUM  
determines which heap pages are truncatable.  In both cases VACUUM is  
concerned with the likely contents of the page in the near future, not  
the current contents of the page.  
  
This state of affairs created the false impression that VACUUM's dead  
tuple accounting had significant difference with similar accounting used  
during ANALYZE.  There were and are no substantive differences, at least  
when the soft assumption completely works out.  This is far clearer now.  
  
Also document cases where things don't quite work out for VACUUM's dead  
tuple accounting.  It's possible that a significant number of LP_DEAD  
items will be left behind by VACUUM, and won't be recorded as remaining  
dead tuples in VACUUM's statistics collector report.  This behavior  
dates back to commit a96c41fe, which taught VACUUM to run without index  
and heap vacuuming at the user's request.  The failsafe mechanism added  
to VACUUM more recently by commit 1e55e7d1 takes the same approach to  
dead tuple accounting.  
  
Reported-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAH2-Wz=Jmtu18PrsYq3EvvZJGOmZqSO2u3bvKpx9xJa5uhNp=Q@mail.gmail.com  

commit   : 640b91c3ed24002b34c7226fb51ef9176fb72713    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Apr 2021 10:43:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Apr 2021 10:43:18 +0200    

Should be signed, not unsigned.  

commit   : c64dcc7fee5f8a7941a4fd098a969de1f457cc79    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Apr 2021 09:02:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Apr 2021 09:02:47 +0530    

In the new test after resetting the stats, we were not waiting for the  
stats message to be delivered. Also, we need to decode the results for  
the new test, otherwise, it will show the old stats.  
  
In passing,  
a. Change docs added by commit f5fc2f5b23 as per suggestion by  
Justin Pryzby.  
b. Bump the PGSTAT_FILE_FORMAT_ID as commit f5fc2f5b23 changes the file  
format of stats.  
  
Reported-by: Tom Lane based on buildfarm reports  
Author: Vignesh C, Justin Pryzby  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : 7ef8b52cf079ef3ace4575f7b97c2d6f80463b4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Apr 2021 11:32:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Apr 2021 11:32:30 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210416070310.GG3315@telsasoft.com  

commit   : c731f9187b5fd7038b04ba60703d3cace1806366    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Apr 2021 10:15:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Apr 2021 10:15:35 +0900    

A couple of tests have been using 0 as magic constant while SEEK_SET can  
be used instead.  This makes the code easier to understand, and more  
consistent with the changes done in 3c5b068.  
  
Per discussion with Andrew Dunstan.  
  
Discussion: https://postgr.es/m/YHrc24AgJQ6tQ1q0@paquier.xyz  

commit   : 8e861eaae86eeaf5589963c9b1c7ce6d4c2acbb5    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 19 Apr 2021 10:22:31 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 19 Apr 2021 10:22:31 +1200    

Add a few words of comment to explain why SIGURG doesn't follow the  
dummy_handler pattern used for SIGUSR2, since that might otherwise  
appear to be a bug.  
  
Discussion: https://postgr.es/m/4006115.1618577212%40sss.pgh.pa.us  

commit   : 4ed7f0599a8984d9ed967780a157d9b23d03fbb5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 18 Apr 2021 16:11:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 18 Apr 2021 16:11:58 +0200    

commit   : f7c09706c14d0858d5a186f3cc769471cba41578    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Apr 2021 14:14:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Apr 2021 14:14:26 +0200    

commit   : f59b58e2a1b7e4a48dee36cc61966759da0faedd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Apr 2021 09:40:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Apr 2021 09:40:50 +0200    

Should be %u rather than %d.  

commit   : f24b156997059c257c697b825f022d115825091d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 22:23:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 22:23:46 -0400    

As it stands, find_expr_references_walker() pays attention to leaf-node  
collation fields while ignoring the input collations of actual function  
and operator nodes.  That seems exactly backwards from a semantic  
standpoint, and it leads to reporting dependencies on collations that  
really have nothing to do with the expression's behavior.  
  
Hence, rewrite to look at function input collations instead.  This  
isn't completely perfect either; it fails to account for the behavior  
of record_eq and its siblings.  (The previous coding at least gave an  
approximation of that, though I think it could be fooled pretty easily  
into considering the columns of irrelevant composite types.)  We may  
be able to improve on this later, but for now this should satisfy the  
buildfarm members that didn't like ef387bed8.  
  
In passing fix some oversights in GetTypeCollations(), and get  
rid of its duplicative de-duplications.  (I'm worried that it's  
still potentially O(N^2) or worse, but this makes it a little  
better.)  
  
Discussion: https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us  

commit   : 8a2df442b652f83b1c189822737091b90f343965    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 19:01:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 19:01:22 -0400    

Ooops, forgot to s/system_views.sql/system_functions.sql/g  
in this part of 767982e36.  
  
No need for an additional catversion bump, I think, since  
these strings are gone by the time initdb finishes.  
  
Discussion: https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us  

commit   : 767982e36298be4da44a063e36261e9cfdc0bf49    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 18:36:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 18:36:45 -0400    

Adopt the new pre-parsed representation for all built-in and  
information_schema SQL-language functions, except for a small  
number that can't presently be converted because they have  
polymorphic arguments.  
  
This eliminates residual hazards around search-path safety of  
these functions, and might provide some small performance benefits  
by reducing parsing costs.  It seems useful also to provide more  
test coverage for the SQL-standard-body feature.  
  
Discussion: https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us  

commit   : e80949372564c126c92aa7d64de483e04c0ef95e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 18:20:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 18:20:42 -0400    

Invent system_functions.sql to carry the function definitions that  
were formerly in system_views.sql.  The function definitions were  
already a quarter of the file and are about to be more, so it seems  
appropriate to give them their own home.  
  
In passing, fix an oversight in dfb75e478: it neglected to call  
check_input() for system_constraints.sql.  
  
Discussion: https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us  

commit   : 3c5b0685b921533f37622345beb0f8dd49200c01    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 16 Apr 2021 16:54:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 16 Apr 2021 16:54:04 -0400    

In order to avoid getting old logfile contents certain functions in  
PostgresNode were doing one of two things. On Windows it rotated the  
logfile and restarted the server, while elsewhere it truncated the log  
file. Both of these are unnecessary. We borrow from the buildfarm which  
does this instead: note the size of the logfile before we start, and  
then when fetching the logfile skip to that position before accumulating  
contents. This is spelled differently on Windows but the effect is the  
same. This is largely centralized in TestLib's slurp_file function,  
which has a new optional parameter, the offset to skip to before  
starting to reading the file. Code in the client becomes much neater.  
  
Backpatch to all live branches.  
  
Michael Paquier, slightly modified by me.  
  
Discussion: https://postgr.es/m/YHajnhcMAI3++pJL@paquier.xyz  

commit   : ef387bed87f2787b1012e68e9a33607a1074c123    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 12:26:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 12:26:50 -0400    

recordMultipleDependencies had the wrong scope for its "version"  
variable, allowing a version label to leak from the collation entry it  
was meant for to subsequent non-collation entries.  This is relatively  
hard to trigger because of the OID-descending order that the inputs  
will normally arrive in: subsequent non-collation items will tend to  
be pinned.  But it can be exhibited easily with a custom collation.  
  
Also, don't special-case the default collation, but instead ignore  
pinned-ness of a collation when we've found a version for it.  This  
avoids creating useless pg_depend entries, and removes a not-very-  
future-proof assumption that C, POSIX, and DEFAULT are the only  
pinned collations.  
  
A small problem is that, because the default collation may or may  
not have a version, the regression tests can't assume anything about  
whether dependency entries will be made for it.  This seems OK though  
since it's now handled just the same as other collations, and we have  
test cases for both versioned and unversioned collations.  
  
Fixes oversights in commit 257836a75.  Thanks to Julien Rouhaud  
for review.  
  
Discussion: https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us  

commit   : f90c708a048667befbf6bbe5f48ae9695cb89de4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 11:30:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Apr 2021 11:30:27 -0400    

This is only a latent bug, since these calls are only reached for  
non-text output formats, and currently none of those will print  
the units.  Still, we should get it right in case that ever changes.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20210415163846.GA3315@telsasoft.com  

commit   : 029c5ac03db72f1898ee17e417650a2e0764b239    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Apr 2021 11:46:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Apr 2021 11:46:01 +0200    

Only track BEGIN...END blocks if they are in a CREATE [OR REPLACE]  
{FUNCTION|PROCEDURE} statement.  Ignore if in parentheses.  
  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://www.postgresql.org/message-id/cee01d26fe55bc086b3bcf10bfe4e8d450e2f608.camel@cybertec.at  

commit   : 25593d7d338232fb855ba563b325237de8f14091    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Apr 2021 11:04:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Apr 2021 11:04:04 +0200    

commit   : 254a2164e5b216ecf98882f8bcb9e239ab2d432d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 16 Apr 2021 16:56:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 16 Apr 2021 16:56:12 +0900    

Author: Erik Rijkers  
Discussion: https://postgr.es/m/1219476687.20432.1617452918468@webmailclassic.xs4all.nl  
Backpatch-through: 12  

commit   : f5fc2f5b23d1b1dff60f8ca5dc211161df47eda4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 16 Apr 2021 07:34:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 16 Apr 2021 07:34:43 +0530    

This adds the statistics about total transactions count and total  
transaction data logically sent to the decoding output plugin from  
ReorderBuffer. Users can query the pg_stat_replication_slots view to check  
these stats.  
  
Suggested-by: Andres Freund  
Author: Vignesh C and Amit Kapila  
Reviewed-by: Sawada Masahiko, Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : 1bf946bd43e545b86e567588b791311fe4e36a8c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 16 Apr 2021 13:20:58 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 16 Apr 2021 13:20:58 +1200    

Warn users that locales with traditional Windows NLS names like  
"English_United States.1252" won't provide version information, and that  
something like initdb --lc-collate=en-US would be needed to fix that  
problem for the initial template databases.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJ_hk3rU%3D%3Dg2FpAMChb_4i%2BTJacpjjqFsinY-tRM3FBmA%40mail.gmail.com  

commit   : 409723365b2708acd3bdf2e830257504bdefac4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 17:24:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 17:24:12 -0400    

Without this, we lose error cursor positions, as shown in the  
modified regression test result.  
  
Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us  

commit   : 83efce7a1ebc5bae79617ddba12a64790141725c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 17:17:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 17:17:45 -0400    

This reverts commit b3ee4c503872f3d0a5d6a7cbde48815f555af15b.  
We don't need it in the wake of the preceding commit, which  
added an upstream check that the querystring isn't null.  
  
Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us  

commit   : 1111b2668d89bfcb6f502789158b1233ab4217a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 17:17:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 17:17:20 -0400    

Commit e717a9a18 changed the longstanding rule that prosrc is NOT NULL  
because when a SQL-language function is written in SQL-standard style,  
we don't currently have anything useful to put there.  This seems a poor  
decision though, as it could easily have negative impacts on external  
PLs (opening them to crashes they didn't use to have, for instance).  
SQL-function-related code can just as easily test "is prosqlbody not  
null" as "is prosrc null", so there's no real gain there either.  
Hence, revert the NOT NULL marking removal and adjust related logic.  
  
For now, we just put an empty string into prosrc for SQL-standard  
functions.  Maybe we'll have a better idea later, although the  
history of things like pg_attrdef.adsrc suggests that it's not  
easy to maintain a string equivalent of a node tree.  
  
This also adds an assertion that queryDesc->sourceText != NULL  
to standard_ExecutorStart.  We'd been silently relying on that  
for awhile, so let's make it less silent.  
  
Also fix some overlooked documentation and test cases.  
  
Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us  

commit   : 3157cbe974846729d49a1ee081944eee1839bdd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 16:31:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Apr 2021 16:31:36 -0400    

These queries could show unexpected entries if the core system,  
or concurrently-running test scripts, created any functions that  
would appear in the information_schema views.  Restrict them  
to showing functions belonging to this test's schema, as the  
far-older nearby test case does.  
  
Per experimentation with conversion of some built-in functions  
to SQL-function-body style.  

commit   : fae65629cec824738ee11bf60f757239906d64fa    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 15 Apr 2021 19:41:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 15 Apr 2021 19:41:42 +0200    

This reverts commit 3a5130672296ed4e682403a77a9a3ad3d21cef75.  
  
Per discussion, this patch had too many issues to resolve at this  
point of the development cycle.  We'll try again in the future.  
  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1904132231510.8961@lancre  

commit   : e2e2efca85b4857361780ed0c736c2a44edb458a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 15 Apr 2021 23:15:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 15 Apr 2021 23:15:19 +0900    

Commit bbe0a81db6 introduced "INCLUDING COMPRESSION" option  
in CREATE TABLE command, but forgot to mention it in the  
CREATE TABLE syntax synopsis.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/54d30e66-dbd6-5485-aaf6-a291ed55919d@oss.nttdata.com  

commit   : 1840d9f4c89998872a3b46473f8e9e5b6ff3c144    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Apr 2021 16:45:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Apr 2021 16:45:34 +0900    

e4c7619 has added a space to the example used for HISTFILE in the docs  
of psql before the variable DBNAME, as a workaround because variables  
were not parsed the same way back then.  This behavior has changed in  
9.2, causing the example in the psql docs to result in the same history  
file created with or without a space added before the DBNAME variable.  
  
Let's just remove this space in the example, to reduce any confusion, as  
the point of it is to prove that a per-database history file is easy to  
set up, and that's easier to read this way.  
  
Per discussion with Tom Lane.  
  
Reported-by: Ludovic Kuty  
Discussion: https://postgr.es/m/161830067409.691.16198363670687811485@wrigleys.postgresql.org  

commit   : cbae8774eb5c2f5552323ee18ca5286f9c8e5d06    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 15 Apr 2021 09:08:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 15 Apr 2021 09:08:18 +0200    

commit   : 59da8d9eb7255c3cb1c9f3b79d76b18b6a1c7da2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 15 Apr 2021 08:58:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 15 Apr 2021 08:58:03 +0200    

Several of these were already fixed in passing in  
9acaf1a62197205b06a85afbfcaa7ffaac939ef3, but one was remaining  
inconsistent.  

commit   : 344487e2db03f3cec13685a839dbc8a0e2a36750    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Apr 2021 10:03:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Apr 2021 10:03:46 +0900    

6568cef, that introduced the option, had an inconsistent behavior when  
it comes to configuration tables set up by pg_extension_config_dump, as  
the data of all configuration tables would included in a dump even for  
extensions not listed by a set of --extension switches.  
  
The contents dumped changed depending on the schema where an extension  
was installed when an extension was not listed.  For example, an  
extension installed under the public schema would have its configuration  
data not dumped even when not listed with --extension, which was  
inconsistent with the case of an extension installed on a non-public  
schema, where the configuration would be dumped.  
  
Per discussion with Noah, we have settled down to the simple rule of  
dumping configuration data of an extension if it is listed in  
--extension (default is unchanged and backward-compatible, to dump  
everything on sight if there are no extensions directly listed).  This  
avoids some weird cases where the dumps depended on a --schema for one.  
  
More tests are added to cover the gap, where we cross-check more  
behaviors depending on --schema when an extension is not listed.  
  
Reported-by: Noah Misch  
Reviewed-by: Noah Misch  
Discussion: https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com  

commit   : e1623b7d86812ee6ab98a42f38b43a192c149988    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Apr 2021 14:28:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Apr 2021 14:28:17 -0400    

That field went away in commit edca44b15, but it seems that  
commit 45be99f8c re-introduced some comments mentioning it.  
Noted by James Coleman, though this isn't exactly his  
proposed new wording.  Also thanks to Justin Pryzby for  
software archaeology.  
  
Discussion: https://postgr.es/m/CAAaqYe8fxZjq3na+XkNx4C78gDqykH-7dbnzygm9Qa9nuDTePg@mail.gmail.com  

commit   : 9acaf1a62197205b06a85afbfcaa7ffaac939ef3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 14 Apr 2021 12:46:31 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 14 Apr 2021 12:46:31 -0400    

We don't need to mention the attribute number in these messages, because  
there's a dedicated column for that, but we should mention the toast  
value ID, because that's really useful for any follow-up troubleshooting  
the user wants to do. This also rewords some of the messages to hopefully  
read a little better.  
  
Also, use VARATT_EXTERNAL_GET_POINTER in case we're accessing a TOAST  
pointer that isn't aligned on a platform that's fussy about alignment,  
so that we don't crash while corruption-checking the user's data.  
  
Mark Dilger, reviewed by me.  
  
Discussion: http://postgr.es/m/7D3B9BF6-50D0-4C30-8506-1C1851C7F96F@enterprisedb.com  

commit   : 07e5e66742333ab100a557e6e3f710e92fa1fd92    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Apr 2021 09:10:57 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Apr 2021 09:10:57 +0200    

commit   : ac725ee0f98c3fec703ffd9b070da629608e9a1e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Apr 2021 15:55:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Apr 2021 15:55:55 +0900    

This GUC has always been classified as a planner option since its  
introduction in 7c944bd, and was listed in postgresql.conf.sample.  As  
this parameter exists for testing purposes, move it to the section  
dedicated to developer parameters and hence remove it from  
postgresql.conf.sample.  This will avoid any temptation to play with it  
on production servers for users that should never really have to touch  
this parameter.  
  
The general description used for developer options is reworded a bit, to  
take into account the inclusion of force_parallel_mode, per a suggestion  
from Tom Lane.  
  
Per discussion between Tom Lane, Bruce Momjian, Justin Pryzby, Bharath  
Rupireddy and me.  
  
Author: Justin Pryzby, Tom Lane  
Discussion: https://postgr.es/m/20210403152402.GA8049@momjian.us  

commit   : 93f41461449f917da20af4fa2973f8afe8e6ea6e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Apr 2021 14:23:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Apr 2021 14:23:53 +0900    

The tests introduced in 32a9c0b for connections broken and  
re-established rely on pg_terminate_backend() for their logic.  When  
these were introduced, this function simply sent a signal to a backend  
without waiting for the operation to complete, and the tests repeatedly  
looked at pg_stat_activity to check if the operation was completed or  
not.  Since aaf0432, it is possible to define a timeout to make  
pg_terminate_backend() wait for a certain duration, so make use of it,  
with a timeout reasonably large enough (3min) to give enough room for  
the tests to pass even on slow machines.  
  
Some measurements show that the tests of postgres_fdw are much faster  
with this change.  For example, on my laptop, they now take 4s instead  
of 6s.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACXGY_EfGrMTjKjHy2zi-u1u9rdeioU_fro0T6Jo8t56KQ@mail.gmail.com  

commit   : cca57c1d9bf7eeba5b81115e0b82651cf3d8e4ea    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 14 Apr 2021 08:55:03 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 14 Apr 2021 08:55:03 +0530    

This will make it consistent with the other usage of slotname in the code.  
In the passing, change pgstat_report_replslot signature to use a structure  
rather than multiple parameters.  
  
Reported-by: Andres Freund  
Author: Vignesh C  
Reviewed-by: Sawada Masahiko, Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : 20661c15db8f430d4880ba685e6b12afa271c1ac    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 14 Apr 2021 00:46:12 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 14 Apr 2021 00:46:12 +0200    

The function is building a fake heap tuple, but left some of the header  
fields (tid and table OID) uninitialized. Per Coverity report.  
  
Reported-by: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQApj6h8tZ0-eP5Af5PKc5NG1YUc7=SdN_99YoHS51fKa0Q@mail.gmail.com  

commit   : 60f1f09ff44308667ef6c72fbafd68235e55ae27    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Apr 2021 12:58:31 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Apr 2021 12:58:31 -0700    

It seems like a good idea to bypass heap truncation when the wraparound  
failsafe mechanism (which was added in commit 1e55e7d1) is in effect.  
  
Deliberately don't bypass heap truncation in the INDEX_CLEANUP=off case,  
even though it is similar to the failsafe case.  There is already a  
separate reloption (and related VACUUM parameter) for that.  
  
Reported-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoDWRh6oTN5T8wa+cpZUVpHXET8BJ8Da7WHVHpwkPP6KLg@mail.gmail.com  

commit   : 6c0373ab77359c94b279c4e67c91aa623841af65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 15:39:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 15:39:33 -0400    

Previously you could only use unqualified variable names here.  
While that's not a functional deficiency, since only the target  
table can be referenced, it's a surprising inconsistency with the  
rules for partial-index predicates, on which this syntax is  
supposedly modeled.  
  
The fix for that is no harder than passing addToRelNameSpace = true  
to addNSItemToQuery.  However, it's really pretty bogus for  
transformOnConflictArbiter and transformOnConflictClause to be  
messing with the namespace item for the target table at all.  
It's not theirs to manage, it results in duplicative creations of  
namespace items, and transformOnConflictClause wasn't even doing  
it quite correctly (that coding resulted in two nsitems for the  
target table, since it hadn't cleaned out the existing one).  
Hence, make transformInsertStmt responsible for setting up the  
target nsitem once for both these clauses and RETURNING.  
  
Also, arrange for ON CONFLICT ... UPDATE's "excluded" pseudo-relation  
to be added to the rangetable before we run transformOnConflictArbiter.  
This produces a more helpful HINT if someone writes "excluded.col"  
in the arbiter expression.  
  
Per bug #16958 from Lukas Eder.  Although I agree this is a bug,  
the consequences are hardly severe, so no back-patch.  
  
Discussion: https://postgr.es/m/16958-963f638020de271c@postgresql.org  

commit   : e8c435a824e123f43067ce6f69d66f14cfb8815e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Apr 2021 14:56:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Apr 2021 14:56:12 -0400    

Mention that there are multiple TOAST compression methods and that the  
compression method used is stored in a TOAST pointer along with the  
other information that was stored there previously. Add a reference to  
the documentation for default_toast_compression, where the supported  
methods are listed, instead of duplicating that here.  
  
I haven't tried to preserve the text claiming that pglz is "fairly  
simple and very fast." I have no view on the veracity of the former  
claim, but LZ4 seems to be faster (and to compress better) so it  
seems better not to muddy the waters by talking about compression  
speed as a strong point of PGLZ.  
  
Patch by me, reviewed by Justin Pryzby.  
  
Discussion: http://postgr.es/m/CA+Tgmoaw_YBwQhOS_hhEPPwFhfAnu+VCLs18EfGr9gQw1z4H-w@mail.gmail.com  

commit   : 69d5ca484b69771073380e234e5377b6d6a5ebaf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 15:10:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 15:10:18 -0400    

Most GUC check hooks that inspect database state have special checks  
that prevent them from throwing hard errors for state-dependent issues  
when source == PGC_S_TEST.  This allows, for example,  
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"  
configuration hasn't been created yet.  Without this, we have problems  
during dump/reload or pg_upgrade, because pg_dump has no idea about  
possible dependencies of GUC values and can't ensure a safe restore  
ordering.  
  
However, check_role() and check_session_authorization() hadn't gotten  
the memo about that, and would throw hard errors anyway.  It's not  
entirely clear what is the use-case for "ALTER ROLE x SET role = y",  
but we've now heard two independent complaints about that bollixing  
an upgrade, so apparently some people are doing it.  
  
Hence, fix these two functions to act more like other check hooks  
with similar needs.  (But I did not change their insistence on  
being inside a transaction, as it's still not apparent that setting  
either GUC from the configuration file would be wise.)  
  
Also fix check_temp_buffers, which had a different form of the disease  
of making state-dependent checks without any exception for PGC_S_TEST.  
A cursory survey of other GUC check hooks did not find any more issues  
of this ilk.  (There are a lot of interdependencies among  
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but  
they're not relevant to the immediate concern because they can't be  
set via ALTER ROLE/DATABASE.)  
  
Per reports from Charlie Hornsby and Nathan Bossart.  Back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM  
Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org  

commit   : c2db458c1036efae503ce5e451f8369e64c99541    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 13:37:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 13:37:07 -0400    

Previously, get_cached_rowtype() cached a pointer to a reference-counted  
tuple descriptor from the typcache, relying on the ExprContextCallback  
mechanism to release the tupdesc refcount when the expression tree  
using the tupdesc was destroyed.  This worked fine when it was designed,  
but the introduction of within-DO-block COMMITs broke it.  The refcount  
is logged in a transaction-lifespan resource owner, but plpgsql won't  
destroy simple expressions made within the DO block (before its first  
commit) until the DO block is exited.  That results in a warning about  
a leaked tupdesc refcount when the COMMIT destroys the original resource  
owner, and then an error about the active resource owner not holding a  
matching refcount when the expression is destroyed.  
  
To fix, get rid of the need to have a shutdown callback at all, by  
instead caching a pointer to the relevant typcache entry.  Those  
survive for the life of the backend, so we needn't worry about the  
pointer becoming stale.  (For registered RECORD types, we can still  
cache a pointer to the tupdesc, knowing that it won't change for the  
life of the backend.)  This mechanism has been in use in plpgsql  
and expandedrecord.c since commit 4b93f5799, and seems to work well.  
  
This change requires modifying the ExprEvalStep structs used by the  
relevant expression step types, which is slightly worrisome for  
back-patching.  However, there seems no good reason for extensions  
to be familiar with the details of these particular sub-structs.  
  
Per report from Rohit Bhogate.  Back-patch to v11 where within-DO-block  
COMMITs became a thing.  
  
Discussion: https://postgr.es/m/CAAV6ZkQRCVBh8qAY+SZiHnz+U+FqAGBBDaDTjF2yiKa2nJSLKg@mail.gmail.com  

commit   : 34f581c39e97e2ea237255cf75cccebccc02d477    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 12:17:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 12:17:24 -0400    

heap_update needs to clear any existing "all visible" flag on  
the old tuple's page (and on the new page too, if different).  
Per coding rules, to do this it must acquire pin on the appropriate  
visibility-map page while not holding exclusive buffer lock;  
which creates a race condition since someone else could set the  
flag whenever we're not holding the buffer lock.  The code is  
supposed to handle that by re-checking the flag after acquiring  
buffer lock and retrying if it became set.  However, one code  
path through heap_update itself, as well as one in its subroutine  
RelationGetBufferForTuple, failed to do this.  The end result,  
in the unlikely event that a concurrent VACUUM did set the flag  
while we're transiently not holding lock, is a non-recurring  
"PANIC: wrong buffer passed to visibilitymap_clear" failure.  
  
This has been seen a few times in the buildfarm since recent VACUUM  
changes that added code paths that could set the all-visible flag  
while holding only exclusive buffer lock.  Previously, the flag  
was (usually?) set only after doing LockBufferForCleanup, which  
would insist on buffer pin count zero, thus preventing the flag  
from becoming set partway through heap_update.  However, it's  
clear that it's heap_update not VACUUM that's at fault here.  
  
What's less clear is whether there is any hazard from these bugs  
in released branches.  heap_update is certainly violating API  
expectations, but if there is no code path that can set all-visible  
without a cleanup lock then it's only a latent bug.  That's not  
100% certain though, besides which we should worry about extensions  
or future back-patch fixes that could introduce such code paths.  
  
I chose to back-patch to v12.  Fixing RelationGetBufferForTuple  
before that would require also back-patching portions of older  
fixes (notably 0d1fe9f74), which is more code churn than seems  
prudent to fix a hypothetical issue.  
  
Discussion: https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us  

commit   : 5fe83adad9efd5e3929f0465b44e786dc23c7b55    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 13 Apr 2021 14:21:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 13 Apr 2021 14:21:51 +0900    

Introduced in commit 0aa8a01d04.  
  
Author: Peter Smith  
Discussion: https://postgr.es/m/CAHut+Ps8rkVHKWyjg09Fb1PaVG5-EhoFTFJ9OZMF4HPzDSXfew@mail.gmail.com  

commit   : 455dbc010be53ac61fcb2da83b1e565f4c263449    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:41 -0700    

With the Oracle Developer Studio 12.6 compiler, #line directives alter  
the current source file location for purposes of #include "..."  
directives.  Hence, a VPATH build failed with 'cannot find include file:  
"specscanner.c"'.  With two exceptions, parser-containing directories  
already add "-I. -I$(srcdir)"; eliminate the exceptions.  Back-patch to  
9.6 (all supported versions).  

commit   : c3556f6fac349b31da2fd00107469ce36fb37536    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:21 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:21 -0700    

It doesn't support "\(foo\)*" like a POSIX "sed" implementation does;  
see the Autoconf manual.  Back-patch to 9.6 (all supported versions).  

commit   : b1df6b696b759f00ebbf02e6de64e259d4be5785    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 13 Apr 2021 12:34:25 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 13 Apr 2021 12:34:25 +1200    

Commit 6f38d4dac38 failed to heed a warning about the stability of the  
value pointed to by "otid".  The caller is allowed to pass in a pointer to  
newtup->t_self, which will be updated during the execution of the  
function.  Instead, the SSI check should use the value we copy into  
oldtup.t_self near the top of the function.  
  
Not a live bug, because newtup->t_self doesn't really get updated until  
a bit later, but it was confusing and broke the rule established by the  
comment.  
  
Back-patch to 13.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2689164.1618160085%40sss.pgh.pa.us  

commit   : 885a87641930778d9580fdf0656af24e3f52d276    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Apr 2021 09:42:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Apr 2021 09:42:01 +0900    

These got introduced in 6568cef.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com  

commit   : cf0020080a3de20287217621da57bfd840e9a693    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Apr 2021 18:58:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Apr 2021 18:58:20 -0400    

collate.icu.utf8.sql was exercising the recording of a collation  
dependency for an enum comparison expression, but such an expression  
should never have had any collation dependency in the first place.  
After I fixed that in commit c402b02b9, the test started failing.  
We don't need to test that scenario anymore, so just remove the  
now-useless test steps.  
  
(This test case is new in HEAD, so no need to back-patch.)  
  
Discussion: https://postgr.es/m/3044030.1618261159@sss.pgh.pa.us  
Discussion: https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com  

commit   : c402b02b9fb53aee2a26876de90a8f95f9a9be92    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Apr 2021 14:37:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Apr 2021 14:37:22 -0400    

There are hacks in parse_coerce.c to push down a requested coercion  
to below any CollateExpr that may appear.  However, we did that even  
if the requested data type is non-collatable, leading to an invalid  
expression tree in which CollateExpr is applied to a non-collatable  
type.  The fix is just to drop the CollateExpr altogether, reasoning  
that it's useless.  
  
This bug is ten years old, dating to the original addition of  
COLLATE support.  The lack of field complaints suggests that there  
aren't a lot of user-visible consequences.  We noticed the problem  
because it would trigger an assertion in DefineVirtualRelation if  
the invalid structure appears as an output column of a view; however,  
in a non-assert build, you don't see a crash just a (subtly incorrect)  
complaint about applying collation to a non-collatable type.  I found  
that by putting the incorrect structure further down in a view, I could  
make a view definition that would fail dump/reload, per the added  
regression test case.  But CollateExpr doesn't do anything at run-time,  
so this likely doesn't lead to any really exciting consequences.  
  
Per report from Yulin Pei.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com  

commit   : 6787e53fe59eed19095c771a8d3323fb59420733    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Apr 2021 20:29:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Apr 2021 20:29:24 +0200    

This could write wrong output into the cluster deletion script if a  
database OID exceeds the signed 32-bit range.  

commit   : fc0fefbfe0d7e805f6a3a4aaaad7127090fcca51    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Apr 2021 19:04:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Apr 2021 19:04:33 +0200    

commit   : 44c8a3d75997b08fa7645dac7ee5c7a918a235c7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Apr 2021 15:44:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Apr 2021 15:44:38 +0200    

broken by 37d2ff38031262a1778bc76a9c55fff7afbcf275  

commit   : 81e094bdfdd6cf6568cba2b25eea9876daceaacb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 12 Apr 2021 21:34:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 12 Apr 2021 21:34:23 +0900    

Commit 8ff1c94649 extended TRUNCATE command so that it can also truncate  
foreign tables. But it forgot to support tab-complete for TRUNCATE on  
foreign tables. That is, previously tab-complete for TRUNCATE displayed  
only the names of regular tables.  
  
This commit improves tab-complete for TRUNCATE so that it displays also  
the names of foreign tables.  
  
Author: Fujii Masao  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/551ed8c1-f531-818b-664a-2cecdab99cd8@oss.nttdata.com  

commit   : b094063cd16d22b2f065a432580bb3568b2d8a77    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Apr 2021 13:53:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Apr 2021 13:53:17 +0900    

This GUC has already been classified as LOGGING_WHAT, but its location  
in postgresql.conf.sample and the documentation did not reflect that, so  
fix those inconsistencies.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210404012546.GK6592@telsasoft.com  

commit   : 15c1a9d9cb7604472d4823f48b64cdc02c441194    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 12 Apr 2021 09:27:10 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 12 Apr 2021 09:27:10 +0530    

Updated documentation for new messages added for streaming of in-progress  
transactions, as well as changes made to the existing messages. It also  
updates the information of protocol versions supported for logical  
replication.  
  
Author: Ajin Cherian  
Reviewed-by: Amit Kapila, Peter Smith, Euler Taveira  
Discussion: https://postgr.es/m/CAFPTHDYHN9m=MZZct-B=BYg_TETvv+kXvL9RD2DpaBS5pGxGYg@mail.gmail.com  

commit   : 7a3972597f6ed7a6976d81abb66c38a7a1c29058    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Apr 2021 11:30:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Apr 2021 11:30:50 +0900    

Using Roman numbers (via "RM" or "rm") for a conversion to calculate a  
number of months has never considered the case of negative numbers,  
where a conversion could easily cause out-of-bound memory accesses.  The  
conversions in themselves were not completely consistent either, as  
specifying 12 would result in NULL, but it should mean XII.  
  
This commit reworks the conversion calculation to have a more  
consistent behavior:  
- If the number of months and years is 0, return NULL.  
- If the number of months is positive, return the exact month number.  
- If the number of months is negative, do a backward calculation, with  
-1 meaning December, -2 November, etc.  
  
Reported-by: Theodor Arsenij Larionov-Trichkin  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/16953-f255a18f8c51f1d5@postgresql.org  
backpatch-through: 9.6  

commit   : 6277435a8a89c59f716c111200c072d1454b8ff2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Apr 2021 17:02:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Apr 2021 17:02:04 -0400    

Coverity complained about possible overflow in expressions like  
	intresult = tm->tm_sec * 1000000 + fsec;  
on the grounds that the multiplication would happen in 32-bit  
arithmetic before widening to the int64 result.  I think these  
are all false positives because of the limited possible range of  
tm_sec; but nonetheless it seems silly to spell it like that when  
nearby lines have the identical computation written with a 64-bit  
constant.  
  
... or more accurately, with an LL constant, which is not project  
style.  Make all of these use INT64CONST(), as we do elsewhere.  
  
This is all new code from a2da77cdb, so no need for back-patch.  

commit   : d7cff12c4c035b7cf12bb8454824f48f13018730    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Apr 2021 13:22:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Apr 2021 13:22:56 -0400    

We'd previously noted the need for coping with Windows headers  
that provide some other definition of macro "ERROR" than elog.h  
does.  It turns out that R also wants to define ERROR, and  
WARNING too.  PL/R has been working around this in a hacky way  
that broke when we recently changed the numeric value of ERROR.  
To let them have a more future-proof solution, provide an  
alternate macro PGWARNING for WARNING, and make PGERROR visible  
always, not only when #ifdef WIN32.  
  
Discussion: https://postgr.es/m/CADK3HHK6iMChd1yoOqssxBn5Z14Zar8Ztr3G-N_fuG7F8YTP3w@mail.gmail.com  

commit   : 9cb92334092fa75afc62a71243bbc1f4612ecfa4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Apr 2021 11:46:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Apr 2021 11:46:32 -0400    

The path for *exprs != NIL would misbehave, and likely crash,  
since pull_varattnos expects its last argument to be valid  
at call.  
  
Found by Coverity --- we have no coverage of this path in  
the regression tests.  

commit   : 81a23dd87999ec9fb62554328c69c5b678612d56    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 12 Apr 2021 00:05:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 12 Apr 2021 00:05:58 +0900    

ExecuteTruncate() filters out the duplicate tables specified  
in the TRUNCATE command, for example in the case where "TRUNCATE foo, foo"  
is executed. Such duplicate tables obviously don't need to be opened  
and closed because they are skipped. But previously it always opened  
the tables before checking whether they were duplicated ones or not,  
and then closed them if they were. That is, the duplicated tables were  
opened and closed unnecessarily.  
  
This commit changes ExecuteTruncate() so that it opens the table  
after it confirms that table is not duplicated one, which leads to  
avoid unnecessary table open/close.  
  
Do not back-patch because such unnecessary table open/close is not  
a bug though it exists in older versions.  
  
Author: Bharath Rupireddy  
Reviewed-by: Amul Sul, Fujii Masao  
Discussion: https://postgr.es/m/CALj2ACUdBO_sXJTa08OZ0YT0qk7F_gAmRa9hT4dxRcgPS4nsZA@mail.gmail.com  

commit   : 08aa89b326261b669648df97d4f2a6edba22d26a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 12 Apr 2021 00:00:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 12 Apr 2021 00:00:18 +0900    

Commit 438fc4a39c prevented the WAL replay from writing  
COMMIT_TS_SETTS record. By this change there is no code that  
generates COMMIT_TS_SETTS record in PostgreSQL core.  
Also we can think that there are no extensions using the record  
because we've not received so far any complaints about the issue  
that commit 438fc4a39c fixed. Therefore this commit removes  
COMMIT_TS_SETTS record and its related code. Even without  
this record, the timestamp required for commit timestamp feature  
can be acquired from the COMMIT record.  
  
Bump WAL page magic.  
  
Reported-by: lx zou <zoulx1982@163.com>  
Author: Fujii Masao  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/16931-620d0f2fdc6108f1@postgresql.org  

commit   : df5efaf4410f94cc1b69e8ade1d64dc92232ec1d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 10 Apr 2021 12:01:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 10 Apr 2021 12:01:41 -0700    

Commit c9c41c7a337d3e2deb0b2a193e9ecfb865d8f52b used two different  
naming patterns.  Standardize on the majority pattern, which was the  
only pattern in the last reviewed version of that commit.  

commit   : 496e58bb0e5e939e6ed5839c92b05e3ab11b54bb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 10 Apr 2021 19:33:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 10 Apr 2021 19:33:46 +0200    

Currently, when the origin is after the input, the result is the  
timestamp at the end of the bin, rather than the beginning as  
expected.  This puts the result consistently at the beginning of the  
bin.  
  
Author: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/CAFBsxsGjLDxQofRfH+d4KSAXxPf3MMevUG7s6EDfdBOvHLDLjw@mail.gmail.com  

commit   : 99964c4ade468c35a3f6e248a2380a1ff67d9cd3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Apr 2021 13:16:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Apr 2021 13:16:08 -0400    

Per cpluspluscheck.  

commit   : 07b76833b15163c6574ea2c12d05d9a0800665e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Apr 2021 12:08:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Apr 2021 12:08:28 -0400    

Adjust docs and description string to note that check_function_bodies  
applies to procedures too.  (In hindsight it should have been named  
check_routine_bodies, but it seems too late for that now.)  
  
Daniel Westermann  
  
Discussion: https://postgr.es/m/GV0P278MB04834A9EB9A74B036DC7CE49D2739@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM  

commit   : 152d33bccec7176f50be225bdbedf2e6de214e54    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 10 Apr 2021 19:19:45 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 10 Apr 2021 19:19:45 +1200    

There were some comments in nodeFuncs.c that, depending on your  
interpretation of the word "result", could lead you to believe that the  
comments were badly copied and pasted from somewhere else.  If you thought  
of "result" as the return value of the function that the comment is  
written in, then you'd be misled.  However, if you'd correctly  
interpreted "result" to mean the result type of the given node type,  
you'd not have seen any issues.  
  
Here we do a small cleanup to try to prevent any future  
misinterpretations.  Per wording suggestion from Tom Lane.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAApHDvp+Bw=2Qiu5=uXMKfC7gd0+B=4JvexVgGJU=am2g9a1CA@mail.gmail.com  

commit   : 9cae39b8e6a53decb37cce22852bb2e6d0e3f5d3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 9 Apr 2021 23:23:45 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 9 Apr 2021 23:23:45 +0200    

Whitespace between tags is significant, and in some cases it creates  
extra vertical space in man pages.  The fix is to remove some newlines  
in the markup.  

commit   : e7e341409a3d85aba4cf754ba9cf722a4d8e6676    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Apr 2021 17:13:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Apr 2021 17:13:18 -0400    

A (relatively minor) annoyance of ErrorResponse/NoticeResponse messages  
as printed by PQtrace() is that their length might vary when we move  
error messages from one source file to another, one function to another,  
or even when their location line numbers change number of digits.  
  
To avoid having to adjust expected files for some tests, make the  
regress mode of PQtrace() suppress the length word of NoticeResponse and  
ErrorResponse messages.  
  
Discussion: https://postgr.es/m/20210402023010.GA13563@alvherre.pgsql  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : 846d35b2dc1bd4d09f5e3e5e5a2cc8efafeb600e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 10 Apr 2021 08:41:07 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 10 Apr 2021 08:41:07 +1200    

Reported-by: Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>  
Discussion: https://postgr.es/m/GV0P278MB0483490FEAC879DCA5ED583DD2739%40GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM  

commit   : dc88460c24ed71ba7464ef4749e5f25da1bf6652    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 10 Apr 2021 08:09:30 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 10 Apr 2021 08:09:30 +1200    

Typos, corrections and language improvements in the docs, and a few in  
code comments too.  
  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20210409033703.GP6592%40telsasoft.com  

commit   : 49fb4e6b249029e75ccc6b490d76f15cd53d553b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 9 Apr 2021 21:55:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 9 Apr 2021 21:55:08 +0200    

Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Author: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/CAFBsxsEEm1nuhZmfVQxvu_i3nDDEuvNJ_WMrDo9whFD_jusp-A@mail.gmail.com  

commit   : 41badeaba8beee7648ebe7923a41c04f1f3cb302    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Apr 2021 13:38:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Apr 2021 13:38:07 -0400    

Commit 0827e8af70f4 added parameters for autovacuum to support  
partitioned tables, but didn't add any docs.  Add them.  
  
Discussion: https://postgr.es/m/20210408213051.GL6592@telsasoft.com  

commit   : 0e69f705cc1a3df273b38c9883fb5765991e04fe    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Apr 2021 11:29:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Apr 2021 11:29:08 -0400    

When commit 0827e8af70f4 added auto-analyze support for partitioned  
tables, it included code to obtain reltuples for the partitioned table  
as a number of catalog accesses to read pg_class.reltuples for each  
partition.  That's not only very inefficient, but also problematic  
because autovacuum doesn't hold any locks on any of those tables -- and  
doesn't want to.  Replace that code with a read of pg_class.reltuples  
for the partitioned table, and make sure ANALYZE and TRUNCATE properly  
maintain that value.  
  
I found no code that would be affected by the change of relpages from  
zero to non-zero for partitioned tables, and no other code that should  
be maintaining it, but if there is, hopefully it'll be an easy fix.  
  
Per buildfarm.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>  
Discussion: https://postgr.es/m/1823909.1617862590@sss.pgh.pa.us  

commit   : 1798d8f8b6fbb8ff922f640ff2d5dbd3e47064a2    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 9 Apr 2021 12:40:14 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 9 Apr 2021 12:40:14 +0200    

Author: Daniel Westermann  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/GV0P278MB0483A7AA85BAFCC06D90F453D2739@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM  

commit   : 609b0652af00374b89411ea2613fd5bb92bca92c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Apr 2021 13:53:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Apr 2021 13:53:07 +0900    

Comment fixes are applied on HEAD, and documentation improvements are  
applied on back-branches where needed.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210408164008.GJ6592@telsasoft.com  
Backpatch-through: 9.6  

commit   : 796092fb84c08162ae803e83a13aa8bd6d9b23d0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 8 Apr 2021 12:54:31 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 8 Apr 2021 12:54:31 -0700    

Per complaint from Tom Lane  
  
Discussion: https://postgr.es/m/1922884.1617909599@sss.pgh.pa.us  

commit   : d1fcbde579d440c35023baa0de7ebf27f644a314    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Apr 2021 15:38:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Apr 2021 15:38:26 -0400    

Oversight in commit a3027e1e7.  

commit   : 01add89454d5dc289ed3126d5de03169bdeff41b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Apr 2021 15:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Apr 2021 15:14:26 -0400    

Several buildfarm critters that don't usually produce such  
warnings are complaining about e717a9a18.  I think it's  
actually safe, but move initialization to silence the warning.  

commit   : 0f61727b75b93915ca9a9f20c996ed7020996a38    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Apr 2021 11:16:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Apr 2021 11:16:01 -0400    

Ignore parallel workers in pg_stat_statements  
  Oversight in 4f0b0966c8 which exposed queryid in parallel workers.  
  Counters are aggregated by the main backend process so parallel workers  
  would report duplicated activity, and could also report activity for the  
  wrong entry as they are only aware of the top level queryid.  
  
Fix thinko in pg_stat_get_activity when retrieving the queryid.  
  
Remove unnecessary call to pgstat_report_queryid().  
  
Reported-by: Amit Kapila, Andres Freund, Thomas Munro  
  
Discussion: https://postgr.es/m/20210408051735.lfbdzun5zdlax5gd@alap3.anarazel.de p634GTSOqnDW86Owrn6qDAVosC5dJjXjp7BMfc5Gz1Q@mail.gmail.com  
  
Author: Julien Rouhaud  

commit   : 5844c23dc50508aefeb8183be45f4ee99e9dec17    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 8 Apr 2021 15:15:17 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 8 Apr 2021 15:15:17 +0200    

v1.9 is already new in this version of PostgreSQL, so turn it into just  
one change.  
  
Author: Julien Rohaud  
Discussion: https://postgr.es/m/20210408120505.7zinijtdexbyghvb@nol  

commit   : 34399a670a1c559ef8a355ed25d090d73e400ad4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Apr 2021 00:36:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Apr 2021 00:36:59 +1200    

Thinko in commit 323cbe7c, per complaint from BF animal locust's older  
GCC compiler.  

commit   : 8ff1c94649f5c9184ac5f07981d8aea9dfd7ac19    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 8 Apr 2021 20:56:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 8 Apr 2021 20:56:08 +0900    

This commit introduces new foreign data wrapper API for TRUNCATE.  
It extends TRUNCATE command so that it accepts foreign tables as  
the targets to truncate and invokes that API. Also it extends postgres_fdw  
so that it can issue TRUNCATE command to foreign servers, by adding  
new routine for that TRUNCATE API.  
  
The information about options specified in TRUNCATE command, e.g.,  
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to  
truncate is also passed to FDW. FDW truncates the foreign data sources  
that the passed foreign tables specify, based on those information.  
For example, postgres_fdw constructs TRUNCATE command using them  
and issues it to the foreign server.  
  
For performance, TRUNCATE command invokes the FDW routine for  
TRUNCATE once per foreign server that foreign tables to truncate belong to.  
  
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao  
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao  
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com  
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com  

commit   : 50e17ad281b8d1c1b410c9833955bc80fbad4078    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 8 Apr 2021 23:51:22 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 8 Apr 2021 23:51:22 +1200    

ScalarArrayOpExprs with "useOr=true" and a set of Consts on the righthand  
side have traditionally been evaluated by using a linear search over the  
array.  When these arrays contain large numbers of elements then this  
linear search could become a significant part of execution time.  
  
Here we add a new method of evaluating ScalarArrayOpExpr expressions to  
allow them to be evaluated by first building a hash table containing each  
element, then on subsequent evaluations, we just probe that hash table to  
determine if there is a match.  
  
The planner is in charge of determining when this optimization is possible  
and it enables it by setting hashfuncid in the ScalarArrayOpExpr.  The  
executor will only perform the hash table evaluation when the hashfuncid  
is set.  
  
This means that not all cases are optimized. For example CHECK constraints  
containing an IN clause won't go through the planner, so won't get the  
hashfuncid set.  We could maybe do something about that at some later  
date.  The reason we're not doing it now is from fear that we may slow  
down cases where the expression is evaluated only once.  Those cases can  
be common, for example, a single row INSERT to a table with a CHECK  
constraint containing an IN clause.  
  
In the planner, we enable this when there are suitable hash functions for  
the ScalarArrayOpExpr's operator and only when there is at least  
MIN_ARRAY_SIZE_FOR_HASHED_SAOP elements in the array.  The threshold is  
currently set to 9.  
  
Author: James Coleman, David Rowley  
Reviewed-by: David Rowley, Tomas Vondra, Heikki Linnakangas  
Discussion: https://postgr.es/m/CAAaqYe8x62+=wn0zvNKCj55tPpg-JBHzhZFFc6ANovdqFw7-dA@mail.gmail.com  

commit   : 1d257577e08d3e598011d6850fd1025858de8c8c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 23:03:43 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 23:03:43 +1200    

Introduce a new GUC recovery_prefetch, disabled by default.  When  
enabled, look ahead in the WAL and try to initiate asynchronous reading  
of referenced data blocks that are not yet cached in our buffer pool.  
For now, this is done with posix_fadvise(), which has several caveats.  
Better mechanisms will follow in later work on the I/O subsystem.  
  
The GUC maintenance_io_concurrency is used to limit the number of  
concurrent I/Os we allow ourselves to initiate, based on pessimistic  
heuristics used to infer that I/Os have begun and completed.  
  
The GUC wal_decode_buffer_size is used to limit the maximum distance we  
are prepared to read ahead in the WAL to find uncached blocks.  
  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (parts)  
Reviewed-by: Andres Freund <andres@anarazel.de> (parts)  
Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (parts)  
Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com>  
Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com>  
Tested-by: Dmitry Dolgov <9erthalion6@gmail.com>  
Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com  

commit   : f003d9f8721b3249e4aec8a1946034579d40d42c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 23:03:34 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 23:03:34 +1200    

Teach xlogreader.c to decode its output into a circular buffer, to  
support optimizations based on looking ahead.  
  
 * XLogReadRecord() works as before, consuming records one by one, and  
   allowing them to be examined via the traditional XLogRecGetXXX()  
   macros.  
  
 * An alternative new interface XLogNextRecord() is added that returns  
   pointers to DecodedXLogRecord structs that can be examined directly.  
  
 * XLogReadAhead() provides a second cursor that lets you see  
   further ahead, as long as data is available and there is enough space  
   in the decoding buffer.  This returns DecodedXLogRecord pointers to the  
   caller, but also adds them to a queue of records that will later be  
   consumed by XLogNextRecord()/XLogReadRecord().  
  
The buffer's size is controlled with wal_decode_buffer_size.  The buffer  
could potentially be placed into shared memory, for future projects.  
Large records that don't fit in the circular buffer are called  
"oversized" and allocated separately with palloc().  
  
Discussion: https://postgr.es/m/CA+hUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq=AovOddfHpA@mail.gmail.com  

commit   : 323cbe7c7ddcf18aaf24b7f6d682a45a61d4e31b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 23:03:23 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 23:03:23 +1200    

Previously, the XLogReader module would fetch new input data using a  
callback function.  Redesign the interface so that it tells the caller  
to insert more data with a special return value instead.  This API suits  
later patches for prefetching, encryption and maybe other future  
projects that would otherwise require continually extending the callback  
interface.  
  
As incidental cleanup work, move global variables readOff, readLen and  
readSegNo inside XlogReaderState.  
  
Author: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>  
Author: Heikki Linnakangas <hlinnaka@iki.fi> (parts of earlier version)  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Reviewed-by: Takashi Menjo <takashi.menjo@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20190418.210257.43726183.horiguchi.kyotaro%40lab.ntt.co.jp  

commit   : 5ac9c4307337313bedeafc21dbbab93ba809241c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 8 Apr 2021 22:35:48 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 8 Apr 2021 22:35:48 +1200    

There was some code in gen_prune_steps_from_opexps that needlessly  
checked a list was not empty when it clearly had to contain at least one  
item. This prompted a further cleanup operation in partprune.c.  
  
Additionally, the previous code could end up adding additional needless  
INTERSECT steps. However, those do not appear to be able to cause any  
misbehavior.  
  
gen_prune_steps_from_opexps is now no longer in charge of generating  
combine pruning steps. Instead, gen_partprune_steps_internal, which  
already does some combine step creation has been given the sole  
responsibility of generating all combine steps. This means that when  
we recursively call gen_partprune_steps_internal, since it always now adds  
a combine step when it produces multiple steps, we can just pay attention  
to the final step returned.  
  
In passing, do quite a bit of work on the comments to try to more clearly  
explain the role of both gen_partprune_steps_internal and  
gen_prune_steps_from_opexps. This is fairly complex code so some extra  
effort to give any new readers an overview of how things work seems like  
a good idea.  
  
Author: Amit Langote  
Reported-by: Andy Fan  
Reviewed-by: Kyotaro Horiguchi, Andy Fan, Ryan Lambert, David Rowley  
Discussion: https://postgr.es/m/CAKU4AWqWoVii+bRTeBQmeVW+PznkdO8DfbwqNsu9Gj4ubt9A6w@mail.gmail.com  

commit   : 7e3c54168d9ec058cb3c9d47f8105b1d32dc8ceb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Apr 2021 12:20:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Apr 2021 12:20:11 +0200    

Apparently, an unrelated patch introduced some variation on the build  
farm.  
  
Reported-by: Magnus Hagander <magnus@hagander.net>  

commit   : aaf043257205ec523f1ba09a3856464d17cf2281    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 8 Apr 2021 11:32:14 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 8 Apr 2021 11:32:14 +0200    

This adds a function, pg_wait_for_backend_termination(), and a new  
timeout argument to pg_terminate_backend(), which will wait for the  
backend to actually terminate (with or without signaling it to do so  
depending on which function is called). The default behaviour of  
pg_terminate_backend() remains being timeout=0 which does not waiting.  
For pg_wait_for_backend_termination() the default wait is 5 seconds.  
  
Author: Bharath Rupireddy  
Reviewed-By: Fujii Masao, David Johnston, Muhammad Usama,  
             Hou Zhijie, Magnus Hagander  
Discussion: https://postgr.es/m/CALj2ACUBpunmyhYZw-kXCYs5NM+h6oG_7Df_Tn4mLmmUQifkqA@mail.gmail.com  

commit   : fb310f17812e7321599845a29af2f36c7f1191c3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Apr 2021 10:51:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Apr 2021 10:51:26 +0200    

Update src/tutorial/basics.source to match.  
  
Author: Jürgen Purtz <juergen@purtz.de>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: "David G. Johnston" <david.g.johnston@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/158996922318.7035.10603922579567326239@wrigleys.postgresql.org  

commit   : 6b4d23feef6e334fb85af077f2857f62ab781848    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 8 Apr 2021 10:23:10 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 8 Apr 2021 10:23:10 +0200    

Changing pg_stat_statements.track between 'all' and 'top' would control  
if pg_stat_statements tracked just top level statements or also  
statements inside functions, but when tracking all it would not  
differentiate between the two. Being table to differentiate this is  
useful both to track where the actual query is coming from, and to see  
if there are differences in executions between the two.  
  
To do this, add a boolean to the hash key indicating if the statement  
was top level or not.  
  
Experience from the pg_stat_kcache module shows that in at least some  
"reasonable worloads" only <5% of the queries show up both top level and  
nested. Based on this, admittedly small, dataset, this patch does not  
try to de-duplicate those query *texts*, and will just store one copy  
for the top level and one for the nested.  
  
Author: Julien Rohaud  
Reviewed-By: Magnus Hagander, Masahiro Ikeda  
Discussion: https://postgr.es/m/20201202040516.GA43757@nol  

commit   : 2e0e0666790e48cec716d4947f89d067ef53490c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Apr 2021 08:28:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Apr 2021 08:28:03 +0200    

commit   : 2f27f8c511494cca9e0e9a4eeeb102fa9f193002    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 17:48:37 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Apr 2021 17:48:37 +1200    

If you know the ID of a buffer that recently held a block that you would  
like to pin, this function can be used check if it's still there.  It  
can be used to avoid a second lookup in the buffer mapping table after  
PrefetchBuffer() reports a cache hit.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA+hUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq=AovOddfHpA@mail.gmail.com  

commit   : 0827e8af70f4653ba17ed773f123a60eadd9f9c9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Apr 2021 01:19:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Apr 2021 01:19:36 -0400    

Previously, autovacuum would completely ignore partitioned tables, which  
is not good regarding analyze -- failing to analyze those tables means  
poor plans may be chosen.  Make autovacuum aware of those tables by  
propagating "changes since analyze" counts from the leaf partitions up  
the partitioning hierarchy.  
  
This also introduces necessary reloptions support for partitioned tables  
(autovacuum_enabled, autovacuum_analyze_scale_factor,  
autovacuum_analyze_threshold).  It's unclear how best to document this  
aspect.  
  
Author: Yuzuko Hosoya <yuzukohosoya@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/CAKkQ508_PwVgwJyBY=0Lmkz90j8CmWNPUxgHvCUwGhMrouz6UA@mail.gmail.com  

commit   : b3ee4c503872f3d0a5d6a7cbde48815f555af15b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 7 Apr 2021 22:00:01 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 7 Apr 2021 22:00:01 -0700    

It's far from clear that this is the right approach - but a good  
portion of the buildfarm has been red for a few hours, on the last day  
of the CF. And this fixes at least the obvious crash. So let's go with  
that for now.  
  
Discussion: https://postgr.es/m/20210407225806.majgznh4lk34hjvu%40alap3.anarazel.de  

commit   : 8ffb003591ff02f59d92c36a5791307881863146    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 8 Apr 2021 10:24:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 8 Apr 2021 10:24:00 +0530    

Author: Tatsuro Yamada  
Discussion: https://postgr.es/m/7c166a60-2808-6b89-9524-feefc6233748@nttcom.co.jp_1  

commit   : 4131f755d548f74eba56285dc674f1f26e4ed6b4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Apr 2021 00:46:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Apr 2021 00:46:14 -0400    

When working on a scan with only a catalog snapshot, we may not have an  
ActiveSnapshot set.  If we were to come across a detached partition,  
that would cause a crash.  Fix by only ignoring detached partitions when  
there's an active snapshot.  

commit   : a3027e1e7f3d3a107ecd72d3b4d6333ea2aab6a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 23:02:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 23:02:16 -0400    

When dealing with overloaded function or operator names, having  
to look through a long list of matches is tedious.  Let's extend  
these commands to allow specification of (input) argument types  
to let such results be trimmed down.  Each additional argument  
is treated the same as the pattern argument of \dT and matched  
against the appropriate argument's type name.  
  
While at it, fix \dT (and these new options) to recognize the  
usual notation of "foo[]" for "the array type over foo", and  
to handle the special abbreviations allowed by the backend  
grammar, such as "int" for "integer".  
  
Greg Sabino Mullane, revised rather significantly by me  
  
Discussion: https://postgr.es/m/CAKAnmmLF9Hhu02N+s7uAyLc5J1xZReg72HQUoiKhNiJV3_jACQ@mail.gmail.com  

commit   : f57a2f5e03054ade221e554c70e628e1ffae1b66    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 22:30:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 22:30:30 -0400    

This also adjusts the printf format for query id used by log_line_prefix  
(%Q).  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210408005402.GG24239@momjian.us  
  
Author: Julien Rouhaud, Bruce Momjian  

commit   : 5100010ee4d5c8ef46619dbd1d17090c627e6d0a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Apr 2021 16:14:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Apr 2021 16:14:54 -0700    

VACUUM has never needed to call ambulkdelete() for each index in cases  
where there are precisely zero TIDs in its dead_tuples array by the end  
of its first pass over the heap (also its only pass over the heap in  
this scenario).  Index vacuuming is simply not required when this  
happens.  Index cleanup will still go ahead, but in practice most calls  
to amvacuumcleanup() are usually no-ops when there were zero preceding  
ambulkdelete() calls.  In short, VACUUM has generally managed to avoid  
index scans when there were clearly no index tuples to delete from  
indexes.  But cases with _close to_ no index tuples to delete were  
another matter -- a round of ambulkdelete() calls took place (one per  
index), each of which performed a full index scan.  
  
VACUUM now behaves just as if there were zero index tuples to delete in  
cases where there are in fact "virtually zero" such tuples.  That is, it  
can now bypass index vacuuming and heap vacuuming as an optimization  
(though not index cleanup).  Whether or not VACUUM bypasses indexes is  
determined dynamically, based on the just-observed number of heap pages  
in the table that have one or more LP_DEAD items (LP_DEAD items in heap  
pages have a 1:1 correspondence with index tuples that still need to be  
deleted from each index in the worst case).  
  
We only skip index vacuuming when 2% or less of the table's pages have  
one or more LP_DEAD items -- bypassing index vacuuming as an  
optimization must not noticeably impede setting bits in the visibility  
map.  As a further condition, the dead_tuples array (i.e. VACUUM's array  
of LP_DEAD item TIDs) must not exceed 32MB at the point that the first  
pass over the heap finishes, which is also when the decision to bypass  
is made.  (The VACUUM must also have been able to fit all TIDs in its  
maintenance_work_mem-bound dead_tuples space, though with a default  
maintenance_work_mem setting it can't matter.)  
  
This avoids surprising jumps in the duration and overhead of routine  
vacuuming with workloads where successive VACUUM operations consistently  
have almost zero dead index tuples.  The number of LP_DEAD items may  
well accumulate over multiple VACUUM operations, before finally the  
threshold is crossed and VACUUM performs conventional index vacuuming.  
Even then, the optimization will have avoided a great deal of largely  
unnecessary index vacuuming.  
  
In the future we may teach VACUUM to skip index vacuuming on a per-index  
basis, using a much more sophisticated approach.  For now we only  
consider the extreme cases, where we can be quite confident that index  
vacuuming just isn't worth it using simple heuristics.  
  
Also log information about how many heap pages have one or more LP_DEAD  
items when autovacuum logging is enabled.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com  
Discussion: https://postgr.es/m/CAH2-WzmkebqPd4MVGuPTOS9bMFvp9MDs5cRTCOsv1rQJ3jCbXw@mail.gmail.com  

commit   : bc70728693bc2d28db7125e7a24d78ad7612f58c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 18:14:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 18:14:36 -0400    

The query originally used was too simple, cause explain_filter() to be  
unable to remove JIT output text.  
  
Reported-by: Tom Lane  
  
Author: Julien Rouhaud  

commit   : c7578fa64019f27edc31261ea49066a4b2569a6c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 8 Apr 2021 06:55:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 8 Apr 2021 06:55:00 +0900    

The truncation of the log file, that this set of tests relies on to make  
sure that a connection attempt matches with its expected backend log  
pattern, fails, as reported by buildfarm member fairywren.  Instead of a  
truncation, do a rotation of the log file and restart the node.  This  
will ensure that the connection attempt data is unique for each test.  
  
Discussion: https://postgr.es/m/YG05nCI8x8B+Ad3G@paquier.xyz  

commit   : e717a9a18b2e34c9c40e5259ad4d31cd7e420750    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 21:30:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 21:30:08 +0200    

This adds support for writing CREATE FUNCTION and CREATE PROCEDURE  
statements for language SQL with a function body that conforms to the  
SQL standard and is portable to other implementations.  
  
Instead of the PostgreSQL-specific AS $$ string literal $$ syntax,  
this allows writing out the SQL statements making up the body  
unquoted, either as a single statement:  
  
    CREATE FUNCTION add(a integer, b integer) RETURNS integer  
        LANGUAGE SQL  
        RETURN a + b;  
  
or as a block  
  
    CREATE PROCEDURE insert_data(a integer, b integer)  
    LANGUAGE SQL  
    BEGIN ATOMIC  
      INSERT INTO tbl VALUES (a);  
      INSERT INTO tbl VALUES (b);  
    END;  
  
The function body is parsed at function definition time and stored as  
expression nodes in a new pg_proc column prosqlbody.  So at run time,  
no further parsing is required.  
  
However, this form does not support polymorphic arguments, because  
there is no more parse analysis done at call time.  
  
Dependencies between the function and the objects it uses are fully  
tracked.  
  
A new RETURN statement is introduced.  This can only be used inside  
function bodies.  Internally, it is treated much like a SELECT  
statement.  
  
psql needs some new intelligence to keep track of function body  
boundaries so that it doesn't send off statements when it sees  
semicolons that are inside a function body.  
  
Tested-by: Jaime Casanova <jcasanov@systemguards.com.ec>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com  

commit   : 1e55e7d1755cefbb44982fbacc7da461fa8684e6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Apr 2021 12:37:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Apr 2021 12:37:45 -0700    

Add a failsafe mechanism that is triggered by VACUUM when it notices  
that the table's relfrozenxid and/or relminmxid are dangerously far in  
the past.  VACUUM checks the age of the table dynamically, at regular  
intervals.  
  
When the failsafe triggers, VACUUM takes extraordinary measures to  
finish as quickly as possible so that relfrozenxid and/or relminmxid can  
be advanced.  VACUUM will stop applying any cost-based delay that may be  
in effect.  VACUUM will also bypass any further index vacuuming and heap  
vacuuming -- it only completes whatever remaining pruning and freezing  
is required.  Bypassing index/heap vacuuming is enabled by commit  
8523492d, which made it possible to dynamically trigger the mechanism  
already used within VACUUM when it is run with INDEX_CLEANUP off.  
  
It is expected that the failsafe will almost always trigger within an  
autovacuum to prevent wraparound, long after the autovacuum began.  
However, the failsafe mechanism can trigger in any VACUUM operation.  
Even in a non-aggressive VACUUM, where we're likely to not advance  
relfrozenxid, it still seems like a good idea to finish off remaining  
pruning and freezing.   An aggressive/anti-wraparound VACUUM will be  
launched immediately afterwards.  Note that the anti-wraparound VACUUM  
that follows will itself trigger the failsafe, usually before it even  
begins its first (and only) pass over the heap.  
  
The failsafe is controlled by two new GUCs: vacuum_failsafe_age, and  
vacuum_multixact_failsafe_age.  There are no equivalent reloptions,  
since that isn't expected to be useful.  The GUCs have rather high  
defaults (both default to 1.6 billion), and are expected to generally  
only be used to make the failsafe trigger sooner/more frequently.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com  
Discussion: https://postgr.es/m/CAH2-WzmgH3ySGYeC-m-eOBsa2=sDwa292-CFghV4rESYo39FsQ@mail.gmail.com  

commit   : 4f0b0966c866ae9f0e15d7cc73ccf7ce4e1af84b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 14:03:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 14:03:56 -0400    

Use the in-core query id computation for pg_stat_activity,  
log_line_prefix, and EXPLAIN VERBOSE.  
  
Similar to other fields in pg_stat_activity, only the queryid from the  
top level statements are exposed, and if the backends status isn't  
active then the queryid from the last executed statements is displayed.  
  
Add a %Q placeholder to include the queryid in log_line_prefix, which  
will also only expose top level statements.  
  
For EXPLAIN VERBOSE, if a query identifier has been computed, either by  
enabling compute_query_id or using a third-party module, display it.  
  
Bump catalog version.  
  
Discussion: https://postgr.es/m/20210407125726.tkvjdbw76hxnpwfi@nol  
  
Author: Julien Rouhaud  
  
Reviewed-by: Alvaro Herrera, Nitin Jadhav, Zhihong Yu  

commit   : ec7ffb8096e8eb90f4c9230f7ba9487f0abe1a9f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Apr 2021 13:28:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Apr 2021 13:28:35 -0400    

First, don't perform database access while holding a buffer lock.  
When checking a heap, we can validate that TOAST pointers are sane by  
performing a scan on the TOAST index and looking up the chunks that  
correspond to each value ID that appears in a TOAST poiner in the main  
table. But, to do that while holding a buffer lock at least risks  
causing other backends to wait uninterruptibly, and probably can cause  
undetected and uninterruptible deadlocks.  So, instead, make a list of  
checks to perform while holding the lock, and then perform the checks  
after releasing it.  
  
Second, adjust things so that we don't try to follow TOAST pointers  
for tuples that are already eligible to be pruned. The TOAST tuples  
become eligible for pruning at the same time that the main tuple does,  
so trying to check them may lead to spurious reports of corruption,  
as observed in the buildfarm. The necessary infrastructure to decide  
whether or not the tuple being checked is prunable was added by  
commit 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0, but it wasn't  
actually used for its intended purpose prior to this patch.  
  
Mark Dilger, adjusted by me to avoid a memory leak.  
  
Discussion: http://postgr.es/m/AC5479E4-6321-473D-AC92-5EC36299FBC2@enterprisedb.com  

commit   : 5fd9dfa5f50e4906c35133a414ebec5b6d518493    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 13:06:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Apr 2021 13:06:47 -0400    

Add compute_query_id GUC to control whether a query identifier should be  
computed by the core (off by default).  It's thefore now possible to  
disable core queryid computation and use pg_stat_statements with a  
different algorithm to compute the query identifier by using a  
third-party module.  
  
To ensure that a single source of query identifier can be used and is  
well defined, modules that calculate a query identifier should throw an  
error if compute_query_id specified to compute a query id and if a query  
idenfitier was already calculated.  
  
Discussion: https://postgr.es/m/20210407125726.tkvjdbw76hxnpwfi@nol  
  
Author: Julien Rouhaud  
  
Reviewed-by: Alvaro Herrera, Nitin Jadhav, Zhihong Yu  

commit   : a282ee68a070a8adc6e6d45e8e643769c587ecc3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 12:50:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 12:50:17 -0400    

This fails on older OpenSSL versions that lack channel binding  
support.  Since that feature is not essential to this test case,  
just remove it, instead of complicating matters.  Per buildfarm.  
  
Jacob Champion  
  
Discussion: https://postgr.es/m/fa8dbbb58c20b1d1adf0082769f80d5466eaf485.camel@vmware.com  

commit   : 0d46771eaaf77ad08555cf34e421234d5943edfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 12:21:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 12:21:54 -0400    

Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqEcawatEaUh1uTbZMEZTJeLzbroRTz9_X9Z5CFjTWJkhw@mail.gmail.com  

commit   : 4573f6a9af6e232ba073392716a051ae2017d1e9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Apr 2021 12:11:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Apr 2021 12:11:44 -0400    

Commit 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0 resulted in the same  
xmin and xmax bounds checking being performed in both check_tuple()  
and check_tuple_visibility(). Remove the duplication.  
  
While at it, adjust some code comments that were overlooked in that  
commit.  
  
Mark Dilger  
  
Discussion: http://postgr.es/m/AC5479E4-6321-473D-AC92-5EC36299FBC2@enterprisedb.com  

commit   : 3c3b8a4b26891892bccf3d220580a7f413c0b9ca    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Apr 2021 08:47:15 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Apr 2021 08:47:15 -0700    

Teach VACUUM to truncate the line pointer array of each heap page when a  
contiguous group of LP_UNUSED line pointers appear at the end of the  
array -- these unused and unreferenced items are excluded.  This process  
occurs during VACUUM's second pass over the heap, right after LP_DEAD  
line pointers on the page (those encountered/pruned during the first  
pass) are marked LP_UNUSED.  
  
Truncation avoids line pointer bloat with certain workloads,  
particularly those involving continual range DELETEs and bulk INSERTs  
against the same table.  
  
Also harden heapam code to check for an out-of-range page offset number  
in places where we weren't already doing so.  
  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-By: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAEze2WjgaQc55Y5f5CQd3L=eS5CZcff2Obxp=O6pto8-f0hC4w@mail.gmail.com  
Discussion: https://postgr.es/m/CAH2-Wzn6a64PJM1Ggzm=uvx2otsopJMhFQj_g1rAj4GWr3ZSzw@mail.gmail.com  

commit   : 3db826bd55cd1df0dd8c3d811f8e5b936d7ba1e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 11:22:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Apr 2021 11:22:22 -0400    

Formerly we were pretty lax about what a custom GUC's name could  
be; so long as it had at least one dot in it, we'd take it.  
However, corner cases such as dashes or equal signs in the name  
would cause various bits of functionality to misbehave.  Rather  
than trying to make the world perfectly safe for that, let's  
just require that custom names look like "identifier.identifier",  
where "identifier" means something that scan.l would accept  
without double quotes.  
  
Along the way, this patch refactors things slightly in guc.c  
so that find_option() is responsible for reporting GUC-not-found  
cases, allowing removal of duplicative code from its callers.  
  
Per report from Hubert Depesz Lubaczewski.  No back-patch,  
since the consequences of the problem don't seem to warrant  
changing behavior in stable branches.  
  
Discussion: https://postgr.es/m/951335.1612910077@sss.pgh.pa.us  

commit   : 23607a8156d595522c232ff3933d77041d3adaa1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 7 Apr 2021 15:58:35 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 7 Apr 2021 15:58:35 +0200    

The code in bringetbitmap() simply added the whole matching page range  
to the TID bitmap, as determined by pages_per_range, even if some of the  
pages were beyond the end of the heap. The query then might fail with  
an error like this:  
  
  ERROR:  could not open file "base/20176/20228.2" (target block  
          262144): previous segment is only 131021 blocks  
  
In this case, the relation has 262093 pages (131072 and 131021 pages),  
but we're trying to acess block 262144, i.e. first block of the 3rd  
segment. At that point _mdfd_getseg() notices the preceding segment is  
incomplete, and fails.  
  
Hitting this in practice is rather unlikely, because:  
  
* Most indexes use power-of-two ranges, so segments and page ranges  
  align perfectly (segment end is also a page range end).  
  
* The table size has to be just right, with the last segment being  
  almost full - less than one page range from full segment, so that the  
  last page range actually crosses the segment boundary.  
  
* Prefetch has to be enabled. The regular page access checks that  
  pages are not beyond heap end, but prefetch does not. On older  
  releases (before 12) the execution stops after hitting the first  
  non-existent page, so the prefetch distance has to be sufficient  
  to reach the first page in the next segment to trigger the issue.  
  Since 12 it's enough to just have prefetch enabled, the prefetch  
  distance does not matter.  
  
Fixed by not adding non-existent pages to the TID bitmap. Backpatch  
all the way back to 9.6 (BRIN indexes were introduced in 9.5, but that  
release is EOL).  
  
Backpatch-through: 9.6  

commit   : 5c55dc8b47338e72a4e598c155d2048d756fd10e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 15:11:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 15:11:41 +0200    

By default, have libpq set the TLS extension "Server Name Indication" (SNI).  
  
This allows an SNI-aware SSL proxy to route connections.  (This  
requires a proxy that is aware of the PostgreSQL protocol, not just  
any SSL proxy.)  
  
In the future, this could also allow the server to use different SSL  
certificates for different host specifications.  (That would require  
new server functionality.  This would be the client-side functionality  
for that.)  
  
Since SNI makes the host name appear in cleartext in the network  
traffic, this might be undesirable in some cases.  Therefore, also add  
a libpq connection option "sslsni" to turn it off.  
  
Discussion: https://www.postgresql.org/message-id/flat/7289d5eb-62a5-a732-c3b9-438cee2cb709%40enterprisedb.com  

commit   : c1968426ba3de1fe37848863e35fff30261bf941    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 7 Apr 2021 14:21:19 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 7 Apr 2021 14:21:19 +0200    

The previous implementation (from 9afffcb833) had an unnecessary check  
on the boundaries of the enum which trigtered compile warnings. To clean  
it up, move the pre-existing static assert to a central location and  
call that.  
  
Reported-By: Erik Rijkers  
Reviewed-By: Michael Paquier  
Discussion: https://postgr.es/m/1056399262.13159.1617793249020@webmailclassic.xs4all.nl  

commit   : 4560e0acdafd57f3ba109b98e15ac047798d960c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 13:52:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 13:52:26 +0200    

Discussion: https://www.postgresql.org/message-id/flat/161626776179.652.11944895442156126506%40wrigleys.postgresql.org  

commit   : d92b1cdbab408d8f1299257125c9ae375f3ca644    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Apr 2021 14:33:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Apr 2021 14:33:21 +0300    

This reverts commit 9f984ba6d23dc6eecebf479ab1d3f2e550a4e9be.  
  
It was making the buildfarm unhappy, apparently setting client_min_messages  
in a regression test produces different output if log_statement='all'.  
Another issue is that I now suspect the bit sortsupport function was in  
fact not correct to call byteacmp(). Revert to investigate both of those  
issues.  

commit   : 9f984ba6d23dc6eecebf479ab1d3f2e550a4e9be    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Apr 2021 13:22:05 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Apr 2021 13:22:05 +0300    

Commit 16fa9b2b30 introduced a faster way to build GiST indexes, by  
sorting all the data. This commit adds the sortsupport functions needed  
to make use of that feature for btree_gist.  
  
Author: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/2F3F7265-0D22-44DB-AD71-8554C743D943@yandex-team.ru  

commit   : dd13ad9d39a1ba41cf329b6fe408b49be57c7b88    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 07:49:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 07:49:27 +0200    

Documentation and comments in code and tests have been using the terms  
sensitive/insensitive cursor incorrectly relative to the SQL standard.  
(Cursor sensitivity is only relevant for changes made in the same  
transaction as the cursor, not for concurrent changes in other  
sessions.)  Moreover, some of the behavior of PostgreSQL is incorrect  
according to the SQL standard, confusing the issue further.  (WHERE  
CURRENT OF changes are not visible in insensitive cursors, but they  
should be.)  
  
This change corrects the terminology and removes the claim that  
sensitive cursors are supported.  It also adds a test case that checks  
the insensitive behavior in a "correct" way, using a change command  
not using WHERE CURRENT OF.  Finally, it adds the ASENSITIVE cursor  
option to select the default asensitive behavior, per SQL standard.  
  
There are no changes to cursor behavior in this patch.  
  
Discussion: https://www.postgresql.org/message-id/flat/96ee8b30-9889-9e1b-b053-90e10c050e85%40enterprisedb.com  

commit   : 0b5e8245283eef67e88fb5380836cdc2c743d848    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 07:37:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Apr 2021 07:37:30 +0200    

The previous wording contained a superfluous comma.  Adjust phrasing  
for grammatical correctness and clarity.  

commit   : 4c0239cb7a7775e3183cb575e62703d71bf3302d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Apr 2021 14:35:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Apr 2021 14:35:26 +0900    

Bloom, GIN, GiST and SP-GiST rely on PageInit() to initialize the  
contents of a page, and this routine fills entirely a page with zeros  
for a size of BLCKSZ, including the special space.  Those index AMs have  
been using an extra memset() call to fill with zeros the special page  
space, or even the whole page, which is not necessary as PageInit()  
already does this work, so let's remove them.  GiST was not doing this  
extra call, but has commented out a system call that did so since  
6236991.  
  
While on it, remove one MAXALIGN() for SP-GiST as PageInit() takes care  
of that.  This makes the whole page initialization logic more consistent  
across all index AMs.  
  
Author: Bharath Rupireddy  
Reviewed-by: Vignesh C, Mahendra Singh Thalor  
Discussion: https://postgr.es/m/CALj2ACViOo2qyaPT7krWm4LRyRTw9kOXt+g6PfNmYuGA=YHj9A@mail.gmail.com  

commit   : 9afffcb833d3c5e59a328a2af674fac7e7334fc1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Apr 2021 10:16:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Apr 2021 10:16:39 +0900    

The "authenticated identity" is the string used by an authentication  
method to identify a particular user.  In many common cases, this is the  
same as the PostgreSQL username, but for some third-party authentication  
methods, the identifier in use may be shortened or otherwise translated  
(e.g. through pg_ident user mappings) before the server stores it.  
  
To help administrators see who has actually interacted with the system,  
this commit adds the capability to store the original identity when  
authentication succeeds within the backend's Port, and generates a log  
entry when log_connections is enabled.  The log entries generated look  
something like this (where a local user named "foouser" is connecting to  
the database as the database user called "admin"):  
  
  LOG:  connection received: host=[local]  
  LOG:  connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88)  
  LOG:  connection authorized: user=admin database=postgres application_name=psql  
  
Port->authn_id is set according to the authentication method:  
  
  bsd: the PostgreSQL username (aka the local username)  
  cert: the client's Subject DN  
  gss: the user principal  
  ident: the remote username  
  ldap: the final bind DN  
  pam: the PostgreSQL username (aka PAM username)  
  password (and all pw-challenge methods): the PostgreSQL username  
  peer: the peer's pw_name  
  radius: the PostgreSQL username (aka the RADIUS username)  
  sspi: either the down-level (SAM-compatible) logon name, if  
        compat_realm=1, or the User Principal Name if compat_realm=0  
  
The trust auth method does not set an authenticated identity.  Neither  
does clientcert=verify-full.  
  
Port->authn_id could be used for other purposes, like a superuser-only  
extra column in pg_stat_activity, but this is left as future work.  
  
PostgresNode::connect_{ok,fails}() have been modified to let tests check  
the backend log files for required or prohibited patterns, using the  
new log_like and log_unlike parameters.  This uses a method based on a  
truncation of the existing server log file, like issues_sql_like().  
Tests are added to the ldap, kerberos, authentication and SSL test  
suites.  
  
Author: Jacob Champion  
Reviewed-by: Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com  

commit   : 8ee9b662daa6d51b54d21ec274f22a218462ad2d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Apr 2021 07:42:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Apr 2021 07:42:36 +0900    

The buildfarm members "drongo" and "fairywren" reported that  
the regression test (024_archive_recovery.pl) added by commit 9de9294b0c  
failed. The cause of this failure is that the test calls $node->init()  
without "allows_streaming => 1" and which doesn't add pg_hba.conf  
entry for TCP/IP connection from pg_basebackup.  
This commit fixes the issue by specifying "allows_streaming => 1"  
when calling $node->init().  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/3cc3909d-f779-7a74-c201-f1f7f62c7497@oss.nttdata.com  

commit   : a1115fa0782378a8238045d238ae70cac36be8ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 18:13:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 18:13:05 -0400    

Delay creation of the projections for INSERT and UPDATE tuples  
until they're needed.  This saves a pretty fair amount of work  
when only some of the partitions are actually touched.  
  
The logic associated with identifying junk columns in UPDATE/DELETE  
is moved to another loop, allowing removal of one loop over the  
target relations; but it didn't actually change at all.  
  
Extracted from a larger patch, which seemed to me to be too messy  
to push in one commit.  
  
Amit Langote, reviewed at different times by Heikki Linnakangas and  
myself  
  
Discussion: https://postgr.es/m/CA+HiwqG7ZruBmmih3wPsBZ4s0H2EhywrnXEduckY5Hr3fWzPWA@mail.gmail.com  

commit   : 3b82d990ab784881153c0f127e4c1211e9b6065c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 7 Apr 2021 09:51:33 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 7 Apr 2021 09:51:33 +1200    

DEBUG was already defined by the MSVC toolchain for "Debug" builds. On  
these systems the unconditional #define DEBUG was causing a 'DEBUG': macro  
redefinition warning.  
  
Here we rename DEBUG to DEBUG_OUPUT and also get rid of the #define which  
defined this constant.  This appears to have been left in the code by  
mistake.  
  
Discussion: https://postgr.es/m/CAApHDvqTTgDm38s4HRj03nhzhzQ1oMOj-RXFUB1pE6Bj07jyuQ@mail.gmail.com  

commit   : c5b7ba4e67aeb5d6f824b74f94114d99ed6e42b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 15:56:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 15:56:55 -0400    

Arrange to do some things on-demand, rather than immediately during  
executor startup, because there's a fair chance of never having to do  
them at all:  
  
* Don't open result relations' indexes until needed.  
  
* Don't initialize partition tuple routing, nor the child-to-root  
tuple conversion map, until needed.  
  
This wins in UPDATEs on partitioned tables when only some of the  
partitions will actually receive updates; with larger partition  
counts the savings is quite noticeable.  Also, we can remove some  
sketchy heuristics in ExecInitModifyTable about whether to set up  
tuple routing.  
  
Also, remove execPartition.c's private hash table tracking which  
partitions were already opened by the ModifyTable node.  Instead  
use the hash added to ModifyTable itself by commit 86dc90056.  
  
To allow lazy computation of the conversion maps, we now set  
ri_RootResultRelInfo in all child ResultRelInfos.  We formerly set it  
only in some, not terribly well-defined, cases.  This has user-visible  
side effects in that now more error messages refer to the root  
relation instead of some partition (and provide error data in the  
root's column order, too).  It looks to me like this is a strict  
improvement in consistency, so I don't have a problem with the  
output changes visible in this commit.  
  
Extracted from a larger patch, which seemed to me to be too messy  
to push in one commit.  
  
Amit Langote, reviewed at different times by Heikki Linnakangas and  
myself  
  
Discussion: https://postgr.es/m/CA+HiwqG7ZruBmmih3wPsBZ4s0H2EhywrnXEduckY5Hr3fWzPWA@mail.gmail.com  

commit   : a3740c48eb2f91663c7c06c948dfcfb6493d2588    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Apr 2021 02:32:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Apr 2021 02:32:10 +0900    

Commit f49bcd4ef3 disallowed postgres_fdw to import table partitions.  
Because all data can be accessed through the partitioned table which  
is the root of the partitioning hierarchy, importing only partitioned  
table should allow access to all the data without creating extra objects.  
This is a reasonable default when importing a whole schema. But there  
may be the case where users want to explicitly import one of  
a partitioned tables' partitions.  
  
For that use case, this commit allows postgres_fdw to import tables or  
foreign tables which are partitions of some other table only when they  
are explicitly specified in LIMIT TO clause.  It doesn't change  
the behavior that any partitions not specified in LIMIT TO are  
automatically excluded in IMPORT FOREIGN SCHEMA command.  
  
Author: Matthias van de Meent  
Reviewed-by: Bernd Helmle, Amit Langote, Michael Paquier, Fujii Masao  
Discussion: https://postgr.es/m/CAEze2Whwg4i=mzApMe+PXxCEfgoZmHGqdqQFW7J4bmj_5p6t1A@mail.gmail.com  

commit   : 90c885cdab8bc5a5f12a243774fa0db51002a2fd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 6 Apr 2021 09:24:50 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 6 Apr 2021 09:24:50 -0700    

Snapshot caching, introduced in 623a9ba79b, did not increment  
xactCompletionCount during subtransaction abort. That could lead to an older  
snapshot being reused. That is, at least as far as I can see, not a  
correctness issue (for MVCC snapshots there's no difference between "in  
progress" and "aborted"). The only difference between the old and new  
snapshots would be a newer ->xmax.  
  
While HeapTupleSatisfiesMVCC makes the same visibility determination, reusing  
the old snapshot leads HeapTupleSatisfiesMVCC to not set  
HEAP_XMIN_INVALID. Which subsequently causes the kill_prior_tuple optimization  
to not kick in (via HeapTupleIsSurelyDead() returning false). The performance  
effects of doing the same index-lookups over and over again is how the issue  
was discovered...  
  
Fix the issue by incrementing xactCompletionCount in  
XidCacheRemoveRunningXids. It already acquires ProcArrayLock exclusively,  
making that an easy proposition.  
  
Add a test to ensure that kill_prior_tuple prevents index growth when it  
involves aborted subtransaction of the current transaction.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20210406043521.lopeo7bbigad3n6t@alap3.anarazel.de  
Discussion: https://postgr.es/m/20210317055718.v6qs3ltzrformqoa%40alap3.anarazel.de  

commit   : 8523492d4e349c4714aa2ab0291be175a88cb4fc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 6 Apr 2021 08:49:22 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 6 Apr 2021 08:49:22 -0700    

Retry the call to heap_prune_page() in rare cases where there is  
disagreement between the heap_prune_page() call and the call to  
HeapTupleSatisfiesVacuum() that immediately follows.  Disagreement is  
possible when a concurrently-aborted transaction makes a tuple DEAD  
during the tiny window between each step.  This was the only case where  
a tuple considered DEAD by VACUUM still had storage following pruning.  
VACUUM's definition of dead tuples is now uniformly simple and  
unambiguous: dead tuples from each page are always LP_DEAD line pointers  
that were encountered just after we performed pruning (and just before  
we considered freezing remaining items with tuple storage).  
  
Eliminating the tupgone=true special case enables INDEX_CLEANUP=off  
style skipping of index vacuuming that takes place based on flexible,  
dynamic criteria.  The INDEX_CLEANUP=off case had to know about skipping  
indexes up-front before now, due to a subtle interaction with the  
special case (see commit dd695979) -- this was a special case unto  
itself.  Now there are no special cases.  And so now it won't matter  
when or how we decide to skip index vacuuming: it won't affect how  
pruning behaves, and it won't be affected by any of the implementation  
details of pruning or freezing.  
  
Also remove XLOG_HEAP2_CLEANUP_INFO records.  These are no longer  
necessary because we now rely entirely on heap pruning taking care of  
recovery conflicts.  There is no longer any need to generate recovery  
conflicts for DEAD tuples that pruning just missed.  This also means  
that heap vacuuming now uses exactly the same strategy for recovery  
conflicts as index vacuuming always has: REDO routines never need to  
process a latestRemovedXid from the WAL record, since earlier REDO of  
the WAL record from pruning is sufficient in all cases.  The generic  
XLOG_HEAP2_CLEAN record type is now split into two new record types to  
reflect this new division (these are called XLOG_HEAP2_PRUNE and  
XLOG_HEAP2_VACUUM).  
  
Also stop acquiring a super-exclusive lock for heap pages when they're  
vacuumed during VACUUM's second heap pass.  A regular exclusive lock is  
enough.  This is correct because heap page vacuuming is now strictly a  
matter of setting the LP_DEAD line pointers to LP_UNUSED.  No other  
backend can have a pointer to a tuple located in a pinned buffer that  
can be invalidated by a concurrent heap page vacuum operation.  
  
Heap vacuuming can now be thought of as conceptually similar to index  
vacuuming and conceptually dissimilar to heap pruning.  Heap pruning now  
has sole responsibility for anything involving the logical contents of  
the database (e.g., managing transaction status information, recovery  
conflicts, considering what to do with HOT chains).  Index vacuuming and  
heap vacuuming are now only concerned with recycling garbage items from  
physical data structures that back the logical database.  
  
Bump XLOG_PAGE_MAGIC due to pruning and heap page vacuum WAL record  
changes.  
  
Credit for the idea of retrying pruning a page to avoid the tupgone case  
goes to Andres Freund.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Andres Freund <andres@anarazel.de>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com  

commit   : 789d81de8a50d9a23cc1a3b8ea5d839246020689    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 11:23:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 11:23:48 -0400    

Per cpluspluscheck.  

commit   : 3a5130672296ed4e682403a77a9a3ad3d21cef75    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 6 Apr 2021 16:58:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 6 Apr 2021 16:58:10 +0200    

Previously, psql printed only the last result if a command string  
returned multiple result sets.  Now it prints all of them.  The  
previous behavior can be obtained by setting the psql variable  
SHOW_ALL_RESULTS to off.  
  
Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Reviewed-by: "Iwata, Aya" <iwata.aya@jp.fujitsu.com>  
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1904132231510.8961@lancre  

commit   : 518442c7f334f3b05ea28b7ef50f1b551cfcc23e    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 6 Apr 2021 16:12:37 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 6 Apr 2021 16:12:37 +0200    

Handling of incompatible clauses while applying extended statistics was  
a bit confused - while handling a mix of compatible and incompatible  
clauses it sometimes incorrectly treated the incompatible clauses as  
compatible, resulting in a crash.  
  
Fixed by reworking the code applying the selected statistics object to  
make it easier to understand, and adding a proper compatibility check.  
  
Reported-by: David Rowley  
Discussion: https://postgr.es/m/CAApHDvpYT10-nkSp8xXe-nbO3jmoaRyRFHbzh-RWMfAJynqgpQ%40mail.gmail.com  

commit   : 7ab96cf6b312cfcd79cdc1a69c6bdb75de0ed30f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 6 Apr 2021 07:49:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 6 Apr 2021 07:49:39 -0700    

Add a lazy_scan_heap() subsidiary function that handles heap pruning and  
tuple freezing: lazy_scan_prune().  This is a great deal cleaner.  The  
code that remains in lazy_scan_heap()'s per-block loop can now be  
thought of as code that either comes before or after the call to  
lazy_scan_prune(), which is now the clear focal point.  This division is  
enforced by the way in which we now manage state.  lazy_scan_prune()  
outputs state (using its own struct) that describes what to do with the  
page following pruning and freezing (e.g., visibility map maintenance,  
recording free space in the FSM).  It doesn't get passed any special  
instructional state from the preamble code, though.  
  
Also cleanly separate the logic used by a VACUUM with INDEX_CLEANUP=off  
from the logic used by single-heap-pass VACUUMs.  The former case is now  
structured as the omission of index and heap vacuuming by a two pass  
VACUUM.  The latter case goes back to being used only when the table  
happens to have no indexes (just as it was before commit a96c41fe).  
This structure is much more natural, since the whole point of  
INDEX_CLEANUP=off is to skip the index and heap vacuuming that would  
otherwise take place.  The single-heap-pass case doesn't skip any useful  
work, though -- it just does heap pruning and heap vacuuming together  
when the table happens to have no indexes.  
  
Both of these changes are preparation for an upcoming patch that  
generalizes the mechanism used by INDEX_CLEANUP=off.  The later patch  
will allow VACUUM to give up on index and heap vacuuming dynamically, as  
problems emerge (e.g., with wraparound), so that an affected VACUUM  
operation can finish up as soon as possible.  
  
Also fix a very old bug in single-pass VACUUM VERBOSE output.  We were  
reporting the number of tuples deleted via pruning as a direct  
substitute for reporting the number of LP_DEAD items removed in a  
function that deals with the second pass over the heap.  But that  
doesn't work at all -- they're two different things.  
  
To fix, start tracking the total number of LP_DEAD items encountered  
during pruning, and use that in the report instead.  A single pass  
VACUUM will always vacuum away whatever LP_DEAD items a heap page has  
immediately after it is pruned, so the total number of LP_DEAD items  
encountered during pruning equals the total number vacuumed-away.  
(They are _not_ equal in the INDEX_CLEANUP=off case, but that's okay  
because skipping index vacuuming is now a totally orthogonal concept to  
one-pass VACUUM.)  
  
Also stop reporting the count of LP_UNUSED items in VACUUM VERBOSE  
output.  This makes the output of VACUUM VERBOSE more consistent with  
log_autovacuum's output (because it never showed information about  
LP_UNUSED items).  VACUUM VERBOSE reported LP_UNUSED items left behind  
by the last VACUUM, and LP_UNUSED items created via pruning HOT chains  
during the current VACUUM (it never included LP_UNUSED items left behind  
by the current VACUUM's second pass over the heap).  This makes it  
useless as an indicator of line pointer bloat, which must have been the  
original intention. (Like the first VACUUM VERBOSE issue, this issue was  
arguably an oversight in commit 282d2a03, which added the heap-only  
tuple optimization.)  
  
Finally, stop reporting empty_pages in VACUUM VERBOSE output, and start  
reporting pages_removed instead.  This also makes the output of VACUUM  
VERBOSE more consistent with log_autovacuum's output (which does not  
show empty_pages, but does show pages_removed).  An empty page isn't  
meaningfully different to a page that is almost empty, or a page that is  
empty but for only a small number of remaining LP_UNUSED items.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com  

commit   : 091e22b2e673e3e8480abd68fbb827c5d6979615    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 10:34:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Apr 2021 10:34:37 -0400    

Andrew Gierth reported that it's possible to crash the backend if no  
pg_attrdef record is found to match an attribute that has atthasdef set.  
AttrDefaultFetch warns about this situation, but then leaves behind  
a relation tupdesc that has null "adbin" pointer(s), which most places  
don't guard against.  
  
We considered promoting the warning to an error, but throwing errors  
during relcache load is pretty drastic: it effectively locks one out  
of using the relation at all.  What seems better is to leave the  
load-time behavior as a warning, but then throw an error in any code  
path that wants to use a default and can't find it.  This confines  
the error to a subset of INSERT/UPDATE operations on the table, and  
in particular will at least allow a pg_dump to succeed.  
  
Also, we should fix AttrDefaultFetch to not leave any null pointers  
in the tupdesc, because that just creates an untested bug hazard.  
  
While at it, apply the same philosophy of "warn at load, throw error  
only upon use of the known-missing info" to CHECK constraints.  
CheckConstraintFetch is very nearly the same logic as AttrDefaultFetch,  
but for reasons lost in the mists of time, it was throwing ERROR for  
the same cases that AttrDefaultFetch treats as WARNING.  Make the two  
functions more nearly alike.  
  
In passing, get rid of potentially-O(N^2) loops in equalTupleDesc  
by making AttrDefaultFetch sort the entries after fetching them,  
so that equalTupleDesc can assume that entries in two equal tupdescs  
must be in matching order.  (CheckConstraintFetch already was sorting  
CHECK constraints, but equalTupleDesc hadn't been told about it.)  
  
There's some argument for back-patching this, but with such a small  
number of field reports, I'm content to fix it in HEAD.  
  
Discussion: https://postgr.es/m/87pmzaq4gx.fsf@news-spur.riddles.org.uk  

commit   : 9de9294b0c4dac77edb80f029648afca79d14653    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 22:56:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 22:56:51 +0900    

Previously if hot standby was enabled, archive recovery exited with  
an error when it found WAL generated with wal_level=minimal.  
But if hot standby was disabled, it just reported a warning and  
continued in that case. Which could lead to data loss or errors  
during normal operation. A warning was emitted, but users could  
easily miss that and not notice this serious situation until  
they encountered the actual errors.  
  
To improve this situation, this commit changes archive recovery  
so that it exits with FATAL error when it finds WAL generated with  
wal_level=minimal whatever the setting of hot standby. This enables  
users to notice the serious situation soon.  
  
The FATAL error is thrown if archive recovery starts from a base  
backup taken before wal_level is changed to minimal. When archive  
recovery exits with the error, if users have a base backup taken  
after setting wal_level to higher than minimal, they can recover  
the database by starting archive recovery from that newer backup.  
But note that if such backup doesn't exist, there is no easy way to  
complete archive recovery, which may make the database server  
unstartable and users may lose whole database. The commit adds  
the note about this risk into the document.  
  
Even in the case of unstartable database server, previously by just  
disabling hot standby users could avoid the error during archive  
recovery, forcibly start up the server and salvage data from it.  
But note that this commit makes this procedure unavailable at all.  
  
Author: Takamichi Osumi  
Reviewed-by: Laurenz Albe, Kyotaro Horiguchi, David Steele, Fujii Masao  
Discussion: https://postgr.es/m/OSBPR01MB4888CBE1DA08818FD2D90ED8EDF90@OSBPR01MB4888.jpnprd01.prod.outlook.com  

commit   : c4c393b3ec83ceb4b4d7f37cdd5302126377d069    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 6 Apr 2021 14:53:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 6 Apr 2021 14:53:56 +0300    

Reported-by: Jaime Casanova, using SQLsmith  
Discussion: https://www.postgresql.org/message-id/20210402235337.GA4082@ahch-to  

commit   : 6b258e3d688db14aadb58dde2a72939362310684    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 6 Apr 2021 11:50:42 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 6 Apr 2021 11:50:42 +0100    

This adds a new function, permute(), that generates pseudorandom  
permutations of arbitrary sizes. This can be used to randomly shuffle  
a set of values to remove unwanted correlations. For example,  
permuting the output from a non-uniform random distribution so that  
all the most common values aren't collocated, allowing more realistic  
tests to be performed.  
  
Formerly, hash() was recommended for this purpose, but that suffers  
from collisions that might alter the distribution, so recommend  
permute() for this purpose instead.  
  
Fabien Coelho and Hironobu Suzuki, with additional hacking be me.  
Reviewed by Thomas Munro, Alvaro Herrera and Muhammad Usama.  
  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1807280944370.5142@lancre  

commit   : a8af856d3257138590788e40eb84049def147acf    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 6 Apr 2021 19:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 6 Apr 2021 19:15:00 +0900    

Adjust the number of events given to WaitEventSetWait() so that it  
doesn't exceed the maximum number of events in the WaitEventSet given  
to that function (set->nevents_space) in hopes of making the buildfarm  
green.  
  
Per valgrind failure report from Tom Lane and the buildfarm.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/3411577.1617289776%40sss.pgh.pa.us  

commit   : 82ed7748b710e3ddce3f7ebc74af80fe4869492f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 6 Apr 2021 10:44:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 6 Apr 2021 10:44:26 +0200    

At present, if we want to update publications in a subscription, we  
can use SET PUBLICATION.  However, it requires supplying all  
publications that exists and the new publications.  If we want to add  
new publications, it's inconvenient.  The new syntax only supplies the  
new publications.  When the refresh is true, it only refreshes the new  
publications.  
  
Author: Japin Li <japinli@hotmail.com>  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/MEYP282MB166939D0D6C480B7FBE7EFFBB6BC0@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : 266b5673b4b6bed2e9ebfe73ca967f44d6dc0e6c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Apr 2021 14:58:52 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Apr 2021 14:58:52 +0530    

In the tests, after disabling the subscription, we were not waiting for  
the replication connection to drop from the publisher. So when the test  
was trying to use the same slot to fetch the messages via SQL API, it  
sometimes gives an error that the replication slot is active for other  
PID.  
  
Per buildfarm.  

commit   : 9bc9b4609a246ded5caf3f3d4c0013a002ba2323    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Apr 2021 18:33:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Apr 2021 18:33:40 +1200    

It seems that in MSVC timeval's tv_sec field is of type long.  
localtime() takes a time_t pointer.  Since long is 32-bit even on 64-bit  
builds in MSVC, passing a long pointer instead of the correct time_t  
pointer generated a compiler warning.  Fix that.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAApHDvoRG25X_=ZCGSPb4KN_j2iu=G2uXsRSg8NBZeuhkOSETg@mail.gmail.com  

commit   : a2da77cdb4661826482ebf2ddba1f953bc74afe4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 6 Apr 2021 07:17:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 6 Apr 2021 07:17:13 +0200    

The previous implementation of EXTRACT mapped internally to  
date_part(), which returned type double precision (since it was  
implemented long before the numeric type existed).  This can lead to  
imprecise output in some cases, so returning numeric would be  
preferrable.  Changing the return type of an existing function is a  
bit risky, so instead we do the following:  We implement a new set of  
functions, which are now called "extract", in parallel to the existing  
date_part functions.  They work the same way internally but use  
numeric instead of float8.  The EXTRACT construct is now mapped by the  
parser to these new extract functions.  That way, dumps of views  
etc. from old versions (which would use date_part) continue to work  
unchanged, but new uses will map to the new extract functions.  
  
Additionally, the reverse compilation of EXTRACT now reproduces the  
original syntax, using the new mechanism introduced in  
40c24bfef92530bd846e111c1742c2a54441c62c.  
  
The following minor changes of behavior result from the new  
implementation:  
  
- The column name from an isolated EXTRACT call is now "extract"  
  instead of "date_part".  
  
- Extract from date now rejects inappropriate field names such as  
  HOUR.  It was previously mapped internally to extract from  
  timestamp, so it would silently accept everything appropriate for  
  timestamp.  
  
- Return values when extracting fields with possibly fractional  
  values, such as second and epoch, now have the full scale that the  
  value has internally (so, for example, '1.000000' instead of just  
  '1').  
  
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu  

commit   : f5d94e405e17a49487672316610630be2f9d0bb7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 14:09:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 14:09:40 +0900    

Introduced by 9868167500.  
  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm1DqgaLBAJrtGznKk1sR1mH-augmp7LfGvxWwTUhah+rg@mail.gmail.com  

commit   : 43620e328617c1f41a2a54c8cee01723064e3ffa    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 13:44:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 13:44:15 +0900    

Commit 3e98c0bafb added pg_backend_memory_contexts view to display  
the memory contexts of the backend process. However its target process  
is limited to the backend that is accessing to the view. So this is  
not so convenient when investigating the local memory bloat of other  
backend process. To improve this situation, this commit adds  
pg_log_backend_memory_contexts() function that requests to log  
the memory contexts of the specified backend process.  
  
This information can be also collected by calling  
MemoryContextStats(TopMemoryContext) via a debugger. But  
this technique cannot be used in some environments because no debugger  
is available there. So, pg_log_backend_memory_contexts() allows us to  
see the memory contexts of specified backend more easily.  
  
Only superusers are allowed to request to log the memory contexts  
because allowing any users to issue this request at an unbounded rate  
would cause lots of log messages and which can lead to denial of service.  
  
On receipt of the request, at the next CHECK_FOR_INTERRUPTS(),  
the target backend logs its memory contexts at LOG_SERVER_ONLY level,  
so that these memory contexts will appear in the server log but not  
be sent to the client. It logs one message per memory context.  
Because if it buffers all memory contexts into StringInfo to log them  
as one message, which may require the buffer to be enlarged very much  
and lead to OOM error since there can be a large number of memory  
contexts in a backend.  
  
When a backend process is consuming huge memory, logging all its  
memory contexts might overrun available disk space. To prevent this,  
now this patch limits the number of child contexts to log per parent  
to 100. As with MemoryContextStats(), it supposes that practical cases  
where the log gets long will typically be huge numbers of siblings  
under the same parent context; while the additional debugging value  
from seeing details about individual siblings beyond 100 will not be large.  
  
There was another proposed patch to add the function to return  
the memory contexts of specified backend as the result sets,  
instead of logging them, in the discussion. However that patch is  
not included in this commit because it had several issues to address.  
  
Thanks to Tatsuhito Kasahara, Andres Freund, Tom Lane, Tomas Vondra,  
Michael Paquier, Kyotaro Horiguchi and Zhihong Yu for the discussion.  
  
Bump catalog version.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Kyotaro Horiguchi, Zhihong Yu, Fujii Masao  
Discussion: https://postgr.es/m/0271f440ac77f2a4180e0e56ebd944d1@oss.nttdata.com  

commit   : 5a71964a832febfee23cedc3bb354049d6ca78a7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Apr 2021 13:23:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Apr 2021 13:23:57 +0900    

The recent refactoring done in c50624c accidentally broke a portion of  
the kerberos tests checking after a query, so add its functionality  
back.  Some inactive SSL tests had their arguments in an incorrect  
order, which would cause them to fail if they were to run.  
  
Author: Jacob Champion  
Discussion: https://postgr.es/m/4f5b0b3dc0b6fe9ae6a34886b4d4000f61eb567e.camel@vmware.com  

commit   : ac4645c0157fc5fcef0af8ff571512aa284a2cec    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Apr 2021 08:40:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Apr 2021 08:40:47 +0530    

The output plugin accepts a new parameter (messages) that controls if  
logical decoding messages are written into the replication stream. It is  
useful for those clients that use pgoutput as an output plugin and needs  
to process messages that were written by pg_logical_emit_message().  
  
Although logical streaming replication protocol supports logical  
decoding messages now, logical replication does not use this feature yet.  
  
Author: David Pirotte, Euler Taveira  
Reviewed-by: Euler Taveira, Andres Freund, Ashutosh Bapat, Amit Kapila  
Discussion: https://postgr.es/m/CADK3HHJ-+9SO7KuRLH=9Wa1rAo60Yreq1GFNkH_kd0=CdaWM+A@mail.gmail.com  

commit   : 531737ddad214cb8a675953208e2f3a6b1be122b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Apr 2021 08:26:31 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Apr 2021 08:26:31 +0530    

Instead of using multiple parameters in parse_ouput_parameters function  
signature, use the struct PGOutputData that encapsulates all pgoutput  
options. It will be useful for future work where we need to add other  
options in pgoutput.  
  
Author: Euler Taveira  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CADK3HHJ-+9SO7KuRLH=9Wa1rAo60Yreq1GFNkH_kd0=CdaWM+A@mail.gmail.com  

commit   : 6d41dd045ada28ee14182112fc4cf50fb3879d28    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Apr 2021 09:53:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Apr 2021 09:53:06 +0900    

This type of failure is similar to what has been fixed in c757a3da,  
where an authentication failure combined with psql pushing a command  
down its communication pipe causes a test failure.  This routine is  
designed to fail, so sending a query has little sense anyway.  
  
Per buildfarm members gaur and hoverfly, based on an analysis and fix  
from Tom Lane.  
  
Discussion: https://postgr.es/m/513200.1617634642@sss.pgh.pa.us  

commit   : f6b8f19a084ce949522fcbc940dc116c034cfc47    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Apr 2021 17:17:40 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Apr 2021 17:17:40 -0700    

Commit 49f49def took entirely the wrong approach to fixing this issue.  
Just allocate a local buffer access strategy in each individual worker  
instead of trying to propagate state.  This state was never propagated  
by parallel VACUUM in the first place.  
  
It looks like the only reason that this worked following commit 40d964ec  
was that it involved static global variables, which are initialized to 0  
per the C standard.  
  
A more comprehensive fix may be necessary, even on HEAD.  This fix  
should at least get the buildfarm green once again.  
  
Thanks once again to Thomas Munro for continued off-list assistance with  
the issue.  

commit   : 09c1c6ab4bc5764dd69c53ccfd43b2060b1fd090    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Apr 2021 18:41:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Apr 2021 18:41:09 -0400    

Not much to say here: does what it says on the tin.  
We steal a previously-always-zero bit from the nextOffset  
field of leaf index tuples in order to track whether there  
is a nulls bitmap.  Otherwise it works about like included  
columns in other index types.  
  
Pavel Borisov, reviewed by Andrey Borodin and Anastasia Lubennikova,  
and rather heavily editorialized on by me  
  
Discussion: https://postgr.es/m/CALT9ZEFi-vMp4faht9f9Junb1nO3NOSjhpxTmbm1UGLMsLqiEQ@mail.gmail.com  

commit   : 49f49defe7c0a330cca084de5da14ccdfdafc6a3    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Apr 2021 14:56:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Apr 2021 14:56:56 -0700    

Parallel VACUUM relied on global variable state from the leader process  
being propagated to workers on fork().  Commit b4af70cb removed most  
uses of global variables inside vacuumlazy.c, but did not account for  
the buffer access strategy state.  
  
To fix, propagate the state through shared memory instead.  
  
Per buildfarm failures on elver, curculio, and morepork.  
  
Many thanks to Thomas Munro for off-list assistance with this issue.  

commit   : b4af70cb210393c9c8f41643acf6b213e21178e7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Apr 2021 13:21:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Apr 2021 13:21:44 -0700    

Reorganize the state struct used by VACUUM -- group related items  
together to make it easier to understand.  Also stop relying on stack  
variables inside lazy_scan_heap() -- move those into the state struct  
instead.  Doing things this way simplifies large groups of related  
functions whose function signatures had a lot of unnecessary redundancy.  
  
Switch over to using int64 for the struct fields used to count things  
that are reported to the user via log_autovacuum and VACUUM VERBOSE  
output.  We were using double, but that doesn't seem to have any  
advantages.  Using int64 makes it possible to add assertions that verify  
that the first pass over the heap (pruning) encounters precisely the  
same number of LP_DEAD items that get deleted from indexes later on, in  
the second pass over the heap.  These assertions will be added in later  
commits.  
  
Finally, adjust the signatures of functions with IndexBulkDeleteResult  
pointer arguments in cases where there was ambiguity about whether or  
not the argument relates to a single index or all indexes.  Functions  
now use the idiom that both ambulkdelete() and amvacuumcleanup() have  
always used (where appropriate): accept a mutable IndexBulkDeleteResult  
pointer argument, and return a result IndexBulkDeleteResult pointer to  
caller.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CAH2-WzkeOSYwC6KNckbhk2b1aNnWum6Yyn0NKP9D-Hq1LGTDPw@mail.gmail.com  

commit   : 6c3ffd697e2242f5497ea4b40fffc8f6f922ff60    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Apr 2021 13:42:52 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Apr 2021 13:42:52 -0400    

A commonly requested use-case is to have a role who can run an  
unfettered pg_dump without having to explicitly GRANT that user access  
to all tables, schemas, et al, without that role being a superuser.  
This address that by adding a "pg_read_all_data" role which implicitly  
gives any member of this role SELECT rights on all tables, views and  
sequences, and USAGE rights on all schemas.  
  
As there may be cases where it's also useful to have a role who has  
write access to all objects, pg_write_all_data is also introduced and  
gives users implicit INSERT, UPDATE and DELETE rights on all tables,  
views and sequences.  
  
These roles can not be logged into directly but instead should be  
GRANT'd to a role which is able to log in.  As noted in the  
documentation, if RLS is being used then an administrator may (or may  
not) wish to set BYPASSRLS on the login role which these predefined  
roles are GRANT'd to.  
  
Reviewed-by: Georgios Kokolatos  
Discussion: https://postgr.es/m/20200828003023.GU29590@tamriel.snowman.net  

commit   : ad8b674922eb70dc5cd02951dd82fe2c4c37c80a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 02:25:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 02:25:37 +0900    

Maxim Orlov reported that the shutdown of standby server could result in  
the following assertion failure. The cause of this issue was that,  
when the shutdown caused the startup process to exit, recovery-time  
transaction tracking was not shut down even if it's already initialized,  
and some locks the tracked transactions were holding could not be released.  
At this situation, if other process was invoked and the PGPROC entry that  
the startup process used was assigned to it, it found such unreleased locks  
and caused the assertion failure, during the initialization of it.  
  
    TRAP: FailedAssertion("SHMQueueEmpty(&(MyProc->myProcLocks[i]))"  
  
This commit fixes this issue by making the startup process shut down  
transaction tracking and release all locks, at the exit of it.  
  
Back-patch to all supported branches.  
  
Reported-by: Maxim Orlov  
Author: Fujii Masao  
Reviewed-by: Maxim Orlov  
Discussion: https://postgr.es/m/ad4ce692cc1d89a093b471ab1d969b0b@postgrespro.ru  

commit   : 6734e806958c4ebd253adb30b255983981818710    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 5 Apr 2021 11:45:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 5 Apr 2021 11:45:17 -0400    

This mostly adds links to the glossary to the existing text, instead of  
using <firstterm>.  Heikki left this out of 29ad6595ef7f out of  
stylistic concerns; these have since been addressed.  
  
Author: Jürgen Purtz <juergen@purtz.de>  
Discussion: https://postgr.es/m/67d7240f-8596-83fc-5e15-af06c128a0f5@purtz.de  

commit   : a63dd8afe2b859b853d857cd8a0392ca1e04ab6c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Apr 2021 09:10:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Apr 2021 09:10:27 +0200    

Move the planner-control flags up so that there is more room for parse  
options.  Some pending patches need some room there, so do this  
renumbering separately so that there is less potential for conflicts.  

commit   : 9f6f1f9b8e61f9ce47e1936fc68c21a4a8d6722c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Apr 2021 11:18:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Apr 2021 11:18:12 +0900    

Introduced by 51e225d.  
  
Author: Anton Voloshin  
Discussion: https://postgr.es/m/05477da0-703c-7de7-998c-5879738e8f39@postgrespro.ru  

commit   : c50624cdd248c13b4ba199f95e24c88d2cc8a097    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Apr 2021 10:13:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Apr 2021 10:13:57 +0900    

This commit refactors more TAP tests to adapt with the recent  
introduction of connect_ok() and connect_fails() in PostgresNode,  
introduced by 0d1a3343.  This changes the following test suites to use  
the same code paths for connection checks:  
- Kerberos  
- LDAP  
- SSL  
- Authentication  
  
Those routines are extended to be able to handle optional parameters  
that are set depending on each suite's needs, as of:  
- custom SQL query.  
- expected stderr matching pattern.  
- expected stdout matching pattern.  
The new design is extensible with more parameters, and there are some  
plans for those routines in the future with checks based on the contents  
of the backend logs.  
  
Author: Jacob Champion, Michael Paquier  
Discussion: https://postgr.es/m/d17b919e27474abfa55d97786cb9cfadfe2b59e9.camel@vmware.com  

commit   : dfc843d465689d2c2af8b0e01c66c51ccaae2343    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Apr 2021 17:57:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Apr 2021 17:57:07 -0400    

spg_box_quad_leaf_consistent unconditionally returned the leaf  
datum as leafValue, even though in its usage for poly_ops that  
value is of completely the wrong type.  
  
In versions before 12, that was harmless because the core code did  
nothing with leafValue in non-index-only scans ... but since commit  
2a6368343, if we were doing a KNN-style scan, spgNewHeapItem would  
unconditionally try to copy the value using the wrong datatype  
parameters.  Said copying is a waste of time and space if we're not  
going to return the data, but it accidentally failed to fail until  
I fixed the datatype confusion in ac9099fc1.  
  
Hence, change spgNewHeapItem to not copy the datum unless we're  
actually going to return it later.  This saves cycles and dodges  
the question of whether lossy opclasses are returning the right  
type.  Also change spg_box_quad_leaf_consistent to not return  
data that might be of the wrong type, as insurance against  
somebody introducing a similar bug into the core code in future.  
  
It seems like a good idea to back-patch these two changes into  
v12 and v13, although I'm afraid to change spgNewHeapItem's  
mistaken idea of which datatype to use in those branches.  
  
Per buildfarm results from ac9099fc1.  
  
Discussion: https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us  

commit   : ac9099fc1dd460bffaafec19272159dd7bc86f5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Apr 2021 14:28:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Apr 2021 14:28:35 -0400    

According to the documentation, the attType passed to the opclass  
config function (and also relied on by the core code) is the type  
of the heap column or expression being indexed.  But what was  
actually being passed was the type stored for the index column.  
This made no difference for user-defined SP-GiST opclasses,  
because we weren't allowing the STORAGE clause of CREATE OPCLASS  
to be used, so the two types would be the same.  But it's silly  
not to allow that, seeing that the built-in poly_ops opclass  
has a different value for opckeytype than opcintype, and that if you  
want to do lossy storage then the types must really be different.  
(Thus, user-defined opclasses doing lossy storage had to lie about  
what type is in the index.)  Hence, remove the restriction, and make  
sure that we use the input column type not opckeytype where relevant.  
  
For reasons of backwards compatibility with existing user-defined  
opclasses, we can't quite insist that the specified leafType match  
the STORAGE clause; instead just add an amvalidate() warning if  
they don't match.  
  
Also fix some bugs that would only manifest when trying to return  
index entries when attType is different from attLeafType.  It's not  
too surprising that these have not been reported, because the only  
usual reason for such a difference is to store the leaf value  
lossily, rendering index-only scans impossible.  
  
Add a src/test/modules module to exercise cases where attType is  
different from attLeafType and yet index-only scan is supported.  
  
Discussion: https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us  

commit   : d9c5b9a9eeb9e3061ae139e0e564ce5358c94001    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:36:10 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:36:10 +0200    

When calling sort_expanded_ranges() we need to remember the return  
value, because the function sorts and also deduplicates the ranges. So  
the number of ranges may decrease. brin_minmax_multi_union failed to do  
that, which resulted in crashes due to bogus ranges (equal minval/maxval  
but not marked as compacted).  
  
Reported-by: Jaime Casanova  
Discussion: https://postgr.es/m/20210404052550.GA4376%40ahch-to  

commit   : 4908684ddab35135869efa2af6b49c4d67c422f9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:26:48 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:26:48 +0200    

The regression test for BRIN minmax-multi opclasses tested almost all  
supported data types, with the exception of macaddr8. So this adds it.  

commit   : 1dad2a5ea3d14dd205603c31cc94ec088183ab2a    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:25:36 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:25:36 +0200    

The BRIN minmax-multi consistent function incorrectly assumed it can  
lookup an operator, and then swap the arguments to get the commutator.  
For example <(a,b) would be called as <(b,a) to get >(a,b). This works  
when the arguments are of the same type, but with cross-type opclasses  
this fails. We can't swap <(float4,float8) arguments, for example.  
  
Fixed by passing arguments in the right order.  
  
Discussion: https://postgr.es/m/CAJKUy5jLZFLCxyxfT%3DMfK5mtPfSzHA1rVLowR-j4RRsFVvKm7A%40mail.gmail.com  

commit   : e1fbe1181c86247eaf8b4b142b81361ce4efcc66    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:23:30 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:23:30 +0200    

The distance calculation ignored the mask, unlike the inet comparator,  
which resulted in negative distance in some cases. Fixed by applying the  
mask in brin_minmax_multi_distance_inet. I've considered simply calling  
inetmi() to calculate the delta, but that does not consider mask either.  
  
Reviewed-by: Zhihong Yu  
Discussion: https://postgr.es/m/1a0a7b9d-9bda-e3a2-7fa4-88f15042a051%40enterprisedb.com  

commit   : 7262f2421a1e099a631356f7b80ad198e34e2a8a    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:21:41 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:21:41 +0200    

The distance calculation ignored the time zone, so the result of (b-a)  
might have ended negative even if (b > a). Fixed by considering the time  
zone difference.  
  
Reported-by: Jaime Casanova  
Discussion: https://postgr.es/m/CAJKUy5jLZFLCxyxfT%3DMfK5mtPfSzHA1rVLowR-j4RRsFVvKm7A%40mail.gmail.com  

commit   : 2b10e0e3c2ca14d732521479123e5d5e2094e143    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:13:26 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Apr 2021 19:13:26 +0200    

The distance calculation for interval type was treating months as having  
31 days, which is inconsistent with the interval comparator (using 30  
days). Due to this it was possible to get negative distance (b-a) when  
(a<b), trigerring an assert.  
  
Fixed by adopting the same logic as interval_cmp_value.  
  
Reported-by: Jaime Casanova  
Discussion: https://postgr.es/m/CAJKUy5jKH0Xhneau2mNftNPtTy-BVgQfXc8zQkEvRvBHfeUThQ%40mail.gmail.com  

commit   : 55873a00e3c3349664e7215077dca74ccea08b4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Apr 2021 17:38:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Apr 2021 17:38:31 -0400    

When editing the previous query buffer, if the editor is exited  
without modifying the temp file then clear the query buffer,  
rather than re-loading (and probably re-executing) the previous  
query buffer.  This reduces the probability of accidentally  
re-executing something you didn't intend to.  
  
Similarly, in "\e file", if the file isn't actually modified  
then don't load it into the query buffer.  And in "\ef" and  
"\ev", if no changes are made then clear the query buffer  
instead of loading the function or view definition into it.  
  
Cases where we fail to invoke the editor at all, or it returns  
a nonzero status, are treated like the no-file-modification case.  
  
Laurenz Albe, reviewed by Jacob Champion  
  
Discussion: https://postgr.es/m/0ba3f2a658bac6546d9934ab6ba63a805d46a49b.camel@cybertec.at  

commit   : 225a22b19ed2960acc8e9c0b7ae53e0e5b0eac87    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Apr 2021 11:44:47 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Apr 2021 11:44:47 -0700    

pgstat_report_wait_start() and pgstat_report_wait_end() required two  
conditional branches so far. One to check if MyProc is NULL, the other to  
check if pgstat_track_activities is set. As wait events are used around  
comparatively lightweight operations, and are inlined (reducing branch  
predictor effectiveness), that's not great.  
  
The dependency on MyProc has a second disadvantage: Low-level subsystems, like  
storage/file/fd.c, report wait events, but architecturally it is preferable  
for them to not depend on inter-process subsystems like proc.h (defining  
PGPROC).  After this change including pgstat.h (nor obviously its  
sub-components like backend_status.h, wait_event.h, ...) does not pull in IPC  
related headers anymore.  
  
These goals, efficiency and abstraction, are achieved by having  
pgstat_report_wait_start/end() not interact with MyProc, but instead a new  
my_wait_event_info variable. At backend startup it points to a local variable,  
removing the need to check for MyProc being NULL. During process  
initialization my_wait_event_info is redirected to MyProc->wait_event_info. At  
shutdown this is reversed. Because wait event reporting now does not need to  
know about where the wait event is stored, it does not need to know about  
PGPROC anymore.  
  
The removal of the branch for checking pgstat_track_activities is simpler:  
Don't check anymore. The cost due to the branch are often higher than the  
store - and even if not, pgstat_track_activities is rarely disabled.  
  
The main motivator to commit this work now is that removing the (indirect)  
pgproc.h include from pgstat.h simplifies a patch to move statistics reporting  
to shared memory (which still has a chance to get into 14).  
  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20210402194458.2vu324hkk2djq6ce@alap3.anarazel.de  

commit   : e1025044cd4e7f33f7304aed54d5778b8a82cd5d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Apr 2021 11:42:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Apr 2021 11:42:52 -0700    

Backend status (supporting pg_stat_activity) and command  
progress (supporting pg_stat_progress*) related code is largely  
independent from the rest of pgstat.[ch] (supporting views like  
pg_stat_all_tables that accumulate data over time). See also  
a333476b925.  
  
This commit doesn't rename the function names to make the distinction  
from the rest of pgstat_ clearer - that'd be more invasive and not  
clearly beneficial. If we were to decide to do such a rename at some  
point, it's better done separately from moving the code as well.  
  
Robert's review was of an earlier version.  
  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20210316195440.twxmlov24rr2nxrg@alap3.anarazel.de  

commit   : 8d3a4c3eae5367fba60ab77c159814defba784fe    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 3 Apr 2021 20:49:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 3 Apr 2021 20:49:08 +0900    

The TAP tests of src/test/ssl/ have been using rather generic matching  
patterns to check some failure scenarios, like "SSL error" or just  
"FATAL".  These have been introduced in 081bfc1.  
  
Those messages are not wrong per se, but when working on the integration  
of new SSL libraries it becomes hard to know if those errors are legit  
or not, and existing scenarios may fail in incorrect ways.  This commit  
makes all those messages more verbose by adding the information  
generated by OpenSSL.  Fortunately, the same error messages are used for  
all the versions supported on HEAD (checked that after running the tests  
from 1.0.1 to 1.1.1), so the change is straight-forward.  
  
Reported-by: Jacob Champion, Álvaro Herrera  
Discussion: https://postgr.es/m/YGU3AxQh0zBMMW8m@paquier.xyz  

commit   : e6bdfd9700ebfc7df811c97c2fc46d7e94e329a2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 3 Apr 2021 17:30:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 3 Apr 2021 17:30:49 +0900    

Similarly to the cryptohash implementations, this refactors the existing  
HMAC code into a single set of APIs that can be plugged with any crypto  
libraries PostgreSQL is built with (only OpenSSL currently).  If there  
is no such libraries, a fallback implementation is available.  Those new  
APIs are designed similarly to the existing cryptohash layer, so there  
is no real new design here, with the same logic around buffer bound  
checks and memory handling.  
  
HMAC has a dependency on cryptohashes, so all the cryptohash types  
supported by cryptohash{_openssl}.c can be used with HMAC.  This  
refactoring is an advantage mainly for SCRAM, that included its own  
implementation of HMAC with SHA256 without relying on the existing  
crypto libraries even if PostgreSQL was built with their support.  
  
This code has been tested on Windows and Linux, with and without  
OpenSSL, across all the versions supported on HEAD from 1.1.1 down to  
1.0.1.  I have also checked that the implementations are working fine  
using some sample results, a custom extension of my own, and doing  
cross-checks across different major versions with SCRAM with the client  
and the backend.  
  
Author: Michael Paquier  
Reviewed-by: Bruce Momjian  
Discussion: https://postgr.es/m/X9m0nkEJEzIPXjeZ@paquier.xyz  

commit   : 1d9c5d0ce2dcac05850401cf266a9df10a68de49    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Apr 2021 20:01:14 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Apr 2021 20:01:14 -0700    

An upcoming patch might remove the (now indirect) proc.h  
include (which in turn includes other headers), and it's cleaner for  
the modified files to include their dependencies directly anyway...  
  
Discussion: https://postgr.es/m/20210402194458.2vu324hkk2djq6ce@alap3.anarazel.de  

commit   : a333476b925134f6185037eaff3424c07a9f466f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Apr 2021 19:45:24 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Apr 2021 19:45:24 -0700    

The wait event related code is independent from the rest of the  
pgstat.[ch] code, of nontrivial size and changes on a regular  
basis. Put it into its own set of files.  
  
As there doesn't seem to be a good pre-existing directory for code  
like this, add src/backend/utils/activity.  
  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20210316195440.twxmlov24rr2nxrg@alap3.anarazel.de  

commit   : 1267d9862fc6a4f8cdc0ca38d1988b61f39da585    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 3 Apr 2021 10:41:43 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 3 Apr 2021 10:41:43 +1300    

Testing if an unsigned variable is >= 0 is pretty pointless.  
  
There's likely enough code in remove_cache_entry() to verify the cache  
memory accounting is correct in assert enabled builds. These Asserts  
were not adding much extra cover, even if they had been checking >= 0 on a  
signed variable.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20210402204734.6mo3nfacnljlicgn@alap3.anarazel.de  

commit   : 84bc2b17523ef485f102be7f00f7affb88f00f18    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Apr 2021 16:42:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Apr 2021 16:42:29 -0400    

All other places already use MONTHS_PER_YEAR appropriately.  
  
Backpatch-through: 9.6  

commit   : c30f54ad732ca5c8762bb68bbe0f51de9137dd72    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 3 Apr 2021 08:52:30 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 3 Apr 2021 08:52:30 +1300    

Provide a new GUC check_client_connection_interval that can be used to  
check whether the client connection has gone away, while running very  
long queries.  It is disabled by default.  
  
For now this uses a non-standard Linux extension (also adopted by at  
least one other OS).  POLLRDHUP is not defined by POSIX, and other OSes  
don't have a reliable way to know if a connection was closed without  
actually trying to read or write.  
  
In future we might consider trying to send a no-op/heartbeat message  
instead, but that could require protocol changes.  
  
Author: Sergey Cherkashin <s.cherkashin@postgrespro.ru>  
Author: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Tatsuo Ishii <ishii@sraoss.co.jp>  
Reviewed-by: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>  
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Maksim Milyutin <milyutinma@gmail.com>  
Reviewed-by: Tsunakawa, Takayuki/綱川 貴之 <tsunakawa.takay@fujitsu.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (much earlier version)  
Discussion: https://postgr.es/m/77def86b27e41f0efcba411460e929ae%40postgrespro.ru  

commit   : 174edbe9f9c1538ab3347474e96d176223591cd1    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Fri, 2 Apr 2021 13:48:42 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Fri, 2 Apr 2021 13:48:42 -0400    

Command-line options, or previous "ALTER (ROLE|DATABASE) ...  
SET ROLE ..." commands, can change the value of the default role  
for a session. In the presence of one of these, RESET ROLE will  
change the current user identifier to the default role rather  
than the session user identifier. Fix the documentation to  
reflect this reality. Backpatch to all supported versions.  
  
Author: Nathan Bossart  
Reviewed-By: Laurenz Albe, David G. Johnston, Joe Conway  
Reported by: Nathan Bossart  
Discussion: https://postgr.es/m/flat/925134DB-8212-4F60-8AB1-B1231D750CB4%40amazon.com  
Backpatch-through: 9.6  

commit   : 2eb1fc8b1ae8b974007e85636fc7336a9b5d7222    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 3 Apr 2021 00:07:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 3 Apr 2021 00:07:00 +0900    

pg_checksums uses two counters, total size and current size,  
to calculate the progress. Previously the progress that  
pg_checksums reported could not reach 100% at the end.  
The cause of this issue was that the sizes of only pages excluding  
new ones in each file were counted as the current size  
while the size of each file is counted as the total size.  
That is, the total size of all new pages could be reported  
as the difference between the total size and current size.  
  
This commit fixes this issue by making pg_checksums count  
the sizes of all pages including new ones in each file as  
the current size.  
  
Back-patch to v12 where progress reporting was added to pg_checksums.  
  
Reported-by: Shinya Kato  
Author: Shinya Kato  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/TYAPR01MB289656B1ACA0A5E7CAD07BE3C47A9@TYAPR01MB2896.jpnprd01.prod.outlook.com  

commit   : 53aafdb9ff6a561c7dea0f428a7c168f2b7e0f16    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Apr 2021 10:43:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Apr 2021 10:43:54 -0400    

Commit dd136052b established a policy that error message FILE items  
should include only the base name of the reporting source file, for  
uniformity and succinctness.  We now observe that some Windows compilers  
use backslashes in __FILE__ strings, so truncate at backslashes as well.  
  
This is expected to fix some platform variation in the results of the  
new libpq_pipeline test module.  
  
Discussion: https://postgr.es/m/3650140.1617372290@sss.pgh.pa.us  

commit   : 1877c9ac3acc05cc787dd6392d073202f8c8ee21    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 2 Apr 2021 10:29:58 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 2 Apr 2021 10:29:58 -0400    

Per gripe from Daniel Gustafsson  

commit   : b1be3074ac719ce8073fba35d4c8b52fb4ddd0c3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 2 Apr 2021 19:45:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 2 Apr 2021 19:45:42 +0900    

This commit adds a new option keep_connections that controls  
whether postgres_fdw keeps the connections to the foreign server open  
so that the subsequent queries can re-use them. This option can only be  
specified for a foreign server. The default is on. If set to off,  
all connections to the foreign server will be discarded  
at the end of transaction. Closed connections will be re-established  
when they are necessary by future queries using a foreign table.  
  
This option is useful, for example, when users want to prevent  
the connections from eating up the foreign servers connections  
capacity.  
  
Author: Bharath Rupireddy  
Reviewed-by: Alexey Kondratov, Vignesh C, Fujii Masao  
Discussion: https://postgr.es/m/CALj2ACVvrp5=AVp2PupEm+nAC8S4buqR3fJMmaCoc7ftT0aD2A@mail.gmail.com  

commit   : 9c5f67fd6256246b2a788a8feb1d42b79dcd0448    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 2 Apr 2021 11:01:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 2 Apr 2021 11:01:49 +0200    

Author: Hou Zhijie <houzj.fnst@cn.fujitsu.com>  
Discussion: https://www.postgresql.org/message-id/flat/7ea5ce773bbc4eea9ff1a381acd3b102@G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 96bdb7e19de80a0c9521c5696455bca2a685c919    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 2 Apr 2021 17:27:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 2 Apr 2021 17:27:31 +0900    

The caller of pgstat_report_replslot() passes int64 values to the function.  
Also the function stores those values in PgStat_Counter (i.e., int64) fields  
of PgStat_MsgReplSlot struct. But previously the function used "int" as  
the data types of some arguments for those values, which could lead to  
the overflow of values.  
  
To avoid this risk, this commit fixes pgstat_report_replslot() to use  
PgStat_Counter type for the arguments. Since they are the statistics counters,  
PgStat_Counter, the data type used for counters, is used for them  
instead of int64.  
  
Reported-by: Vignesh C  
Author: Vignesh C  
Reviewed-by: Jeevan Ladhe, Fujii Masao  
Discussion: https://postgr.es/m/CALDaNm080OpG=ZwOb0i8EyChH5SyHAMFWJCKaKTXmrfvJLbgaA@mail.gmail.com  

commit   : 6fb66c268df2de1112cac3cf0a6cf0a8b96ceaf0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 16:37:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 16:37:00 +0900    

The current instructions describing how to write the backup_label and  
tablespace_map files are confusing.  For example, opening a file in text  
mode on Windows and copy-pasting the file's contents would result in a  
failure at recovery because of the extra CRLF characters generated.  The  
documentation was not stating that clearly, and per discussion this is  
not considered as a supported scenario.  
  
This commit extends a bit the documentation to mention that it may be  
required to open the file in binary mode before writing its data.  
  
Reported-by: Wang Shenhao  
Author: David Steele  
Reviewed-by: Andrew Dunstan, Magnus Hagander  
Discussion: https://postgr.es/m/8373f61426074f2cb6be92e02f838389@G08CNEXMBPEKD06.g08.fujitsu.local  
Backpatch-through: 9.6  

commit   : 98e5bd103f887326e381c509c2fbe879ba3ea2f3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 2 Apr 2021 16:26:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 2 Apr 2021 16:26:36 +0900    

Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoA1YL7t0nzVSEySx6zOaE7xO3r0jyu8hkitGL2_XbaMxQ@mail.gmail.com  

commit   : a4fac4ffe8f8d543a10ac7debf1157e34963ece3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 2 Apr 2021 15:25:38 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 2 Apr 2021 15:25:38 +1300    

force_parallel_mode = regress is causing a few more problems than I  
thought.  It seems that both the leader and the single worker can  
contribute to the execution. I had mistakenly thought that only the worker  
process would do any work.  Since it's not deterministic as to which  
of the two processes will get a chance to work on the plan, it seems just  
better to disable force_parallel_mode for these tests.  At least doing  
this seems better than changing to EXPLAIN only rather than EXPLAIN  
ANALYZE.  
  
Additionally, I overlooked the fact that the number of executions of the  
sub-plan below a Result Cache will execute a varying number of times  
depending on cache eviction.  32-bit machines will use less memory and  
evict fewer tuples from the cache.  That results in the subnode being  
executed fewer times on 32-bit machines.  Let's just blank out the number  
of loops in each node.  

commit   : 2bda93f813919b58225f5a0e282e10b98d7633d4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Apr 2021 21:17:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Apr 2021 21:17:24 -0400    

Also mention that you should read the intervening major releases notes.  
This change was also applied to the website.  
  
Discussion: https://postgr.es/m/20210330144949.GA8259@momjian.us  
  
Backpatch-through: 9.6  

commit   : 9eacee2e62d89cab7b004f97c206c4fba4f1d745    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 2 Apr 2021 14:10:56 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 2 Apr 2021 14:10:56 +1300    

Here we add a new executor node type named "Result Cache".  The planner  
can include this node type in the plan to have the executor cache the  
results from the inner side of parameterized nested loop joins.  This  
allows caching of tuples for sets of parameters so that in the event that  
the node sees the same parameter values again, it can just return the  
cached tuples instead of rescanning the inner side of the join all over  
again.  Internally, result cache uses a hash table in order to quickly  
find tuples that have been previously cached.  
  
For certain data sets, this can significantly improve the performance of  
joins.  The best cases for using this new node type are for join problems  
where a large portion of the tuples from the inner side of the join have  
no join partner on the outer side of the join.  In such cases, hash join  
would have to hash values that are never looked up, thus bloating the hash  
table and possibly causing it to multi-batch.  Merge joins would have to  
skip over all of the unmatched rows.  If we use a nested loop join with a  
result cache, then we only cache tuples that have at least one join  
partner on the outer side of the join.  The benefits of using a  
parameterized nested loop with a result cache increase when there are  
fewer distinct values being looked up and the number of lookups of each  
value is large.  Also, hash probes to lookup the cache can be much faster  
than the hash probe in a hash join as it's common that the result cache's  
hash table is much smaller than the hash join's due to result cache only  
caching useful tuples rather than all tuples from the inner side of the  
join.  This variation in hash probe performance is more significant when  
the hash join's hash table no longer fits into the CPU's L3 cache, but the  
result cache's hash table does.  The apparent "random" access of hash  
buckets with each hash probe can cause a poor L3 cache hit ratio for large  
hash tables.  Smaller hash tables generally perform better.  
  
The hash table used for the cache limits itself to not exceeding work_mem  
* hash_mem_multiplier in size.  We maintain a dlist of keys for this cache  
and when we're adding new tuples and realize we've exceeded the memory  
budget, we evict cache entries starting with the least recently used ones  
until we have enough memory to add the new tuples to the cache.  
  
For parameterized nested loop joins, we now consider using one of these  
result cache nodes in between the nested loop node and its inner node.  We  
determine when this might be useful based on cost, which is primarily  
driven off of what the expected cache hit ratio will be.  Estimating the  
cache hit ratio relies on having good distinct estimates on the nested  
loop's parameters.  
  
For now, the planner will only consider using a result cache for  
parameterized nested loop joins.  This works for both normal joins and  
also for LATERAL type joins to subqueries.  It is possible to use this new  
node for other uses in the future.  For example, to cache results from  
correlated subqueries.  However, that's not done here due to some  
difficulties obtaining a distinct estimation on the outer plan to  
calculate the estimated cache hit ratio.  Currently we plan the inner plan  
before planning the outer plan so there is no good way to know if a result  
cache would be useful or not since we can't estimate the number of times  
the subplan will be called until the outer plan is generated.  
  
The functionality being added here is newly introducing a dependency on  
the return value of estimate_num_groups() during the join search.  
Previously, during the join search, we only ever needed to perform  
selectivity estimations.  With this commit, we need to use  
estimate_num_groups() in order to estimate what the hit ratio on the  
result cache will be.   In simple terms, if we expect 10 distinct values  
and we expect 1000 outer rows, then we'll estimate the hit ratio to be  
99%.  Since cache hits are very cheap compared to scanning the underlying  
nodes on the inner side of the nested loop join, then this will  
significantly reduce the planner's cost for the join.   However, it's  
fairly easy to see here that things will go bad when estimate_num_groups()  
incorrectly returns a value that's significantly lower than the actual  
number of distinct values.  If this happens then that may cause us to make  
use of a nested loop join with a result cache instead of some other join  
type, such as a merge or hash join.  Our distinct estimations have been  
known to be a source of trouble in the past, so the extra reliance on them  
here could cause the planner to choose slower plans than it did previous  
to having this feature.  Distinct estimations are also fairly hard to  
estimate accurately when several tables have been joined already or when a  
WHERE clause filters out a set of values that are correlated to the  
expressions we're estimating the number of distinct value for.  
  
For now, the costing we perform during query planning for result caches  
does put quite a bit of faith in the distinct estimations being accurate.  
When these are accurate then we should generally see faster execution  
times for plans containing a result cache.  However, in the real world, we  
may find that we need to either change the costings to put less trust in  
the distinct estimations being accurate or perhaps even disable this  
feature by default.  There's always an element of risk when we teach the  
query planner to do new tricks that it decides to use that new trick at  
the wrong time and causes a regression.  Users may opt to get the old  
behavior by turning the feature off using the enable_resultcache GUC.  
Currently, this is enabled by default.  It remains to be seen if we'll  
maintain that setting for the release.  
  
Additionally, the name "Result Cache" is the best name I could think of  
for this new node at the time I started writing the patch.  Nobody seems  
to strongly dislike the name. A few people did suggest other names but no  
other name seemed to dominate in the brief discussion that there was about  
names. Let's allow the beta period to see if the current name pleases  
enough people.  If there's some consensus on a better name, then we can  
change it before the release.  Please see the 2nd discussion link below  
for the discussion on the "Result Cache" name.  
  
Author: David Rowley  
Reviewed-by: Andy Fan, Justin Pryzby, Zhihong Yu, Hou Zhijie  
Tested-By: Konstantin Knizhnik  
Discussion: https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com  
Discussion: https://postgr.es/m/CAApHDvq=yQXr5kqhRviT2RhNKwToaWr9JAN5t+5_PzhuRJ3wvg@mail.gmail.com  

commit   : fe246d1c111d43fd60a1b0afff25ed09b7ae11eb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 09:44:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 09:44:42 +0900    

This test has been using a simple VACUUM with pg_relation_size() to  
check if a relation gets physically truncated or not, but forgot the  
fact that some concurrent activity, like checkpoint buffer writes, could  
cause some pages to be skipped.  The second test enabling  
vacuum_truncate could fail, seeing a non-empty relation.  The first test  
would not have failed, but could finish by testing a behavior different  
than the one aimed for.  Both tests gain a FREEZE option, to make the  
vacuums more aggressive and prevent page skips.  
  
This is similar to the issues fixed in c2dc1a7.  
  
Author: Arseny Sher  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/87tuotr2hh.fsf@ars-thinkpad  
backpatch-through: 12  

commit   : 1ebdec8c03294e55a9fdb6e676a9e8de680231cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Apr 2021 17:55:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Apr 2021 17:55:14 -0400    

The existing convention in SP-GiST is that any pass-by-value datatype  
is stored in Datum representation, i.e. it's of width sizeof(Datum)  
even when typlen is less than that.  This is okay, or at least it's  
too late to change it, for prefix datums and node-label datums in inner  
(upper) tuples.  But it's problematic for leaf datums, because we'd  
prefer those to be stored in Postgres' standard on-disk representation  
so that we can easily extend leaf tuples to carry additional "included"  
columns.  
  
I believe, however, that we can get away with just up and changing that.  
This would be an unacceptable on-disk-format break, but there are two  
big mitigating factors:  
  
1. It seems quite unlikely that there are any SP-GiST opclasses out  
there that use pass-by-value leaf datatypes.  Certainly none of the  
ones in core do, nor has codesearch.debian.net heard of any.  Given  
what SP-GiST is good for, it's hard to conceive of a use-case where  
the leaf-level values would be both small and fixed-width.  (As an  
example, if you wanted to index text values with the leaf level being  
just a byte, then every text string would have to be represented  
with one level of inner tuple per preceding byte, which would be  
horrendously space-inefficient and slow to access.  You always want  
to use as few inner-tuple levels as possible, leaving as much as  
possible in the leaf values.)  
  
2. Even granting that you have such an index, this change only  
breaks things on big-endian machines.  On little-endian, the high  
order bytes of the Datum format will now just appear to be alignment  
padding space.  
  
So, change the code to store pass-by-value leaf datums in their  
usual on-disk form.  Inner-tuple datums are not touched.  
  
This is extracted from a larger patch that intends to add support for  
"included" columns.  I'm committing it separately for visibility in  
our commit logs.  
  
Pavel Borisov and Tom Lane, reviewed by Andrey Borodin  
  
Discussion: https://postgr.es/m/CALT9ZEFi-vMp4faht9f9Junb1nO3NOSjhpxTmbm1UGLMsLqiEQ@mail.gmail.com  

commit   : c9c41c7a337d3e2deb0b2a193e9ecfb865d8f52b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 1 Apr 2021 15:32:06 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 1 Apr 2021 15:32:06 -0400    

The term 'default roles' wasn't quite apt as these roles aren't able to  
be modified or removed after installation, so rename them to be  
'Predefined Roles' instead, adding an entry into the newly added  
Obsolete Appendix to help users of current releases find the new  
documentation.  
  
Bruce Momjian and Stephen Frost  
  
Discussion: https://postgr.es/m/157742545062.1149.11052653770497832538%40wrigleys.postgresql.org  
and https://www.postgresql.org/message-id/20201120211304.GG16415@tamriel.snowman.net  

commit   : a68a894f0198aaeffa81b3027f135adcdaa8abf6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Apr 2021 16:25:46 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Apr 2021 16:25:46 -0300    

Windows doesn't like setvbuf(..., _IOLBF) and crashes if you use it,  
which has been causing the libpq_pipeline failures all along ... and our  
own port.h has known about it for a long time: it offers PG_IOLBF that's  
defined to _IONBF on that platform.  Follow its advice.  
  
While at it, get rid of a bogus bitshift that used a constant of the  
wrong size.  Decorate the constant as LL to fix.  While at it, remove a  
pointless addition that only confused matters.  
  
All as diagnosed by Tom Lane.  
  
Discussion: https://postgr.es/m/3458958.1617302154@sss.pgh.pa.us  

commit   : 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 1 Apr 2021 13:36:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 1 Apr 2021 13:36:28 -0400    

We now follow the order of checks from HeapTupleSatisfies* more  
closely to avoid coming to erroneous conclusions.  
  
Mark Dilger and Robert Haas  
  
Discussion: http://postgr.es/m/CA+Tgmob6sii0yTvULYJ0Vq4w6ZBmj7zUhddL3b+SKDi9z9NA7Q@mail.gmail.com  

commit   : ec03f2df17a8ba5b431b34dd924e020a0be729f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Apr 2021 13:34:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Apr 2021 13:34:16 -0400    

Despite the clear comments pointing out that the duplicative code  
segments in ReadHead() and _discoverArchiveFormat() needed to be  
in sync, they were not: the latter did not bother to apply any of  
the sanity checks in the former.  We'd missed noticing this partly  
because none of those checks would fail in scenarios we customarily  
test, and partly because the oversight would be masked if both  
segments execute, which they would in cases other than needing to  
autodetect the format of a non-seekable stdin source.  However,  
in a case meeting all these requirements --- for example, trying  
to read a newer-than-supported archive format from non-seekable  
stdin --- pg_restore missed applying the version check and would  
likely dump core or otherwise misbehave.  
  
The whole thing is silly anyway, because there seems little reason  
to duplicate the logic beyond the one-line verification that the  
file starts with "PGDMP".  There seems to have been an undocumented  
assumption that multiple major formats (major enough to require  
separate reader modules) would nonetheless share the first half-dozen  
fields of the custom-format header.  This seems unlikely, so let's  
fix it by just nuking the duplicate logic in _discoverArchiveFormat().  
  
Also get rid of the pointless attempt to seek back to the start of  
the file after successful autodetection.  That wastes cycles and  
it means we have four behaviors to verify not two.  
  
Per bug #16951 from Sergey Koposov.  This has been broken for  
decades, so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/16951-a4dd68cf0de23048@postgresql.org  

commit   : 91e7c903291116bd081abe7d4a058d40a2a06e16    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Apr 2021 16:12:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Apr 2021 16:12:53 +0200    

Through various refactorings over time, the extract(timezone_minute  
from time with time zone) and extract(timezone_minute from timestamp  
with time zone) implementations ended up with two different but  
equally nonsensical formulas by using SECS_PER_MINUTE and  
MINS_PER_HOUR interchangeably.  Since those two are of course both the  
same number, the formulas do work, but for readability, fix them to be  
semantically correct.  

commit   : dde1a35aee6266dc8105717275335c46cd2b3650    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Apr 2021 10:04:45 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Apr 2021 10:04:45 -0300    

I forgot to strdup() when processing argv[].  Apparently many platforms  
hide this mistake from users, but in those that don't you may get a  
program crash.  Repair.  
  
Per buildfarm member drongo, which is the only one in all the buildfarm  
manifesting a problem here.  
  
While at it, move "numrows" processing out of the line of special cases,  
and make it getopt's -r instead.  (A similar thing could be done to  
'conninfo', but current use of the program doesn't warrant spending time  
on that -- nowhere else we use conninfo in so simplistic a manner.)  
  
Discussion: https://postgr.es/m/20210401124850.GA19247@alvherre.pgsql  

commit   : f82de5c46bdf8cd65812a7b04c9509c218e1545d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Apr 2021 12:23:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Apr 2021 12:23:40 +0300    

This gives a small performance gain, by reducing the number of calls  
to the conversion/verification function, and letting it work with  
larger inputs. Also, reorganizing the input pipeline makes it easier  
to parallelize the input parsing: after the input has been converted  
to the database encoding, the next stage of finding the newlines can  
be done in parallel, because there cannot be any newline chars  
"embedded" in multi-byte characters in the encodings that we support  
as server encodings.  
  
This changes behavior in one corner case: if client and server  
encodings are the same single-byte encoding (e.g. latin1), previously  
the input would not be checked for zero bytes ('\0'). Any fields  
containing zero bytes would be truncated at the zero. But if encoding  
conversion was needed, the conversion routine would throw an error on  
the zero. After this commit, the input is always checked for zeros.  
  
Reviewed-by: John Naylor  
Discussion: https://www.postgresql.org/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi  

commit   : ea1b99a6619cd9dcfd46b82ac0d926b0b80e0ae9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Apr 2021 11:45:22 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Apr 2021 11:45:22 +0300    

With the 'noError' argument, you can try to convert a buffer without  
knowing the character boundaries beforehand. The functions now need to  
return the number of input bytes successfully converted.  
  
This is is a backwards-incompatible change, if you have created a custom  
encoding conversion with CREATE CONVERSION. This adds a check to  
pg_upgrade for that, refusing the upgrade if there are any user-defined  
encoding conversions. Custom conversions are very rare, there are no  
commonly used extensions that I know of that uses that feature. No other  
objects can depend on conversions, so if you do have one, you can fairly  
easily drop it before upgrading, and recreate it after the upgrade with  
an updated version.  
  
Add regression tests for built-in encoding conversions. This doesn't cover  
every conversion, but it covers all the internal functions in conv.c that  
are used to implement the conversions.  
  
Reviewed-by: John Naylor  
Discussion: https://www.postgresql.org/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi  

commit   : e2639a767bfa1afebaf1877515a1187feb393443    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Apr 2021 09:52:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Apr 2021 09:52:03 +0200    

Use a time zone offset with nonzero minutes to make the  
timezone_minute test meaningful.  

commit   : ffd3391ea94165fbb5adc9534894c62d41138505    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Apr 2021 15:28:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Apr 2021 15:28:37 +0900    

Some sections of the documentation used "exclusive lock" to describe  
that an ACCESS EXCLUSIVE lock is taken during a given operation.  This  
can be confusing to the reader as ACCESS SHARE is allowed with an  
EXCLUSIVE lock is used, but that would not be the case with what is  
described on those parts of the documentation.  
  
Author: Greg Rychlewski  
Discussion: https://postgr.es/m/CAKemG7VptD=7fNWckFMsMVZL_zzvgDO6v2yVmQ+ZiBfc_06kCQ@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 4778826532a62fd6e4d3fdeef9532c943604c730    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 1 Apr 2021 07:57:34 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 1 Apr 2021 07:57:34 +0530    

It is possible that while decoding a prepared transaction, it gets aborted  
concurrently via a ROLLBACK PREPARED command. In that case, we were  
skipping all the changes and directly sending Rollback Prepared when we  
find the same in WAL. However, the downstream has no idea of the GID of  
such a transaction. So, ensure to send prepare even when a concurrent  
abort is detected.  
  
Author: Ajin Cherian  
Reviewed-by: Markus Wanner, Amit Kapila  
Discussion: https://postgr.es/m/f82133c6-6055-b400-7922-97dae9f2b50b@enterprisedb.com  

commit   : 0d1a33438d3a88938264e12e94c22818307d2f4d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Apr 2021 09:48:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Apr 2021 09:48:17 +0900    

test_connect_ok() and test_connect_fails() have always been part of the  
SSL tests, and check if a connection to the backend should work or not,  
and there are sanity checks done on specific error patterns dropped by  
libpq if the connection fails.  
  
This was fundamentally wrong on two aspects.  First, SSLServer.pm works  
mostly on setting up and changing the SSL configuration of a  
PostgresNode, and has really nothing to do with the client.  Second,  
the situation became worse in light of b34ca595, where the SSL tests  
would finish by using a psql command that may not come from the same  
installation as the node set up.  
  
This commit moves those client routines into PostgresNode, making easier  
the refactoring of SSLServer to become more SSL-implementation aware.  
This can also be reused by the ldap, kerberos and authentication test  
suites for connection checks, and a follow-up patch should extend those  
interfaces to match with backend log patterns.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan, Daniel Gustafsson, Álvaro Herrera  
Discussion: https://postgr.es/m/YGLKNBf9zyh6+WSt@paquier.xyz  

commit   : 28b3e3905c982c42fb10ee800e6f881e9742c89d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Apr 2021 13:33:23 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Apr 2021 13:33:23 +1300    

This removes "Add Result Cache executor node".  It seems that something  
weird is going on with the tracking of cache hits and misses as  
highlighted by many buildfarm animals.  It's not yet clear what the  
problem is as other parts of the plan indicate that the cache did work  
correctly, it's just the hits and misses that were being reported as 0.  
  
This is especially a bad time to have the buildfarm so broken, so  
reverting before too many more animals go red.  
  
Discussion: https://postgr.es/m/CAApHDvq_hydhfovm4=izgWs+C5HqEeRScjMbOgbpC-jRAeK3Yw@mail.gmail.com  

commit   : b6002a796dc0bfe721db5eaa54ba9d24fd9fd416    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Apr 2021 12:32:22 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Apr 2021 12:32:22 +1300    

Here we add a new executor node type named "Result Cache".  The planner  
can include this node type in the plan to have the executor cache the  
results from the inner side of parameterized nested loop joins.  This  
allows caching of tuples for sets of parameters so that in the event that  
the node sees the same parameter values again, it can just return the  
cached tuples instead of rescanning the inner side of the join all over  
again.  Internally, result cache uses a hash table in order to quickly  
find tuples that have been previously cached.  
  
For certain data sets, this can significantly improve the performance of  
joins.  The best cases for using this new node type are for join problems  
where a large portion of the tuples from the inner side of the join have  
no join partner on the outer side of the join.  In such cases, hash join  
would have to hash values that are never looked up, thus bloating the hash  
table and possibly causing it to multi-batch.  Merge joins would have to  
skip over all of the unmatched rows.  If we use a nested loop join with a  
result cache, then we only cache tuples that have at least one join  
partner on the outer side of the join.  The benefits of using a  
parameterized nested loop with a result cache increase when there are  
fewer distinct values being looked up and the number of lookups of each  
value is large.  Also, hash probes to lookup the cache can be much faster  
than the hash probe in a hash join as it's common that the result cache's  
hash table is much smaller than the hash join's due to result cache only  
caching useful tuples rather than all tuples from the inner side of the  
join.  This variation in hash probe performance is more significant when  
the hash join's hash table no longer fits into the CPU's L3 cache, but the  
result cache's hash table does.  The apparent "random" access of hash  
buckets with each hash probe can cause a poor L3 cache hit ratio for large  
hash tables.  Smaller hash tables generally perform better.  
  
The hash table used for the cache limits itself to not exceeding work_mem  
* hash_mem_multiplier in size.  We maintain a dlist of keys for this cache  
and when we're adding new tuples and realize we've exceeded the memory  
budget, we evict cache entries starting with the least recently used ones  
until we have enough memory to add the new tuples to the cache.  
  
For parameterized nested loop joins, we now consider using one of these  
result cache nodes in between the nested loop node and its inner node.  We  
determine when this might be useful based on cost, which is primarily  
driven off of what the expected cache hit ratio will be.  Estimating the  
cache hit ratio relies on having good distinct estimates on the nested  
loop's parameters.  
  
For now, the planner will only consider using a result cache for  
parameterized nested loop joins.  This works for both normal joins and  
also for LATERAL type joins to subqueries.  It is possible to use this new  
node for other uses in the future.  For example, to cache results from  
correlated subqueries.  However, that's not done here due to some  
difficulties obtaining a distinct estimation on the outer plan to  
calculate the estimated cache hit ratio.  Currently we plan the inner plan  
before planning the outer plan so there is no good way to know if a result  
cache would be useful or not since we can't estimate the number of times  
the subplan will be called until the outer plan is generated.  
  
The functionality being added here is newly introducing a dependency on  
the return value of estimate_num_groups() during the join search.  
Previously, during the join search, we only ever needed to perform  
selectivity estimations.  With this commit, we need to use  
estimate_num_groups() in order to estimate what the hit ratio on the  
result cache will be.   In simple terms, if we expect 10 distinct values  
and we expect 1000 outer rows, then we'll estimate the hit ratio to be  
99%.  Since cache hits are very cheap compared to scanning the underlying  
nodes on the inner side of the nested loop join, then this will  
significantly reduce the planner's cost for the join.   However, it's  
fairly easy to see here that things will go bad when estimate_num_groups()  
incorrectly returns a value that's significantly lower than the actual  
number of distinct values.  If this happens then that may cause us to make  
use of a nested loop join with a result cache instead of some other join  
type, such as a merge or hash join.  Our distinct estimations have been  
known to be a source of trouble in the past, so the extra reliance on them  
here could cause the planner to choose slower plans than it did previous  
to having this feature.  Distinct estimations are also fairly hard to  
estimate accurately when several tables have been joined already or when a  
WHERE clause filters out a set of values that are correlated to the  
expressions we're estimating the number of distinct value for.  
  
For now, the costing we perform during query planning for result caches  
does put quite a bit of faith in the distinct estimations being accurate.  
When these are accurate then we should generally see faster execution  
times for plans containing a result cache.  However, in the real world, we  
may find that we need to either change the costings to put less trust in  
the distinct estimations being accurate or perhaps even disable this  
feature by default.  There's always an element of risk when we teach the  
query planner to do new tricks that it decides to use that new trick at  
the wrong time and causes a regression.  Users may opt to get the old  
behavior by turning the feature off using the enable_resultcache GUC.  
Currently, this is enabled by default.  It remains to be seen if we'll  
maintain that setting for the release.  
  
Additionally, the name "Result Cache" is the best name I could think of  
for this new node at the time I started writing the patch.  Nobody seems  
to strongly dislike the name. A few people did suggest other names but no  
other name seemed to dominate in the brief discussion that there was about  
names. Let's allow the beta period to see if the current name pleases  
enough people.  If there's some consensus on a better name, then we can  
change it before the release.  Please see the 2nd discussion link below  
for the discussion on the "Result Cache" name.  
  
Author: David Rowley  
Reviewed-by: Andy Fan, Justin Pryzby, Zhihong Yu  
Tested-By: Konstantin Knizhnik  
Discussion: https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com  
Discussion: https://postgr.es/m/CAApHDvq=yQXr5kqhRviT2RhNKwToaWr9JAN5t+5_PzhuRJ3wvg@mail.gmail.com  

commit   : 6ec578e60101c3c02533f99715945a0400fb3286    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 20:11:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 20:11:51 -0300    

It's misplaced there -- it's not libpq's output stream to tweak in that  
way.  In particular, POSIX says that it has to be called before any  
other operation on the file, so if a stream previously used by the  
calling application, bad things may happen.  
  
Put setvbuf() in libpq_pipeline for good measure.  
  
Also, reduce fopen(..., "w+") to just fopen(..., "w") in  
libpq_pipeline.c.  It's not clear that this fixes anything, but we don't  
use w+ anywhere.  
  
Per complaints from Tom Lane.  
  
Discussion: https://postgr.es/m/3337422.1617229905@sss.pgh.pa.us  

commit   : aba24b51cc1b045a9810458b4bb15fee2c182948    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 19:16:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 19:16:58 -0300    

Failing to do this can cause a crash, and I suspect is what has happened  
with a buildfarm member reporting mysterious failures.  
  
This is an ancient bug, but I'm not backpatching since evidently nobody  
cares about PQtrace in older releases.  
  
Discussion: https://postgr.es/m/3333908.1617227066@sss.pgh.pa.us  

commit   : a6d3dea8e5e0c8a0df2f95d66b6c3903a4354ca0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 18:45:17 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 18:45:17 -0300    

Some buildfarm animals with force_parallel_mode=regress were failing  
this test because the error is reported in a parallel worker quicker  
than the rows that succeed.  
  
Take the opportunity to move the SET of lc_messages out of the traced  
section, because it's not very interesting.  
  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3304521.1617221724@sss.pgh.pa.us  

commit   : 9e20406dd847d0f8c1cbd803786c6d0ad33bcbdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 17:14:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 17:14:16 -0400    

We must cast the arguments of <ctype.h> functions to unsigned  
char to avoid problems where char is signed.  
  
Speaking of which, considering that this *is* a <ctype.h> function,  
it's rather remarkable that we aren't seeing more complaints about  
not having included that header.  
  
Per buildfarm.  

commit   : f1be740a991406d7885047beb971e1ff5dbe8b71    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 17:00:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 17:00:30 -0400    

Remove confusion between time_t and pg_time_t; neither  
gettimeofday() nor localtime() deal in the latter.  
libpq indeed has no business using <pgtime.h> at all.  
  
Use snprintf not sprintf, to ensure we can't overrun the  
supplied buffer.  (Unlikely, but let's be safe.)  
  
Per buildfarm.  

commit   : 8998e3cafa23632790787b8cc726998e84067259    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 16:50:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 16:50:45 -0400    

Per buildfarm.  

commit   : c545e9524dcfcfce25c370f584b31562e8d7a4b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 16:45:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 16:45:17 -0400    

Since a4d75c86b, some buildfarm members have been warning that  
		Assert(attnum <= MaxAttrNumber);  
is useless if attnum is an AttrNumber.  I'm not certain how plausible  
it is that the value coming out of the bitmap could actually exceed  
MaxAttrNumber, but we seem to have thought that that was possible back  
in 7300a6995.  Revert the intermediate variable to int so that we have  
the same overflow protection as before.  

commit   : 3b0c647bbfc52894d979976f1e6d60e40649bba7    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 31 Mar 2021 16:23:25 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 31 Mar 2021 16:23:25 -0400    

The new appendix groups information on renamed or removed settings,  
commands, etc into an out-of-the-way part of the docs.  
  
The original id elements are retained in each subsection to ensure that  
the same filenames are produced for HTML docs. This prevents /current/  
links on the web from breaking, and allows users of the web docs  
to follow links from old version pages to info on the changes in the  
new version. Prior to this change, a link to /current/ for renamed  
sections like the recovery.conf docs would just 404. Similarly if  
someone searched for recovery.conf they would find the pg11 docs,  
but there would be no /12/ or /current/ link, so they couldn't easily  
find out that it was removed in pg12 or how to adapt.  
  
Index entries are also added so that there's a breadcrumb trail for  
users to follow when they know the old name, but not what we changed it  
to. So a user who is trying to find out how to set standby_mode in  
PostgreSQL 12+, or where pg_resetxlog went, now has more chance of  
finding that information.  
  
Craig Ringer and Stephen Frost  
Reviewed-by: Euler Taveira  
Discussion: https://postgr.es/m/CAGRY4nzPNOyYQ_1-pWYToUVqQ0ThqP5jdURnJMZPm539fdizOg%40mail.gmail.com  
Backpatch-through: 10  

commit   : 522d1a89f8d7ed45681988c60bd0a687332a4023    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 15:30:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 15:30:04 -0400    

Some compilers seem to be concerned about the possibility that  
recv_step is not any of the defined enum values.  Silence  
warnings about uninitialized cmdtag in a different way than  
I did in 9fb9691a8.  

commit   : 6197db5340b8154adce1c6d07f6d3325547429c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 15:25:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 15:25:53 -0400    

Put the remote end's error message into the primary error string,  
instead of relegating it to errdetail().  Although this could end up  
being awkward if the remote sends us a really long error message,  
it seems more in keeping with our message style guidelines, and more  
helpful in situations where the errdetail could get dropped.  
  
Peter Smith  
  
Discussion: https://postgr.es/m/CAHut+Ps-Qv2yQceCwobQDP0aJOkfDzRFrOaR6+2Op2K=WHGeWg@mail.gmail.com  

commit   : db973ffb3ca43e65a0bf15175a35184a53bf977d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 15:13:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Mar 2021 15:13:42 -0300    

Test pipeline_abort was not checking that it got the rows it expected in  
one mode; make it do so.  This doesn't fix the actual problem (no idea  
what that is, yet) but at least it should make it more obvious rather  
than being visible only as a difference in the trace output.  
  
While at it, fix other infelicities in the test:  
  
* I reversed the order of result vs. expected in like().  
  
* The output traces from -t are being put in the log dir, which means  
the buildfarm script uselessly captures them.  Put them in a separate  
dir tmp_check/traces instead, to avoid cluttering the buildfarm results.  
  
* Test pipelined_insert was using too large a row count.  Reduce that a  
tad and add a filler column to make each insert a little bulkier, while  
still keeping enough that a buffer is filled and we have to switch mode.  

commit   : b12bd4869b5e64b742a69ca07915e2f77f85a9ae    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 31 Mar 2021 13:55:25 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 31 Mar 2021 13:55:25 -0400    

According to the comments, when an invalid or dropped column oid is passed  
to has_column_privilege(), the intention has always been to return NULL.  
However, when the caller had table level privilege the invalid/missing  
column was never discovered, because table permissions were checked first.  
  
Fix that by introducing extended versions of pg_attribute_acl(check|mask)  
and pg_class_acl(check|mask) which take a new argument, is_missing. When  
is_missing is NULL, the old behavior is preserved. But when is_missing is  
passed by the caller, no ERROR is thrown for dropped or missing  
columns/relations, and is_missing is flipped to true. This in turn allows  
has_column_privilege to check for column privileges first, providing the  
desired semantics.  
  
Not backpatched since it is a user visible behavioral change with no previous  
complaints, and the fix is a bit on the invasive side.  
  
Author: Joe Conway  
Reviewed-By: Tom Lane  
Reported by: Ian Barwick  
Discussion: https://postgr.es/m/flat/9b5f4311-157b-4164-7fe7-077b4fe8ed84%40joeconway.com  

commit   : 86dc90056dfdbd9d1b891718d2e5614e3e432f35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 11:52:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Mar 2021 11:52:34 -0400    

This patch makes two closely related sets of changes:  
  
1. For UPDATE, the subplan of the ModifyTable node now only delivers  
the new values of the changed columns (i.e., the expressions computed  
in the query's SET clause) plus row identity information such as CTID.  
ModifyTable must re-fetch the original tuple to merge in the old  
values of any unchanged columns.  The core advantage of this is that  
the changed columns are uniform across all tables of an inherited or  
partitioned target relation, whereas the other columns might not be.  
A secondary advantage, when the UPDATE involves joins, is that less  
data needs to pass through the plan tree.  The disadvantage of course  
is an extra fetch of each tuple to be updated.  However, that seems to  
be very nearly free in context; even worst-case tests don't show it to  
add more than a couple percent to the total query cost.  At some point  
it might be interesting to combine the re-fetch with the tuple access  
that ModifyTable must do anyway to mark the old tuple dead; but that  
would require a good deal of refactoring and it seems it wouldn't buy  
all that much, so this patch doesn't attempt it.  
  
2. For inherited UPDATE/DELETE, instead of generating a separate  
subplan for each target relation, we now generate a single subplan  
that is just exactly like a SELECT's plan, then stick ModifyTable  
on top of that.  To let ModifyTable know which target relation a  
given incoming row refers to, a tableoid junk column is added to  
the row identity information.  This gets rid of the horrid hack  
that was inheritance_planner(), eliminating O(N^2) planning cost  
and memory consumption in cases where there were many unprunable  
target relations.  
  
Point 2 of course requires point 1, so that there is a uniform  
definition of the non-junk columns to be returned by the subplan.  
We can't insist on uniform definition of the row identity junk  
columns however, if we want to keep the ability to have both  
plain and foreign tables in a partitioning hierarchy.  Since  
it wouldn't scale very far to have every child table have its  
own row identity column, this patch includes provisions to merge  
similar row identity columns into one column of the subplan result.  
In particular, we can merge the whole-row Vars typically used as  
row identity by FDWs into one column by pretending they are type  
RECORD.  (It's still okay for the actual composite Datums to be  
labeled with the table's rowtype OID, though.)  
  
There is more that can be done to file down residual inefficiencies  
in this patch, but it seems to be committable now.  
  
FDW authors should note several API changes:  
  
* The argument list for AddForeignUpdateTargets() has changed, and so  
has the method it must use for adding junk columns to the query.  Call  
add_row_identity_var() instead of manipulating the parse tree directly.  
You might want to reconsider exactly what you're adding, too.  
  
* PlanDirectModify() must now work a little harder to find the  
ForeignScan plan node; if the foreign table is part of a partitioning  
hierarchy then the ForeignScan might not be the direct child of  
ModifyTable.  See postgres_fdw for sample code.  
  
* To check whether a relation is a target relation, it's no  
longer sufficient to compare its relid to root->parse->resultRelation.  
Instead, check it against all_result_relids or leaf_result_relids,  
as appropriate.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/CA+HiwqHpHdqdDn48yCEhynnniahH78rwcrv1rEX65-fsZGBOLQ@mail.gmail.com  

commit   : 055fee7eb4dcc78e58672aef146334275e1cc40d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 17:09:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 17:09:24 +0200    

This allows something like  
  
    SELECT ... FROM t1 JOIN t2 USING (a, b, c) AS x  
  
where x has the columns a, b, c and unlike a regular alias it does not  
hide the range variables of the tables being joined t1 and t2.  
  
Per SQL:2016 feature F404 "Range variable for common column names".  
  
Reviewed-by: Vik Fearing <vik.fearing@2ndquadrant.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/454638cf-d563-ab76-a585-2564428062af@2ndquadrant.com  

commit   : 27e1f14563cf982f1f4d71e21ef247866662a052    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 31 Mar 2021 18:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 31 Mar 2021 18:45:00 +0900    

This implements asynchronous execution, which runs multiple parts of a  
non-parallel-aware Append concurrently rather than serially to improve  
performance when possible.  Currently, the only node type that can be  
run concurrently is a ForeignScan that is an immediate child of such an  
Append.  In the case where such ForeignScans access data on different  
remote servers, this would run those ForeignScans concurrently, and  
overlap the remote operations to be performed simultaneously, so it'll  
improve the performance especially when the operations involve  
time-consuming ones such as remote join and remote aggregation.  
  
We may extend this to other node types such as joins or aggregates over  
ForeignScans in the future.  
  
This also adds the support for postgres_fdw, which is enabled by the  
table-level/server-level option "async_capable".  The default is false.  
  
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself.  This commit  
is mostly based on the patch proposed by Robert Haas, but also uses  
stuff from the patch proposed by Kyotaro Horiguchi and from the patch  
proposed by Thomas Munro.  Reviewed by Kyotaro Horiguchi, Konstantin  
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and  
others.  
  
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com  
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com  
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com  

commit   : 66392d396508c91c2ec07a61568bf96acb663ad8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 10:52:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 10:52:37 +0200    

ParseNamespaceItem had a wired-in assumption that p_rte->eref  
describes the table and column aliases exposed by the nsitem.  This  
relaxes this by creating a separate p_names field in an nsitem.  This  
is mainly preparation for a patch for JOIN USING aliases, but it saves  
one indirection in common code paths, so it's possibly a win on its  
own.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/785329.1616455091@sss.pgh.pa.us  

commit   : 91c5a8caaa61055959aa5fb68a00e5f690e39a34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 09:15:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 09:15:51 +0200    

Similar to existing errmsg_plural() and errdetail_plural().  Some  
errhint() calls hadn't received the proper plural treatment yet.  

commit   : 287d2a97c1de07486e4525c8ad06258f04bd6268    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 08:20:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Mar 2021 08:20:35 +0200    

Not supported by PDF build right now, so let's do without it.  

commit   : 13cb5bd84657ed49021fe6fc4ce46601c315c9a5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 31 Mar 2021 10:36:39 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 31 Mar 2021 10:36:39 +0530    

Author: Suraj Kharage  
Reviewed-by: Bharath Rupireddy, Vignesh C  
Discussion: https://postgr.es/m/CAF1DzPWRfxUeH-wShz7P_pK5Tx6M_nEK+TkS8gn5ngvg07Q5=g@mail.gmail.com  

commit   : 9f45631766bd0c51a74102770737ba3b0561977e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 31 Mar 2021 08:17:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 31 Mar 2021 08:17:50 +0530    

At some places in the docs, we refer to them as tablesync slots and at other  
places as table synchronization slots. For consistency, we refer to them as  
table synchronization slots at all places.  
  
Author: Peter Smith  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAHut+PvzYNKCeZ=kKBDkh3dw-r=2D3fk=nNc9SXSW=CZGk69xg@mail.gmail.com  

commit   : 0ff8bbdee19a9db2794a95d439c946ab017d0acd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 30 Mar 2021 18:53:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 30 Mar 2021 18:53:44 -0700    

We always inserted a larger-than-fillfactor tuple into a newly-extended  
page, even when existing pages were empty or contained nothing but an  
unused line pointer.  This was unnecessary relation extension.  Start  
tolerating page usage up to 1/8 the maximum space that could be taken up  
by line pointers.  This is somewhat arbitrary, but it should allow more  
cases to reuse pages.  This has no effect on tables with fillfactor=100  
(the default).  
  
John Naylor and Floris van Nee.  Reviewed by Matthias van de Meent.  
Reported by Floris van Nee.  
  
Discussion: https://postgr.es/m/6e263217180649339720afe2176c50aa@opammb0562.comp.optiver.com  

commit   : 7ef64e7e72a65f191fc2f7d4bbe220f53dd8d5de    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Mar 2021 09:35:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Mar 2021 09:35:58 +0900    

CreateStmt->inhRelations is a list of RangeVars, but a comment was  
incorrect about that.  
  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/20210330123015.yzekhz5sweqbgxdr@nol  

commit   : 6568cef26e0f40c25ae54b8e20aad8d1410a854b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Mar 2021 09:12:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Mar 2021 09:12:34 +0900    

When specified, only extensions matching the given pattern are included  
in dumps.  Similarly to --table and --schema, when --strict-names is  
used,  a perfect match is required.  Also, like the two other options,  
this new option offers no guarantee that dependent objects have been  
dumped, so a restore may fail on a clean database.  
  
Tests are added in test_pg_dump/, checking after a set of positive and  
negative cases, with or without an extension's contents added to the  
dump generated.  
  
Author: Guillaume Lelarge  
Reviewed-by: David Fetter, Tom Lane, Michael Paquier, Asif Rehman,  
Julien Rouhaud  
Discussion: https://postgr.es/m/CAECtzeXOt4cnMU5+XMZzxBPJ_wu76pNy6HZKPRBL-j7yj1E4+g@mail.gmail.com  

commit   : 65158f497a7d7523ad438b2034d01a560fafe6bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Mar 2021 20:01:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Mar 2021 20:01:27 -0400    

Whilst poking at nodeModifyTable.c, I chanced to notice that while  
its calls to ExecBR*Triggers and ExecIR*Triggers are protected by  
tests to see if there are any relevant triggers to fire, its calls  
to ExecAR*Triggers are not; the latter functions do the equivalent  
tests themselves.  This seems possibly reasonable given the more  
complex conditions involved, but what's less reasonable is that  
the ExecAR* functions aren't careful to do no work when there is  
no work to be done.  ExecARInsertTriggers gets this right, but the  
other two will both force creation of a slot that the query may  
have no use for.  ExecARUpdateTriggers additionally performed a  
usually-useless ExecClearTuple() on that slot.  This is probably  
all pretty microscopic in real workloads, but a cycle shaved is a  
cycle earned.  

commit   : 9ee7d533dacf8594057ced2d016250f09056c284    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Mar 2021 19:46:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Mar 2021 19:46:22 -0400    

Seems the -1/singular output is used in the dblink regression tests.  
  
Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/20210330231506.GA10666@alvherre.pgsql  

commit   : 7bebd0d00998a28449d83376f4bcdeec65d5eea6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Mar 2021 20:33:04 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Mar 2021 20:33:04 -0300    

The libpq_pipeline program recently introduced by commit acb7e4eb6b1c  
is well equipped to test the PQtrace() functionality, so let's make it  
do that.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210327192812.GA25115@alvherre.pgsql  

commit   : 198b3716dba68544b55cb97bd120738a86d5df2d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Mar 2021 20:12:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Mar 2021 20:12:34 -0300    

Transform the PQtrace output format from its ancient (and mostly  
useless) byte-level output format to a logical-message-level output,  
making it much more usable.  This implementation allows the printing  
code to be written (as it indeed was) by looking at the protocol  
documentation, which gives more confidence that the three (docs, trace  
code and actual code) actually match.  
  
Author: 岩田 彩 (Aya Iwata) <iwata.aya@fujitsu.com>  
Reviewed-by: 綱川 貴之 (Takayuki Tsunakawa) <tsunakawa.takay@fujitsu.com>  
Reviewed-by: Kirk Jamison <k.jamison@fujitsu.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: 黒田 隼人 (Hayato Kuroda) <kuroda.hayato@fujitsu.com>  
Reviewed-by: "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>  
Reviewed-by: Ryo Matsumura <matsumura.ryo@fujitsu.com>  
Reviewed-by: Greg Nancarrow <gregn4422@gmail.com>  
Reviewed-by: Jim Doty <jdoty@pivotal.io>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/71E660EB361DF14299875B198D4CE5423DE3FBA4@g01jpexmbkw25  

commit   : 5da9868ed983f95cc1cff80dcd81252a513774f8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Mar 2021 18:34:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Mar 2021 18:34:27 -0400    

This outputs "-1 year", not "-1 years".  
  
Reported-by: neverov.max@gmail.com  
  
Bug: 16939  
  
Discussion: https://postgr.es/m/16939-cceeb03fb72736ee@postgresql.org  

commit   : 6131ffc43ff3d2f566e93f017e56a09e4e717318    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 30 Mar 2021 22:05:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 30 Mar 2021 22:05:18 +0200    

This exercises a special case in the implementations of  
date_part('epoch', timestamp[tz]) that was previously not tested.  

commit   : 4753ef37e0eda4ba0af614022d18fcbc5a946cc9    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 30 Mar 2021 12:52:56 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 30 Mar 2021 12:52:56 -0400    

Instead of using pg_usleep() in vacuum_delay_point(), use a WaitLatch.  
This has the advantage that we will realize if the postmaster has been  
killed since the last time we decided to sleep while vacuuming.  
  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/CAFh8B=kcdk8k-Y21RfXPu5dX=bgPqJ8TC3p_qxR_ygdBS=JN5w@mail.gmail.com  

commit   : 54bb91c30e3964fd81059e6b02e377cc9dd2d64c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Mar 2021 10:57:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Mar 2021 10:57:57 -0400    

As committed in bbe0a81db, pg_dump from a pre-v14 server effectively  
acts as though you'd said --no-toast-compression.  I think the right  
thing is for it to act as though default_toast_compression is set to  
"pglz", instead, so that the tables' toast compression behavior is  
preserved.  You can always get the other behavior, if you want that,  
by giving the switch.  
  
Discussion: https://postgr.es/m/1112852.1616609702@sss.pgh.pa.us  

commit   : ed934d4fa30f0f94e6f7125ad2154e6a58d1c7f7    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 20:52:46 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 20:52:46 +1300    

Here we add a new output parameter to estimate_num_groups() to allow it to  
inform the caller of additional, possibly useful information about the  
estimation.  
  
The new output parameter is a struct that currently contains just a single  
field with a set of flags.  This was done rather than having the flags as  
an output parameter to allow future fields to be added without having to  
change the signature of the function at a later date when we want to pass  
back further information that might not be suitable to store in the flags  
field.  
  
It seems reasonable that one day in the future that the planner would want  
to know more about the estimation. For example, how many individual sets  
of statistics was the estimation generated from?  The planner may want to  
take that into account if we ever want to consider risks as well as costs  
when generating plans.  
  
For now, there's only 1 flag we set in the flags field.  This is to  
indicate if the estimation fell back on using the hard-coded constants in  
any part of the estimation. Callers may like to change their behavior if  
this is set, and this gives them the ability to do so.  Callers may pass  
the flag pointer as NULL if they have no interest in obtaining any  
additional information about the estimate.  
  
We're not adding any actual usages of these flags here.  Some follow-up  
commits will make use of this feature.  Additionally, we're also not  
making any changes to add support for clauselist_selectivity() and  
clauselist_selectivity_ext().  However, if this is required in the future  
then the same struct being added here should be fine to use as a new  
output argument for those functions too.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/CAApHDvqQqpk=1W-G_ds7A9CsXX3BggWj_7okinzkLVhDubQzjA@mail.gmail.com  

commit   : efd9d92bb39c74c2aded64fc08e2d601ce20c39d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 20:28:09 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 20:28:09 +1300    

Some compilers are not aware that elog/ereport ERROR does not return.  

commit   : ff53d7b159b93ce9fc884897f9d96b97744781e2    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 19:56:50 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 19:56:50 +1300    

Previously simplehash.h only exposed a method to perform a hash table  
delete using the hash table key. This meant that the delete function had  
to perform a hash lookup in order to find the entry to delete.  Here we  
add a new function so that users of simplehash.h can perform a hash delete  
directly using the entry pointer, thus saving the hash lookup.  
  
An upcoming patch that uses simplehash.h already has performed the hash  
lookup so already has the entry pointer.  This change will allow the  
code in that patch to perform the hash delete without the code in  
simplehash.h having to perform an additional hash lookup.  
  
Author: David Rowley  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CAApHDvqFLXXge153WmPsjke5VGOSt7Ez0yD0c7eBXLfmWxs3Kw@mail.gmail.com  

commit   : bc9f1afdebc98b490d0a00468d75e8e4d080afb0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 30 Mar 2021 08:46:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 30 Mar 2021 08:46:34 +0200    

The existing regression tests only tested the lower boundary of the  
range supported by the timestamp and timestamptz types because "The  
upper boundary differs between integer and float timestamps, so no  
check".  Since this is obsolete, add similar tests for the upper  
boundary.  

commit   : f64ea6dc5c8ccaec9a3d3d39695ca261febb6883    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 30 Mar 2021 10:34:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 30 Mar 2021 10:34:43 +0530    

Along with gid, this provides a different way to identify the transaction.  
The users that use xid in some way to prepare the transactions can use it  
to filter prepare transactions. The later commands COMMIT PREPARED or  
ROLLBACK PREPARED carries both identifiers, providing an output plugin the  
choice of what to use.  
  
Author: Markus Wanner  
Reviewed-by: Vignesh C, Amit Kapila  
Discussion: https://postgr.es/m/ee280000-7355-c4dc-e47b-2436e7be959c@enterprisedb.com  

commit   : bc2797ebb14bae663da1ee7845774dd98716c0d0    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 30 Mar 2021 13:00:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 30 Mar 2021 13:00:00 +0900    

Back-patch to all supported branches.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com  

commit   : 8d645a116ef6e04bfb03e259149b8e163dbdf50c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Mar 2021 18:34:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Mar 2021 18:34:39 -0300    

We were never doing clearerr() on the output stream, which results in a  
message being printed after each result once an EOF is seen:  
  
could not print result table: Success  
  
This message was added by commit b03436994bcc (in the pg13 era); before  
that, the error indicator would never be examined.  So backpatch only  
that far back, even though the actual bug (to wit: the fact that the  
error indicator is never cleared) is older.  

commit   : af527705edc3fd0b335264d17e0521c05edc5cca    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 10:17:09 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 30 Mar 2021 10:17:09 +1300    

The design of the data structures which allow storage of the per-worker  
memory during parallel seq scans were not ideal. The work done in  
56788d215 required an additional data structure to allow workers to  
remember the range of pages that had been allocated to them for  
processing during a parallel seqscan.  That commit added a void pointer  
field to TableScanDescData to allow heapam to store the per-worker  
allocation information.  However putting the field there made very little  
sense given that we have AM specific structs for that, e.g.  
HeapScanDescData.  
  
Here we remove the void pointer field from TableScanDescData and add a  
dedicated field for this purpose to HeapScanDescData.  
  
Previously we also allocated memory for this parallel per-worker data for  
all scans, regardless if it was a parallel scan or not.  This was just a  
wasted allocation for non-parallel scans, so here we make the allocation  
conditional on the scan being parallel.  
  
Also, add previously missing pfree() to free the per-worker data in  
heap_endscan().  
  
Reported-by: Andres Freund  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/20210317023101.anvejcfotwka6gaa@alap3.anarazel.de  

commit   : 6d7a6feac48b1970c4cd127ee65d4c487acbb5e9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 29 Mar 2021 15:31:22 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 29 Mar 2021 15:31:22 -0400    

Currently we only recognize the Common Name (CN) of a certificate's  
subject to be matched against the user name. Thus certificates with  
subjects '/OU=eng/CN=fred' and '/OU=sales/CN=fred' will have the same  
connection rights. This patch provides an option to match the whole  
Distinguished Name (DN) instead of just the CN. On any hba line using  
client certificate identity, there is an option 'clientname' which can  
have values of 'DN' or 'CN'. The default is 'CN', the current procedure.  
  
The DN is matched against the RFC2253 formatted DN, which looks like  
'CN=fred,OU=eng'.  
  
This facility of probably best used in conjunction with an ident map.  
  
Discussion: https://postgr.es/m/92e70110-9273-d93c-5913-0bccb6562740@dunslane.net  
  
Reviewed-By: Michael Paquier, Daniel Gustafsson, Jacob Champion  

commit   : efcc7572f532ea564fedc6359c2df43045ee7908    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Mar 2021 17:53:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Mar 2021 17:53:30 +0200    

Some tests for timestamp and timestamptz were in the date.sql test  
file.  Move them to their appropriate files, or drop tests cases that  
were already present there.  

commit   : f37fec837ce8bf7af408ba66d32099e5a0182402    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 28 Mar 2021 08:16:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 28 Mar 2021 08:16:15 +0200    

This allows decoding a string with Unicode escape sequences.  It is  
similar to Unicode escape strings, but offers some more flexibility.  
  
Author: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Asif Rehman <asifr.rehman@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAFj8pRA5GnKT+gDVwbVRH2ep451H_myBt+NTz8RkYUARE9+qOQ@mail.gmail.com  

commit   : ebedd0c78fc51c293abe56e99a18c67af14da0c9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Mar 2021 08:40:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Mar 2021 08:40:39 +0200    

After some tests relating to standard_conforming_strings behavior, the  
value was not reset to the default value.  Therefore, the rest of the  
tests in that file ran with the nondefault setting, which affected the  
results of some tests.  For clarity, reset the value and run the rest  
of the tests with the default setting again.  

commit   : 30aaab26e52144097a1a5bbb0bb66ea1ebc0cb81    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 28 Mar 2021 20:10:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 28 Mar 2021 20:10:02 -0700    

Assert that LP_UNUSED items have no storage.  If it's worth having  
defensive code in non-assert builds then it's worth having an assertion  
as well.  

commit   : f58b230ed0dba2a3d396794a2ec84541e321d92d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 29 Mar 2021 14:47:05 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 29 Mar 2021 14:47:05 +1300    

Here we aim to reduce duplicate work done by contain_volatile_functions()  
by caching whether PathTargets and RestrictInfos contain any volatile  
functions the first time contain_volatile_functions() is called for them.  
Any future calls for these nodes just use the cached value rather than  
going to the trouble of recursively checking the sub-node all over again.  
Thanks to Tom Lane for the idea.  
  
Any locations in the code which make changes to a PathTarget or  
RestrictInfo which could change the outcome of the volatility check must  
change the cached value back to VOLATILITY_UNKNOWN again.  
contain_volatile_functions() is the only code in charge of setting the  
cache value to either VOLATILITY_VOLATILE or VOLATILITY_NOVOLATILE.  
  
Some existing code does benefit from this additional caching, however,  
this change is mainly aimed at an upcoming patch that must check for  
volatility during the join search.  Repeated volatility checks in that  
case can become very expensive when the join search contains more than a  
few relations.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/3795226.1614059027@sss.pgh.pa.us  

commit   : b64654d6c450eb9fb04c6e3456915790510af482    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 28 Mar 2021 11:27:59 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 28 Mar 2021 11:27:59 -0400    

Commit c6763156589 added an acronym reference for "TLS" but the definition  
was never added.  
  
Author: Daniel Gustafsson  
Reviewed-by: Michael Paquier  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/27109504-82DB-41A8-8E63-C0498314F5B0@yesql.se  

commit   : 2a058e938c73bfb85bbc9fa93dea74788043ca6c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 27 Mar 2021 18:26:52 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 27 Mar 2021 18:26:52 +0100    

The tests used string concatenation to test statistics on expressions,  
but that made the tests locale-dependent, e.g. because the ordering of  
'11' and '1X' depends on the collation. This affected both the estimated  
and actual row couts, breaking some of the tests.  
  
Fixed by replacing the string concatenation with upper() function call,  
so that the text values contain only digits.  
  
Discussion: https://postgr.es/m/b650920b-2767-fbc3-c87a-cb8b5d693cbf%40enterprisedb.com  

commit   : 8df2f371141ea267627364cd00e1791054d82d7e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Mar 2021 10:17:12 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Mar 2021 10:17:12 +0100    

commit   : a4d75c86bf15220df22de0a92c819ecef9db3849    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 23:22:01 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 23:22:01 +0100    

Allow defining extended statistics on expressions, not just just on  
simple column references.  With this commit, expressions are supported  
by all existing extended statistics kinds, improving the same types of  
estimates. A simple example may look like this:  
  
  CREATE TABLE t (a int);  
  CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;  
  ANALYZE t;  
  
The collected statistics are useful e.g. to estimate queries with those  
expressions in WHERE or GROUP BY clauses:  
  
  SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;  
  
  SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);  
  
This introduces new internal statistics kind 'e' (expressions) which is  
built automatically when the statistics object definition includes any  
expressions. This represents single-expression statistics, as if there  
was an expression index (but without the index maintenance overhead).  
The statistics is stored in pg_statistics_ext_data as an array of  
composite types, which is possible thanks to 79f6a942bd.  
  
CREATE STATISTICS allows building statistics on a single expression, in  
which case in which case it's not possible to specify statistics kinds.  
  
A new system view pg_stats_ext_exprs can be used to display expression  
statistics, similarly to pg_stats and pg_stats_ext views.  
  
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it  
treats indexes, i.e. it drops and recreates the statistics. This means  
all statistics are reset, and we no longer try to preserve at least the  
functional dependencies. This should not be a major issue in practice,  
as the functional dependencies actually rely on per-column statistics,  
which were always reset anyway.  
  
Author: Tomas Vondra  
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu  
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com  

commit   : 98376c18f12e562421b5c77e619248e8b7aae3c6    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 23:00:41 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 23:00:41 +0100    

The regression tests of extended statistics were taking a fair amount of  
time, due to using fairly large data sets with a couple thousand rows.  
So far this was fine, but with tests for statistics on expressions the  
duration would get a bit excessive.  So reduce the size of some of the  
tests that will be used to test expressions, to keep the duration under  
control.  Done in a separate commit before adding the statistics on  
expressions, to make it clear which estimates are expected to change.  
  
Author: Tomas Vondra  
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com  

commit   : 33e52ad9a32929a6d14dfd98a8440d57028f2e3e    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 22:34:53 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 22:34:53 +0100    

When estimating the number of groups using extended statistics, the code  
was discarding information about system attributes. This led to strange  
situation that  
  
    SELECT 1 FROM t GROUP BY ctid;  
  
could have produced higher estimate (equal to pg_class.reltuples) than  
  
    SELECT 1 FROM t GROUP BY a, b, ctid;  
  
with extended statistics on (a,b). Fixed by retaining information about  
the system attribute.  
  
Backpatch all the way to 10, where extended statistics were introduced.  
  
Author: Tomas Vondra  
Backpatch-through: 10  

commit   : a14a0118a1fecf4066e53af52ed0f188607d0c4b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 26 Mar 2021 10:42:17 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 26 Mar 2021 10:42:17 -0700    

Membership consists, implicitly, of the current database owner.  Expect  
use in template databases.  Once pg_database_owner has rights within a  
template, each owner of a database instantiated from that template will  
exercise those rights.  
  
Reviewed by John Naylor.  
  
Discussion: https://postgr.es/m/20201228043148.GA1053024@rfd.leadboat.com  

commit   : f687bf61ed4dc75ec074c387f848147da2097e13    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 26 Mar 2021 10:42:16 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 26 Mar 2021 10:42:16 -0700    

The next commit would have complicated two or three algorithms, so take  
this opportunity to consolidate.  No functional changes.  
  
Reviewed by John Naylor.  
  
Discussion: https://postgr.es/m/20201228043148.GA1053024@rfd.leadboat.com  

commit   : 73b96bad4af8fd113a36e4633dd3312001c115dc    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 16:33:19 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 16:33:19 +0100    

The deserialization failed to ensure correct alignment, as it assumed it  
can simply point into the serialized value. The serialization however  
ignores alignment and copies just the significant bytes in order to make  
the result as small as possible. This caused failures on systems that  
are sensitive to mialigned addresses, like sparc, or with address  
sanitizer enabled.  
  
Fixed by copying the serialized data to ensure proper alignment. While  
at it, fix an issue with serialization on big endian machines, using the  
same store_att_byval/fetch_att trick as extended statistics.  
  
Discussion: https://postgr.es/0c8c3304-d3dd-5e29-d5ac-b50589a23c8c%40enterprisedb.com  

commit   : ab596105b55f1d7fbd5a66b66f65227d210b047d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:54:29 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:54:29 +0100    

Adds BRIN opclasses similar to the existing minmax, except that instead  
of summarizing the page range into a single [min,max] range, the summary  
consists of multiple ranges and/or points, allowing gaps. This allows  
more efficient handling of data with poor correlation to physical  
location within the table and/or outlier values, for which the regular  
minmax opclassed tend to work poorly.  
  
It's possible to specify the number of values kept for each page range,  
either as a single point or an interval boundary.  
  
  CREATE TABLE t (a int);  
  CREATE INDEX ON t  
   USING brin (a int4_minmax_multi_ops(values_per_range=16));  
  
When building the summary, the values are combined into intervals with  
the goal to minimize the "covering" (sum of interval lengths), using a  
support procedure computing distance between two values.  
  
Bump catversion, due to various catalog changes.  
  
Author: Tomas Vondra <tomas.vondra@postgresql.org>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru>  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com  
Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com  

commit   : 77b88cd1bb9041a735f24072150cacfa06c699a3    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:35:29 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:35:29 +0100    

Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes  
using the new opclasses allow only equality queries (similar to hash  
indexes), but that works fine for data like UUID, MAC addresses etc. for  
which range queries are not very common. This also means the indexes  
work for data that is not well correlated to physical location within  
the table, or perhaps even entirely random (which is a common issue with  
existing BRIN minmax opclasses).  
  
It's possible to specify opclass parameters with the usual Bloom filter  
parameters, i.e. the desired false-positive rate and the expected number  
of distinct values per page range.  
  
  CREATE TABLE t (a int);  
  CREATE INDEX ON t  
   USING brin (a int4_bloom_ops(false_positive_rate = 0.05,  
                                n_distinct_per_range = 100));  
  
The opclasses do not operate on the indexed values directly, but compute  
a 32-bit hash first, and the Bloom filter is built on the hash value.  
Collisions should not be a huge issue though, as the number of distinct  
values in a page ranges is usually fairly small.  
  
Bump catversion, due to various catalog changes.  
  
Author: Tomas Vondra <tomas.vondra@postgresql.org>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru>  
Reviewed-by: Nico Williams <nico@cryptonector.com>  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com  
Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com  

commit   : a681e3c107aa97eb554f118935c4d2278892c3dd    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:17:56 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:17:56 +0100    

Commit a1c649d889 changed the signature of the BRIN consistent function  
by adding a new required parameter.  Treating the parameter as optional,  
which would make the change backwards incompatibile, was rejected with  
the justification that there are few out-of-core extensions, so it's not  
worth adding making the code more complex, and it's better to deal with  
that in the extension.  
  
But after further thought, that would be rather problematic, because  
pg_upgrade simply dumps catalog contents and the same version of an  
extension needs to work on both PostgreSQL versions. Supporting both  
variants of the consistent function (with 3 or 4 arguments) makes that  
possible.  
  
The signature is not the only thing that changed, as commit 72ccf55cb9  
moved handling of IS [NOT] NULL keys from the support procedures. But  
this change is backward compatible - handling the keys in exension is  
unnecessary, but harmless. The consistent function will do a bit of  
unnecessary work, but it should be very cheap.  
  
This also undoes most of the changes to the existing opclasses (minmax  
and inclusion), making them use the old signature again. This should  
make backpatching simpler.  
  
Catversion bump, because of changes in pg_amproc.  
  
Author: Tomas Vondra <tomas.vondra@postgresql.org>  
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>  
Reviewed-by: Mark Dilger <hornschnorter@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Masahiko Sawada <masahiko.sawada@enterprisedb.com>  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com  

commit   : a68dfa27d42fb7b7611fd1206d2356fc124ed390    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:04:13 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 13:04:13 +0100    

The BRIN minmax opclasses included amproc entries with mismatching left  
and right types, but those happen to be unnecessary.  The opclasses only  
need cross-type operators, not cross-type support procedures. Discovered  
when trying to define equivalent BRIN operator families in an extension.  
  
Catversion bump, because of pg_amproc changes.  
  
Author: Tomas Vondra  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/78c357ab-3395-8433-e7b3-b2cfcc9fdc23%40enterprisedb.com  

commit   : 5db1fd7823a1a12e2bdad98abc8e102fd71ffbda    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Mar 2021 19:55:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Mar 2021 19:55:32 -0400    

Before, trying to compress a value for insertion into an expression  
index would crash.  
  
Dilip Kumar, with some editing by me. Report by Jaime Casanova.  
  
Discussion: http://postgr.es/m/CAJKUy5gcs0zGOp6JXU2mMVdthYhuQpFk=S3V8DOKT=LZC1L36Q@mail.gmail.com  

commit   : 71f4c8c6f74ba021e55d35b1128d22fb8c6e1629    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 18:00:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 18:00:28 -0300    

Allow a partition be detached from its partitioned table without  
blocking concurrent queries, by running in two transactions and only  
requiring ShareUpdateExclusive in the partitioned table.  
  
Because it runs in two transactions, it cannot be used in a transaction  
block.  This is the main reason to use dedicated syntax: so that users  
can choose to use the original mode if they need it.  But also, it  
doesn't work when a default partition exists (because an exclusive lock  
would still need to be obtained on it, in order to change its partition  
constraint.)  
  
In case the second transaction is cancelled or a crash occurs, there's  
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final  
steps.  
  
The main trick to make this work is the addition of column  
pg_inherits.inhdetachpending, initially false; can only be set true in  
the first part of this command.  Once that is committed, concurrent  
transactions that use a PartitionDirectory will include or ignore  
partitions so marked: in optimizer they are ignored if the row is marked  
committed for the snapshot; in executor they are always included.  As a  
result, and because of the way PartitionDirectory caches partition  
descriptors, queries that were planned before the detach will see the  
rows in the detached partition and queries that are planned after the  
detach, won't.  
  
A CHECK constraint is created that duplicates the partition constraint.  
This is probably not strictly necessary, and some users will prefer to  
remove it afterwards, but if the partition is re-attached to a  
partitioned table, the constraint needn't be rechecked.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql  

commit   : 650d623530c884c087c565f1d3b8cd76f8fe2b95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 16:30:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 16:30:22 -0300    

On partition detach, we acquire a SHARE lock on all tables that  
reference the partitioned table that we're detaching a partition from,  
but failed to document this fact.  My oversight in commit f56f8f8da6af.  
Repair.  Backpatch to 12.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210325180244.GA12738@alvherre.pgsql  

commit   : cc121d5596964f8aac93607e6f14607184558b16    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 16:07:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 16:07:15 -0300    

The prior commit which introduced it was pretty squalid in terms of  
code documentation, so add some comments.  

commit   : cd03c6e94b09ff402cbc3ce8da5587f09f0b5e58    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 15:56:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 15:56:11 -0300    

Struct AlteredRelationInfo gains a new Relation member, to be used only  
by Phase 2 (ATRewriteCatalogs); this allows ATExecCmd() subroutines open  
and close the relation internally.  
  
A future commit will use this facility to implement an ALTER TABLE  
subcommand that closes and reopens the relation across transaction  
boundaries.  
  
(It is possible to keep the relation open past phase 2 to be used by  
phase 3 instead of having to reopen it that point, but there are some  
minor complications with that; it's not clear that there is much to be  
won from doing that, though.)  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql  

commit   : 4669cacbd4b4b1baa1b7f2ea53d461433a1b6276    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 22 Feb 2021 17:21:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 22 Feb 2021 17:21:22 -0300    

The original definitions pointlessly disregarded existing ItemPointer  
macros that do the same thing.  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20210222201557.GA32655@alvherre.pgsql  

commit   : a24ae3d7b9efb3b113c0d53030aa99de0d41b40a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 10:47:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 10:47:38 -0300    

I introduced this duplicate code in commit 8b08f7d4820f for no good  
reason.  Remove it, and backpatch to 11 where it was introduced.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : f2c7ce64ae9ba292c1846ae864cef1b8b37af1f3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Mar 2021 10:17:52 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Mar 2021 10:17:52 +0100    

commit   : 91d1f2d302108f49006eedb8053522236dde77cc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Mar 2021 10:06:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Mar 2021 10:06:32 +0100    

A WHERE clause will be used for row filtering in logical replication.  
We already have a similar node: 'WHERE (condition here)'.  Let's  
rename the node to a generic name and use it for row filtering too.  
  
Author: Euler Taveira <euler.taveira@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X+mK_DitLXF25B=jE6xyNCH4YOwM860JR7HarGQ@mail.gmail.com  

commit   : a1999a01bb56c5f5451116abe61b892b2eec5e49    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Mar 2021 16:08:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Mar 2021 16:08:03 +0900    

Combo CIDs were referred in the code comments using different terms  
across various places of the code, so unify a bit the term used with  
what is currently in use in some of the READMEs.  
  
Author: "Hou, Zhijie"  
Discussion: https://postgr.es/m/1d42865c91404f46af4562532fdbea31@G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 438fc4a39c3905b7af88bb848bc5aeb1308a017d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Mar 2021 11:23:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Mar 2021 11:23:30 +0900    

Previously the WAL replay of COMMIT_TS_SETTS record called  
TransactionTreeSetCommitTsData() with the argument write_xlog=true,  
which generated and wrote new COMMIT_TS_SETTS record.  
This should not be acceptable because it's during recovery.  
  
This commit fixes the WAL replay of COMMIT_TS_SETTS record  
so that it calls TransactionTreeSetCommitTsData() with write_xlog=false  
and doesn't generate new WAL during recovery.  
  
Back-patch to all supported branches.  
  
Reported-by: lx zou <zoulx1982@163.com>  
Author: Fujii Masao  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/16931-620d0f2fdc6108f1@postgresql.org  

commit   : df9384492b89aac370ab9d12eb89375aeb38a1d4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Mar 2021 10:41:28 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Mar 2021 10:41:28 +0900    

Previously when an archive recovery or a standby was starting and  
reached the consistent recovery state but hot_standby was configured  
to off, the error message when a client connectted was "the database  
system is starting up", which was needless confusing and not really  
all that accurate either.  
  
This commit improves the connection denied error message during  
recovery, as follows, so that the users immediately know that their  
servers are configured to deny those connections.  
  
- If hot_standby is disabled, the error message "the database system  
  is not accepting connections" and the detail message "Hot standby  
  mode is disabled." are output when clients connect while an archive  
  recovery or a standby is running.  
  
- If hot_standby is enabled, the error message "the database system  
  is not yet accepting connections" and the detail message  
  "Consistent recovery state has not been yet reached." are output  
  when clients connect until the consistent recovery state is reached  
  and postmaster starts accepting read only connections.  
  
This commit doesn't change the connection denied error message of  
"the database system is starting up" during normal server startup and  
crash recovery. Because it's still suitable for those situations.  
  
Author: James Coleman  
Reviewed-by: Alvaro Herrera, Andres Freund, David Zhang, Tom Lane, Fujii Masao  
Discussion: https://postgr.es/m/CAAaqYe8h5ES_B=F_zDT+Nj9XU7YEwNhKhHA2RE4CFhAQ93hfig@mail.gmail.com  

commit   : b34ca595abd697e716ce369ec1b58624bdd1c431    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Mar 2021 18:52:25 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Mar 2021 18:52:25 -0400    

Currently instances of PostgresNode find their Postgres executables in  
the PATH of the caller. This modification allows for instances that know  
the installation path they are supposed to use, and the module adjusts  
the environment of methods that call Postgres executables appropriately.  
  
This facility is activated by passing the installation path to the  
constructor:  
  
  my $node = PostgresNode->get_new_node('mynode',  
     installation_path => '/path/to/installation');  
  
This makes a number of things substantially easier, including  
  
. testing third party modules  
. testing different versions of postgres together  
. testing different builds of postgres together  
  
Discussion: https://postgr.es/m/a94c74f9-6b71-1957-7973-a734ea3cbef1@dunslane.net  
  
Reviewed-By:  Alvaro Herrera, Michael Paquier, Dagfinn Ilmari Mannsåker  

commit   : 65c2ec6f30d9c0878a9ef83e0ec9a53e6b82d9d8    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 24 Mar 2021 22:06:31 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 24 Mar 2021 22:06:31 +0100    

commit   : ad8305a43d1890768a613d3fb586b44f17360f29    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 24 Mar 2021 20:48:20 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 24 Mar 2021 20:48:20 +0100    

This command declares a SQL identifier for a SQL statement to be used in other  
embedded SQL statements. The identifier is linked to a connection.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Shawn Wang <shawn.wang.pg@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/TY2PR01MB24438A52DB04E71D0E501452F5630@TY2PR01MB2443.jpnprd01.prod.outlook.com  

commit   : 37c99d304dcbf12ab581ff031f394af93b750895    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 20:42:05 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 20:42:05 +0100    

Reported-by: John Naylor <john.naylor@enterprisedb.com>  

commit   : 5173e428928ce890be3e3d809b2d23d5f3c7da2f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 20:41:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 20:41:18 +0100    

Reported-by: Erik Rijkers <er@xs4all.nl>  

commit   : bbcc4eb2e08fb6e4535c7f84b2c00f3ad508bb9b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 24 Mar 2021 13:07:51 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 24 Mar 2021 13:07:51 -0400    

Common recommendations are that the checkpoint should be spread out as  
much as possible, provided we avoid having it take too long.  This  
change updates the default to 0.9 (from 0.5) to match that  
recommendation.  
  
There was some debate about possibly removing the option entirely but it  
seems there may be some corner-cases where having it set much lower to  
try to force the checkpoint to be as fast as possible could result in  
fewer periods of time of reduced performance due to kernel flushing.  
General agreement is that the "spread more" is the preferred approach  
though and those who need to tune away from that value are much less  
common.  
  
Reviewed-By: Michael Paquier, Peter Eisentraut, Tom Lane, David Steele,  
Nathan Bossart  
Discussion: https://postgr.es/m/20201207175329.GM16415%40tamriel.snowman.net  

commit   : e5595de03ec6ce60afde980ae05e9353a1501fdf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 24 Mar 2021 12:36:08 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 24 Mar 2021 12:36:08 -0400    

Change the default_toast_compression GUC to be an enum rather than  
a string. Earlier, uncommitted versions of the patch supported using  
CREATE ACCESS METHOD to add new compression methods to a running  
system, but that idea was dropped before commit. So, we can simplify  
the GUC handling as well, which has the nice side effect of improving  
the error messages.  
  
While updating the documentation to reflect the new GUC type, also  
move it back to the right place in the list. I moved this while  
revising what became commit 24f0e395ac5892cd12e8914646fe921fac5ba23d,  
but apparently the intended ordering is "alphabetical" rather than  
"whatever Robert thinks looks nice."  
  
Rejigger things to avoid having access/toast_compression.h depend on  
utils/guc.h, so that we don't end up with every file that includes  
it also depending on something largely unrelated. Move a few  
inline functions back into the C source file partly to help reduce  
dependencies and partly just to avoid clutter. A few very minor  
cosmetic fixes.  
  
Original patch by Justin Pryzby, but very heavily edited by me,  
and reverse reviewed by him and also reviewed by by Tom Lane.  
  
Discussion: http://postgr.es/m/CA+TgmoYp=GT_ztUCeZg2i4hkHAQv8o=-nVJ1-TKWTG1zQOmOpg@mail.gmail.com  

commit   : 49ab61f0bdc93984a8d36b602f6f2a15f09ebcc7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 16:16:14 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 16:16:14 +0100    

Similar to date_trunc, but allows binning by an arbitrary interval  
rather than just full units.  
  
Author: John Naylor <john.naylor@enterprisedb.com>  
Reviewed-by: David Fetter <david@fetter.org>  
Reviewed-by: Isaac Morland <isaac.morland@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Artur Zakirov <zaartur@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CACPNZCt4buQFRgy6DyjuZS-2aPDpccRkrJBmgUfwYc1KiaXYxg@mail.gmail.com  

commit   : 1509c6fc29c07d13c9a590fbd6f37c7576f58ba6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 08:02:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Mar 2021 08:02:06 +0100    

Make it the same as another nearby message.  

commit   : 26acb54a1368bf3706294400abca85b15c9233a6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Mar 2021 11:10:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Mar 2021 11:10:12 +0530    

To allow inserts in parallel-mode this feature has to ensure that all the  
constraints, triggers, etc. are parallel-safe for the partition hierarchy  
which is costly and we need to find a better way to do that. Additionally,  
we could have used existing cached information in some cases like indexes,  
domains, etc. to determine the parallel-safety.  
  
List of commits reverted, in reverse chronological order:  
  
ed62d3737c Doc: Update description for parallel insert reloption.  
c8f78b6161 Add a new GUC and a reloption to enable inserts in parallel-mode.  
c5be48f092 Improve FK trigger parallel-safety check added by 05c8482f7f.  
e2cda3c20a Fix use of relcache TriggerDesc field introduced by commit 05c8482f7f.  
e4e87a32cc Fix valgrind issue in commit 05c8482f7f.  
05c8482f7f Enable parallel SELECT for "INSERT INTO ... SELECT ...".  
  
Discussion: https://postgr.es/m/E1lMiB9-0001c3-SY@gemulon.postgresql.org  

commit   : 84007043fc1b1be68dad5d0a78269347c12094b6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 24 Mar 2021 10:37:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 24 Mar 2021 10:37:54 +0900    

Commit de829ddf23 added wait event WalrcvExit. But its name is not  
consistent with other wait events like WalReceiverMain or  
WalReceiverWaitStart, etc. So this commit renames WalrcvExit to  
WalReceiverExit.  
  
Author: Fujii Masao  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/cced9995-8fa2-7b22-9d91-3f22a2b8c23c@oss.nttdata.com  

commit   : 7fbcee1b2d5f1012c67942126881bd492e95077e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 24 Mar 2021 10:36:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 24 Mar 2021 10:36:56 +0900    

GetNewOidWithIndex() generates a new OID one by one until it finds  
one not in the relation. If there are very long runs of consecutive  
existing OIDs, GetNewOidWithIndex() needs to iterate many times  
in the loop to find unused OID. Since TOAST table can have a large  
number of entries and there can be such long runs of OIDs, there is  
the case where it takes so many iterations to find new OID not in  
TOAST table. Furthermore if all (i.e., 2^32) OIDs are already used,  
GetNewOidWithIndex() enters something like busy loop and repeats  
the iterations until at least one OID is marked as unused.  
  
There are some reported troubles caused by a large number of  
iterations in GetNewOidWithIndex(). For example, when inserting  
a billion of records into the table, all the backends doing that  
insertion operation got hang with 100% CPU usage at some point.  
  
Previously there was no easy way to detect that GetNewOidWithIndex()  
failed to find unused OID many times. So, for example, gdb full  
backtrace of hanged backends needed to be taken, in order to  
investigate that trouble. This is inconvenient and may not be  
available in some production environments.  
  
To provide easy way for that, this commit makes GetNewOidWithIndex()  
log that it iterates more than GETNEWOID_LOG_THRESHOLD but have  
not yet found OID unused in the relation. Also this commit makes  
it repeat logging with exponentially increasing intervals until  
it iterates more than GETNEWOID_LOG_MAX_INTERVAL, and makes it  
finally repeat logging every GETNEWOID_LOG_MAX_INTERVAL unless  
an unused OID is found. Those macro variables are used not to  
fill up the server log with the similar messages.  
  
In the discusion at pgsql-hackers, there was another idea to report  
the lots of iterations in GetNewOidWithIndex() via wait event.  
But since GetNewOidWithIndex() traverses indexes to find unused  
OID and which will do I/O, acquire locks, etc, which will overwrite  
the wait event and reset it to nothing once done. So that idea  
doesn't work well, and we didn't adopt it.  
  
Author: Tomohiro Hiramitsu  
Reviewed-by: Tatsuhito Kasahara, Kyotaro Horiguchi, Tom Lane, Fujii Masao  
Discussion: https://postgr.es/m/16722-93043fb459a41073@postgresql.org  

commit   : 99dd75fb99baa9188971cf47779ed8d7a5e6eb29    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Mar 2021 09:36:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Mar 2021 09:36:03 +0900    

Using "remain" is confusing, as it implies that the index file can  
shrink.  Instead, use "in total".  
  
Per discussion with Peter Geoghegan.  
  
Discussion: https://postgr.es/m/CAH2-WzkYgHZzpGOwR14CScJsjaQpvJrEkEfkh_=wGhzLb=yVdQ@mail.gmail.com  

commit   : 79f6a942bdb958fbd7ef6870d5bf2e3cefb65da5    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 24 Mar 2021 00:47:50 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 24 Mar 2021 00:47:50 +0100    

When resolving types during catalog bootstrap, try to reload the pg_type  
contents if a type is not found. That allows catalogs to contain  
composite types, e.g. row types for other catalogs.  
  
Author: Justin Pryzby  
Reviewed-by: Dean Rasheed, Tomas Vondra  
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com  

commit   : e1a5e65703ce884529340819f6268d24f43ef8f7    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 24 Mar 2021 00:47:38 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 24 Mar 2021 00:47:38 +0100    

It's a bit easier and more convenient to free and reload a List,  
compared to a plain array. This will be helpful when allowing catalogs  
to contain composite types.  
  
Author: Justin Pryzby  
Reviewed-by: Dean Rasheed, Tomas Vondra  
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com  

commit   : 5b861baa550a369e04bf67fbe83f3a5a8c742fb4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 23 Mar 2021 16:09:51 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 23 Mar 2021 16:09:51 -0700    

Teach nbtree VACUUM to press on with vacuuming in the event of a page  
deletion attempt that fails to "re-find" a downlink for its child/target  
page.  
  
There is no good reason to treat this as an irrecoverable error.  But  
there is a good reason not to: pressing on at this point removes any  
question of VACUUM not making progress solely due to misbehavior from  
user-defined operator class code.  
  
Discussion: https://postgr.es/m/CAH2-Wzma5G9CTtMjbrXTwOym+U=aWg-R7=-htySuztgoJLvZXg@mail.gmail.com  

commit   : 87d90ac61fa113ffc886efcdb391c522c1982991    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 23 Mar 2021 14:57:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 23 Mar 2021 14:57:45 -0400    

Disable autovacuum, because we don't want it to run against  
intentionally corrupted tables. Also, before corrupting the tables,  
run pg_amcheck and ensure that it passes. Otherwise, if something  
unexpected happens when we check the corrupted tables, it's not so  
clear whether it would have also happened before we corrupted  
them.  
  
Mark Dilger  
  
Discussion: http://postgr.es/m/AA5506CE-7D2A-42E4-A51D-358635E3722D@enterprisedb.com  

commit   : ea80138545043c0cfcff8405b15626796f2695fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 14:27:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 14:27:50 -0400    

Jasen Betts reported yet another unintended side effect of commit  
85c54287a: reconnecting with "\c service=whatever" did not have the  
expected results.  The reason is that starting from the output of  
PQconndefaults() effectively allows environment variables (such  
as PGPORT) to override entries in the service file, whereas the  
normal priority is the other way around.  
  
Not using PQconndefaults at all would require yet a third main code  
path in do_connect's parameter setup, so I don't really want to fix  
it that way.  But we can have the logic effectively ignore all the  
default values for just a couple more lines of code.  
  
This patch doesn't change the behavior for "\c -reuse-previous=on  
service=whatever".  That remains significantly different from before  
85c54287a, because many more parameters will be re-used, and thus  
not be possible for service entries to replace.  But I think this  
is (mostly?) intentional.  In any case, since libpq does not report  
where it got parameter values from, it's hard to do differently.  
  
Per bug #16936 from Jasen Betts.  As with the previous patches,  
back-patch to all supported branches.  (9.5 is unfortunately now  
out of support, so this won't get fixed there.)  
  
Discussion: https://postgr.es/m/16936-3f524322a53a29f0@postgresql.org  

commit   : 9d523119fd38fd205cb9c8ea8e7cceeb54355818    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 11:24:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 11:24:16 -0400    

end_heap_rewrite was not careful to ensure that the target relation  
is open at the smgr level before performing its final smgrimmedsync.  
In ordinary cases this is no problem, because it would have been  
opened earlier during the rewrite.  However a crash can be reproduced  
by re-clustering an empty table with CLOBBER_CACHE_ALWAYS enabled.  
  
Although that exact scenario does not crash in v13, I think that's  
a chance result of unrelated planner changes, and the problem is  
likely still reachable with other test cases.  The true proximate  
cause of this failure is commit c6b92041d, which replaced a call to  
heap_sync (which was careful about opening smgr) with a direct call  
to smgrimmedsync.  Hence, back-patch to v13.  
  
Amul Sul, per report from Neha Sharma; cosmetic changes  
and test case by me.  
  
Discussion: https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com  

commit   : 22e1943f13b66df22ea4f8d15836411ba259263a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Mar 2021 11:35:12 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Mar 2021 11:35:12 +0100    

This has previously not been a problem (that anyone ever reported),  
but in future OpenSSL versions (3.0.0), where legacy ciphers are/can  
be disabled, this is the place where this is reported.  So we need to  
catch the error here, otherwise the higher-level functions would  
return garbage.  The nearby encryption code already handled errors  
similarly.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/9e9c431c-0adc-7a6d-9b1a-915de1ba3fe7@enterprisedb.com  

commit   : a6715af1e72da289474011be1e2d536f991eda34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Mar 2021 08:45:51 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Mar 2021 08:45:51 +0100    

This function for bit and bytea counts the set bits in the bit or byte  
string.  Internally, we use the existing popcount functionality.  
  
For the name, after some discussion, we settled on bit_count, which  
also exists with this meaning in MySQL, Java, and Python.  
  
Author: David Fetter <david@fetter.org>  
Discussion: https://www.postgresql.org/message-id/flat/20201230105535.GJ13234@fetter.org  

commit   : 5aed6a1fc214913de9ac69c1717dc64a2483e16d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Mar 2021 13:25:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Mar 2021 13:25:14 +0900    

Once a relation's autovacuum is completed, the logs include more  
information about this relation state if the threshold of  
log_autovacuum_min_duration (or its relation option) is reached, with  
for example contents about the statistics of the VACUUM operation for  
the relation, WAL and system usage.  
  
This commit adds more information about the statistics of the relation's  
indexes, with one line of logs generated for each index.  The index  
stats were already calculated, but not printed in the context of  
autovacuum yet.  While on it, some refactoring is done to keep track of  
the index statistics directly within LVRelStats, simplifying some  
routines related to parallel VACUUMs.  
  
Author: Masahiko Sawada  
Reviewed-by: Michael Paquier, Euler Taveira  
Discussion: https://postgr.es/m/CAD21AoAy6SxHiTivh5yAPJSUE4S=QRPpSZUdafOSz0R+fRcM6Q@mail.gmail.com  

commit   : 4b82ed6eca41220e50d4712ab929c20030b30d35    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 23 Mar 2021 09:43:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 23 Mar 2021 09:43:33 +0530    

We can't access the entry after it is removed from dynahash.  
  
Author: Peter Smith  
Discussion: https://postgr.es/m/CAHut+Ps-pL++f6CJwPx2+vUqXuew=Xt-9Bi-6kCyxn+Fwi2M7w@mail.gmail.com  

commit   : a5f002ad9a2ddb501148a12281efbaacec6f6397    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 04:45:26 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 04:45:26 +0100    

A couple error messages and comments used 'statistic kind', not the  
correct 'statistics kind'. Fix and backpatch all the way back to 10,  
where extended statistics were introduced.  
  
Backpatch-through: 10  

commit   : 1e3e8b51bda8ddd59984230f876f199c9ce3166a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Mar 2021 10:09:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Mar 2021 10:09:42 +0900    

Previously the type of this wait event was Client. But while this  
wait event is being reported, walreceiver process is waiting for  
the startup process to set initial data for streaming replication.  
It's not waiting for any activity on a socket connected to a user  
application or walsender. So this commit changes the type for  
WalReceiverWaitStart wait event to IPC.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/cdacc27c-37ff-f1a4-20e2-ce19933abfcc@oss.nttdata.com  

commit   : 51893c8463501fc9a38e39cc097773dbdfb9db82    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Mar 2021 09:53:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Mar 2021 09:53:08 +0900    

pg_waldump --stats=record identifies a record by a combination  
of the RmgrId and the four bits of the xl_info field of the record.  
But XACT records use the first bit of those four bits for an optional  
flag variable, and the following three bits for the opcode to  
identify a record. So previously the same type of XACT record  
could have different four bits (three bits are the same but the  
first one bit is different), and which could cause  
pg_waldump --stats=record to show two lines of per-record statistics  
for the same XACT record. This is a bug.  
  
This commit changes pg_waldump --stats=record so that it processes  
only XACT record differently, i.e., filters the opcode out of xl_info  
and uses a combination of the RmgrId and those three bits as  
the identifier of a record, only for XACT record. For other records,  
the four bits of the xl_info field are still used.  
  
Back-patch to all supported branches.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Shinya Kato, Fujii Masao  
Discussion: https://postgr.es/m/2020100913412132258847@highgo.ca  

commit   : 95d77149c53545a74e0c84717cf8f925b8f6d632    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 Mar 2021 20:22:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 Mar 2021 20:22:48 -0400    

Previously, to check relation permanence, the Relation's Form_pg_class  
structure member relpersistence was compared to the value  
RELPERSISTENCE_PERMANENT ("p"). This commit adds the macro  
RelationIsPermanent() and is used in appropirate places to simplify the  
code.  This matches other RelationIs* macros.  
  
This macro will be used in more places in future cluster file encryption  
patches.  
  
Discussion: https://postgr.es/m/20210318153134.GH20766@tamriel.snowman.net  

commit   : 8e4b332e88b8339408a3aa8c62bc93d96b67c808    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:47:06 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:47:06 +0100    

The bringetbitmap function allocates memory for various purposes, which  
may be quite expensive, depending on the number of scan keys. Instead of  
allocating them separately, allocate one bit chunk of memory an carve it  
into smaller pieces as needed - all the pieces have the same lifespan,  
and it saves quite a bit of CPU and memory overhead.  
  
Author: Tomas Vondra <tomas.vondra@postgresql.org>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Mark Dilger <hornschnorter@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Masahiko Sawada <masahiko.sawada@enterprisedb.com>  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com  

commit   : 72ccf55cb99c6450dfb77f2f8f4a28b5c049ef7a    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:45:33 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:45:33 +0100    

The handling of IS [NOT] NULL clauses is independent of an opclass, and  
most of the code was exactly the same in both minmax and inclusion. So  
instead move the code from support procedures to the AM.  
  
This simplifies the code - especially the support procedures - quite a  
bit, as they don't need to care about NULL values and flags at all. It  
also means the IS [NOT] NULL clauses can be evaluated without invoking  
the support procedure.  
  
Author: Tomas Vondra <tomas.vondra@postgresql.org>  
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>  
Reviewed-by: Nikita Glukhov <n.gluhov@postgrespro.ru>  
Reviewed-by: Mark Dilger <hornschnorter@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: Masahiko Sawada <masahiko.sawada@enterprisedb.com>  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com  

commit   : a1c649d889bdf6e74e9382e1e28574d7071568de    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:12:19 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:12:19 +0100    

This commit changes how we pass scan keys to BRIN consistent function.  
Instead of passing them one by one, we now pass all scan keys for a  
given attribute at once. That makes the consistent function a bit more  
complex, as it has to loop through the keys, but it does allow more  
elaborate opclasses that can use multiple keys to eliminate ranges much  
more effectively.  
  
The existing BRIN opclasses (minmax, inclusion) don't really benefit  
from this change. The primary purpose is to allow future opclases to  
benefit from seeing all keys at once.  
  
This does change the BRIN API, because the signature of the consistent  
function changes (a new parameter with number of scan keys). So this  
breaks existing opclasses, and will require supporting two variants of  
the code for different PostgreSQL versions. We've considered supporting  
two variants of the consistent, but we've decided not to do that.  
Firstly, there's another patch that moves handling of NULL values from  
the opclass, which means the opclasses need to be updated anyway.  
Secondly, we're not aware of any out-of-core BRIN opclasses, so it does  
not seem worth the extra complexity.  
  
Bump catversion, because of pg_proc changes.  
  
Author: Tomas Vondra <tomas.vondra@postgresql.org>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Mark Dilger <hornschnorter@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Reviewed-by: Nikita Glukhov <n.gluhov@postgrespro.ru>  
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com  

commit   : bfa2cee784125047771db2768fcf7f04d8bd6bb4    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:11:20 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 00:11:20 +0100    

Until now the bsearch_arg function was used only in extended statistics  
code, so it was defined in that code.  But we already have qsort_arg in  
src/port, so let's move it next to it.  

commit   : 063dd37ebc7644e8db6419565b50dca019e69e86    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Mar 2021 14:01:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Mar 2021 14:01:20 -0400    

substring(), and perhaps other callers, isn't careful to pass a  
slice length that is no more than the datum's true size.  Since  
toast_decompress_datum_slice's children will palloc the requested  
slice length, this can waste memory.  Also, close study of the liblz4  
documentation suggests that it is dependent on the caller to not ask  
for more than the correct amount of decompressed data; this squares  
with observed misbehavior with liblz4 1.8.3.  Avoid these problems  
by switching to the normal full-decompression code path if the  
slice request is >= datum's decompressed size.  
  
Tom Lane and Dilip Kumar  
  
Discussion: https://postgr.es/m/507597.1616370729@sss.pgh.pa.us  

commit   : aeb1631ed207cef2d80e20f79eb52c72f03bca7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Mar 2021 13:43:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Mar 2021 13:43:10 -0400    

The authors of bbe0a81db hadn't quite got the idea that macros named  
like SOMETHING_4B_C were only meant for internal endianness-related  
details in postgres.h.  Choose more legible names for macros that are  
intended to be used elsewhere.  Rearrange postgres.h a bit to clarify  
the separation between those internal macros and ones intended for  
wider use.  
  
Also, avoid using the term "rawsize" for true decompressed size;  
we've used "extsize" for that, because "rawsize" generally denotes  
total Datum size including header.  This choice seemed particularly  
unfortunate in tests that were comparing one of these meanings to  
the other.  
  
This patch includes a couple of not-purely-cosmetic changes: be  
sure that the shifts aligning compression methods are unsigned  
(not critical today, but will be when compression method 2 exists),  
and fix broken definition of VARATT_EXTERNAL_GET_COMPRESSION (now  
VARATT_EXTERNAL_GET_COMPRESS_METHOD), whose callers worked only  
accidentally.  
  
Discussion: https://postgr.es/m/574197.1616428079@sss.pgh.pa.us  

commit   : 2c75f8a612b207c7d36e5dc73317dc9ab6fb29d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Mar 2021 11:20:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Mar 2021 11:20:44 -0400    

This seems to have been just copied-and-pasted from some other  
header checks.  But our C code is entirely unprepared to support  
such a header name, so it's only wasting cycles to look for it.  
If we did need to support it, some #ifdefs would be required.  
  
(A quick trawl at codesearch.debian.net finds some packages that  
reference lz4/lz4.h; but they use *only* that spelling, and  
appear to be intending to reference their own copy rather than  
a system-level installation of liblz4.  There's no evidence of  
freestanding installations that require this spelling.)  
  
Discussion: https://postgr.es/m/457962.1616362509@sss.pgh.pa.us  

commit   : a4d5284a10b5096585f1bbf1bf723954e9d6c2e0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Mar 2021 10:57:08 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Mar 2021 10:57:08 -0400    

The previous coding treated an invalid compression method name as  
equivalent to the default, which is certainly not right.  
  
Justin Pryzby  
  
Discussion: http://postgr.es/m/20210321235544.GD4203@telsasoft.com  

commit   : 24f0e395ac5892cd12e8914646fe921fac5ba23d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Mar 2021 10:34:10 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Mar 2021 10:34:10 -0400    

Previously, the default_toast_compression GUC was not documented,  
and neither was pg_dump's new --no-toast-compression option.  
  
Justin Pryzby and Robert Haas  
  
Discussion: http://postgr.es/m/20210321235544.GD4203@telsasoft.com  

commit   : 226e2be3876d0bda3dc33d16dfa0bed246b7b74f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Mar 2021 09:21:37 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Mar 2021 09:21:37 -0400    

Remove unused macro. Fix confusion about whether a TOAST compression  
method is identified by an OID or a char.  
  
Justin Pryzby  
  
Discussion: http://postgr.es/m/20210321235544.GD4203@telsasoft.com  

commit   : 909b449e00fc2f71e1a38569bbddbb6457d28485    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 14:02:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 14:02:26 +0900    

This commit is mostly a revert of aaa3aed, that switched the routine  
doing the internal renaming of recycled WAL segments to use on Windows a  
combination of CreateHardLinkA() plus unlink() instead of rename().  As  
reported by several users of Postgres 13, this is causing concurrency  
issues when manipulating WAL segments, mostly in the shape of the  
following error:  
LOG:  could not rename file "pg_wal/000000XX000000YY000000ZZ":  
Permission denied  
  
This moves back to a logic where a single rename() (well, pgrename() for  
Windows) is used.  This issue has proved to be hard to hit when I tested  
it, facing it only once with an archive_command that was not able to do  
its work, so it is environment-sensitive.  The reporters of this issue  
have been able to confirm that the situation improved once we switched  
back to a single rename().  In order to check things, I have provided to  
the reporters a patched build based on 13.2 with aaa3aed reverted, to  
test if the error goes away, and an unpatched build of 13.2 to test if  
the error still showed up (just to make sure that I did not mess up my  
build process).  
  
Extra thanks to Fujii Masao for pointing out what looked like the  
culprit commit, and to all the reporters for taking the time to test  
what I have sent them.  
  
Reported-by: Andrus, Guy Burgess, Yaroslav Pashinsky, Thomas Trenz  
Reviewed-by: Tom Lane, Andres Freund  
Discussion: https://postgr.es/m/3861ff1e-0923-7838-e826-094cc9bef737@hot.ee  
Discussion: https://postgr.es/m/16874-c3eecd319e36a2bf@postgresql.org  
Discussion: https://postgr.es/m/095ccf8d-7f58-d928-427c-b17ace23cae6@burgess.co.nz  
Discussion: https://postgr.es/m/16927-67c570d968c99567%40postgresql.org  
Discussion: https://postgr.es/m/YFBcRbnBiPdGZvfW@paquier.xyz  
Backpatch-through: 13  

commit   : 8c6eda2d1c926be76baa79c28521275323bd26fd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 22 Mar 2021 12:02:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 22 Mar 2021 12:02:44 +0900    

This commit improves pgbench \sleep command so that it handles  
the following three cases more properly.  
  
(1) When only one argument was specified in \sleep command and  
    it's not a number, previously pgbench reported a confusing error  
    message like "unrecognized time unit, must be us, ms or s".  
    This commit fixes this so that more proper error message like  
    "invalid sleep time, must be an integer" is reported.  
  
(2) When two arguments were specified in \sleep command and  
    the first argument was not a number, previously pgbench treated  
    that argument as the sleep time 0. No error was reported in this  
    case. This commit fixes this so that an error is thrown in this  
    case.  
  
(3) When a variable was specified as the first argument in \sleep  
    command and the variable stored non-digit value, previously  
    pgbench treated that argument as the sleep time 0. No error  
    was reported in this case. This commit fixes this so that  
    an error is thrown in this case.  
  
Author: Kota Miyake  
Reviewed-by: Hayato Kuroda, Alvaro Herrera, Fujii Masao  
Discussion: https://postgr.es/m/23b254daf20cec4332a2d9168505dbc9@oss.nttdata.com  

commit   : e3f4aec027891f794328050e62c9bbbe4ae02811    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 21 Mar 2021 19:09:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 21 Mar 2021 19:09:29 -0700    

Back-patch to v13, which introduced the test code in question.  

commit   : 992d353a190c551db39bcab2dec0ecf14fbc7a40    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 09:51:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 09:51:05 +0900    

The test added by 595b9cb forgot that on Windows it is necessary to set  
up pg_hba.conf (see PostgresNode::set_replication_conf) with a specific  
entry or base backups fail.  Any node that requires to support  
replication just needs to pass down allows_streaming at initialization.  
This updates the test to do so.  Simplify things a bit while on it.  
  
Per buildfarm member fairywren.  Any Windows hosts running this test  
would have failed, and I have reproduced the problem as well.  
  
Backpatch-through: 10  

commit   : 11e1577a576fec6307aa0bfcde7333e63f907fa7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 08:59:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 08:59:43 +0900    

The TAP tests of kerberos rely on the logs generated by the backend to  
check various connection scenarios.  In order to make sure that a given  
test does not overlap with the log contents generated by a previous  
test, the test suite relied on a logic with the logging collector and a  
rotation of the log files to ensure the uniqueness of the log generated  
with a wait phase.  
  
Parsing the log contents for expected patterns is a problem that has  
been solved in a simpler way by PostgresNode::issues_sql_like() where  
the log file is truncated before checking for the contents generated,  
with the backend sending its output to a log file given by pg_ctl  
instead.  This commit switches the kerberos test suite to use such a  
method, removing any wait phase and simplifying the whole logic,  
resulting in less code.  If a failure happens in the tests, the contents  
of the logs are still showed to the user at the moment of the failure  
thanks to like(), so this has no impact on debugging capabilities.  
  
I have bumped into this issue while reviewing a different patch set  
aiming at extending the kerberos test suite to check for multiple  
log patterns instead of one now.  
  
Author: Michael Paquier  
Reviewed-by: Stephen Frost, Bharath Rupireddy  
Discussion: https://postgr.es/m/YFXcq2vBTDGQVBNC@paquier.xyz  

commit   : 595b9cba2ab0cdd057e02d3c23f34a8bcfd90a2d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 08:30:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 08:30:53 +0900    

Any transactions found as still prepared by a checkpoint have their  
state data read from the WAL records generated by PREPARE TRANSACTION  
before being moved into their new location within pg_twophase/.  While  
reading such records, the WAL reader uses the callback  
read_local_xlog_page() to read a page, that is shared across various  
parts of the system.  This callback, since 1148e22a, has introduced an  
update of ThisTimeLineID when reading a record while in recovery, which  
is potentially helpful in the context of cascading WAL senders.  
  
This update of ThisTimeLineID interacts badly with the checkpointer if a  
promotion happens while some 2PC data is read from its record, as, by  
changing ThisTimeLineID, any follow-up WAL records would be written to  
an timeline older than the promoted one.  This results in consistency  
issues.  For instance, a subsequent server restart would cause a failure  
in finding a valid checkpoint record, resulting in a PANIC, for  
instance.  
  
This commit changes the code reading the 2PC data to reset the timeline  
once the 2PC record has been read, to prevent messing up with the static  
state of the checkpointer.  It would be tempting to do the same thing  
directly in read_local_xlog_page().  However, based on the discussion  
that has led to 1148e22a, users may rely on the updates of  
ThisTimeLineID when a WAL record page is read in recovery, so changing  
this callback could break some cases that are working currently.  
  
A TAP test reproducing the issue is added, relying on a PITR to  
precisely trigger a promotion with a prepared transaction still  
tracked.  
  
Per discussion with Heikki Linnakangas, Kyotaro Horiguchi, Fujii Masao  
and myself.  
  
Author: Soumyadeep Chakraborty, Jimmy Yih, Kevin Yeap  
Discussion: https://postgr.es/m/CAE-ML+_EjH_fzfq1F3RJ1=XaaNG=-Jz-i3JqkNhXiLAsM3z-Ew@mail.gmail.com  
Backpatch-through: 10  

commit   : ac897c483485d3858ada23ca49650a0f2742a50f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 18:42:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 18:42:40 -0400    

It's not okay to scribble directly on a syscache entry.  
Nor to continue accessing said entry after releasing it.  
  
Also get rid of not-used local variables.  
  
Per valgrind testing.  

commit   : 9dd963ae2534e9614f0abeccaafbd39f1b93ff8a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 21 Mar 2021 15:25:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 21 Mar 2021 15:25:39 -0700    

Maintain a simple array of metadata about pages that were deleted during  
nbtree VACUUM's current btvacuumscan() call.  Use this metadata at the  
end of btvacuumscan() to attempt to place newly deleted pages in the FSM  
without further delay.  It might not yet be safe to place any of the  
pages in the FSM by then (they may not be deemed recyclable), but we  
have little to lose and plenty to gain by trying.  In practice there is  
a very good chance that this will work out when vacuuming larger  
indexes, where scanning the index naturally takes quite a while.  
  
This commit doesn't change the page recycling invariants; it merely  
improves the efficiency of page recycling within the confines of the  
existing design.  Recycle safety is a part of nbtree's implementation of  
what Lanin & Shasha call "the drain technique".  The design happens to  
use transaction IDs (they're stored in deleted pages), but that in  
itself doesn't align the cutoff for recycle safety to any of the  
XID-based cutoffs used by VACUUM (e.g., OldestXmin).  All that matters  
is whether or not _other_ backends might be able to observe various  
inconsistencies in the tree structure (that they cannot just detect and  
recover from by moving right).  Recycle safety is purely a question of  
maintaining the consistency (or the apparent consistency) of a physical  
data structure.  
  
Note that running a simple serial test case involving a large range  
DELETE followed by a VACUUM VERBOSE will probably show that any newly  
deleted nbtree pages are not yet reusable/recyclable.  This is expected  
in the absence of even one concurrent XID assignment.  It is an old  
implementation restriction.  In practice it's unlikely to be the thing  
that makes recycling remain unsafe, at least with larger indexes, where  
recycling newly deleted pages during the same VACUUM actually matters.  
  
An important high-level goal of this commit (as well as related recent  
commits e5d8a999 and 9f3665fb) is to make expensive deferred cleanup  
operations in index AMs rare in general.  If index vacuuming frequently  
depends on the next VACUUM operation finishing off work that the current  
operation started, then the general behavior of index vacuuming is hard  
to predict.  This is relevant to ongoing work that adds a vacuumlazy.c  
mechanism to skip index vacuuming in certain cases.  Anything that makes  
the real world behavior of index vacuuming simpler and more linear will  
also make top-down modeling in vacuumlazy.c more robust.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAH2-Wzk76_P=67iUscb1UN44-gyZL-KgpsXbSxq_bdcMa7Q+wQ@mail.gmail.com  

commit   : 4d399a6fbeb720b34d33441330910b7d853f703d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 17:20:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 17:20:17 -0400    

It's not okay to just shove the pkg_config results right into our  
build flags, for a couple different reasons:  
  
* This fails to maintain the separation between CPPFLAGS and CFLAGS,  
as well as that between LDFLAGS and LIBS.  (The CPPFLAGS angle is,  
I believe, the reason for warning messages reported when building  
with MacPorts' liblz4.)  
  
* If pkg_config emits anything other than -I/-D/-L/-l switches,  
it's highly unlikely that we want to absorb those.  That'd be more  
likely to break the build than do anything helpful.  (Even the -D  
case is questionable; but we're doing that for libxml2, so I kept it.)  
  
Also, it's not okay to skip doing an AC_CHECK_LIB probe, as  
evidenced by recent build failure on topminnow; that should  
have been caught at configure time.  
  
Model fixes for this on configure's libxml2 support.  
  
It appears that somebody overlooked an autoheader run, too.  
  
Discussion: https://postgr.es/m/20210119190720.GL8560@telsasoft.com  

commit   : fd1ac9a548966786cf7978e590be816c55936a50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 16:26:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 16:26:44 -0400    

This test will fail in "make installcheck" if the installation's  
default_toast_compression setting is not 'pglz'.  Make it robust  
against that situation.  
  
Dilip Kumar  
  
Discussion: https://postgr.es/m/CAFiTN-t0w+Rc2U3S+y=7KWcLuOYNB5MfWeGdNa7+pg0UovVdcQ@mail.gmail.com  

commit   : ef823873840c9f341239e18633bdb0116d8d2738    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 21 Mar 2021 15:04:45 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 21 Mar 2021 15:04:45 -0400    

This reverts commit 677271a3a125e294b33b891669f594a2c8cb36ce.  
"Unbreak recovery test on Windows"  
  
The test hangs on Windows, and attempts to remedy the problem have  
proved fragile at best. So we simply disable the test on Windows perl.  
(Msys perl seems perfectly happy).  
  
Discussion: https://postgr.es/m/5b748470-7335-5439-e876-6a88c951e1c5@dunslane.net  

commit   : 2b526ed2e1cbaa54e5ad0c12d1294482f2757b17    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 21 Mar 2021 14:55:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 21 Mar 2021 14:55:27 -0300    

My oversight in commit 9aa491abbf07.  
  
Per coverity.  

commit   : 677271a3a125e294b33b891669f594a2c8cb36ce    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 21 Mar 2021 11:52:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 21 Mar 2021 11:52:30 -0400    

On Windows we need to send explicit quit messages to psql or the TAP tests  
can hang.  

commit   : 9fb9691a88ae8df9bc30e0f0f72de7c96e73e125    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 11:50:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Mar 2021 11:50:43 -0400    

Compilers that don't understand that elog(ERROR) doesn't return  
issued warnings here.  In the cases in libpq_pipeline.c, we were  
not exactly helping things by failing to mark pg_fatal() as noreturn.  
  
Per buildfarm.  

commit   : 96ae658e6238c5e69819fb1557c2c14a555506d8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 21 Mar 2021 08:02:30 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 21 Mar 2021 08:02:30 +0100    

The documentation specifically states that lwlock-release fires before  
any released waiters have been awakened.  It worked that way until  
ab5194e6f617a9a9e7aadb3dd1cee948a42d0755, where is seems to have been  
misplaced accidentally.  Move it back where it belongs.  
  
Author: Craig Ringer <craig.ringer@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/CAGRY4nwxKUS_RvXFW-ugrZBYxPFFM5kjwKT5O+0+Stuga5b4+Q@mail.gmail.com  

commit   : 882b2cdc08c4100e273f24742e2118be98708a07    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 21 Mar 2021 00:28:13 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 21 Mar 2021 00:28:13 +0100    

When compressing the BRIN summary, we can't simply use the compression  
method from the indexed attribute.  The summary may use a different data  
type, e.g. fixed-length attribute may have varlena summary, leading to  
compression failures.  For the built-in BRIN opclasses this happens to  
work, because the summary uses the same data type as the attribute.  
  
When the data types match, we can inherit use the compression method  
specified for the attribute (it's copied into the index descriptor).  
Otherwise we don't have much choice and have to use the default one.  
  
Author: Tomas Vondra  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/e0367f27-392c-321a-7411-a58e1a7e4817%40enterprisedb.com  

commit   : aa25d1089ac00bbc3f97d2efe8f54c3d4beed5d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Mar 2021 15:01:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Mar 2021 15:01:10 -0400    

The approach used in commit bbe0a81db would've been disastrous for  
portability of dumps.  Instead handle non-default compression options  
in separate ALTER TABLE commands.  This reduces chatter for the  
common case where most columns are compressed the same way, and it  
makes it possible to restore the dump to a server that lacks any  
knowledge of per-attribute compression options (so long as you're  
willing to ignore syntax errors from the ALTER TABLE commands).  
  
There's a whole lot left to do to mop up after bbe0a81db, but  
I'm fast-tracking this part because we need to see if it's  
enough to make the buildfarm's cross-version-upgrade tests happy.  
  
Justin Pryzby and Tom Lane  
  
Discussion: https://postgr.es/m/20210119190720.GL8560@telsasoft.com  

commit   : e835e89a0fd267871e7fbddc39ad00ee3d0cb55c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Mar 2021 12:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Mar 2021 12:47:21 -0400    

While back-patching e0e569e1d, I noted that there were some other  
places where we ought to be applying DH_free(); namely, where we  
load some DH parameters from a file and then reject them as not  
being sufficiently secure.  While it seems really unlikely that  
anybody would hit these code paths in production, let alone do  
so repeatedly, let's fix it for consistency.  
  
Back-patch to v10 where this code was introduced.  
  
Discussion: https://postgr.es/m/16160-18367e56e9a28264@postgresql.org  

commit   : f0c2a5bba6c566fad781802537eb17f2977702bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Mar 2021 23:03:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Mar 2021 23:03:17 -0400    

RestoreGUCState applied InitializeOneGUCOption to already-live  
GUC entries, causing any malloc'd subsidiary data to be forgotten.  
We do want the effect of resetting the GUC to its compiled-in  
default, and InitializeOneGUCOption seems like the best way to do  
that, so add code to free any existing subsidiary data beforehand.  
  
The interaction between can_skip_gucvar, SerializeGUCState, and  
RestoreGUCState is way more subtle than their opaque comments  
would suggest to an unwary reader.  Rewrite and enlarge the  
comments to try to make it clearer what's happening.  
  
Remove a long-obsolete assertion in read_nondefault_variables: the  
behavior of set_config_option hasn't depended on IsInitProcessingMode  
since f5d9698a8 installed a better way of controlling it.  
  
Although this is fixing a clear memory leak, the leak is quite unlikely  
to involve any large amount of data, and it can only happen once in the  
lifetime of a worker process.  So it seems unnecessary to take any  
risk of back-patching.  
  
Discussion: https://postgr.es/m/4105247.1616174862@sss.pgh.pa.us  

commit   : 61752afb26404dfc99a535c7a53f7f04dc110263    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 20 Mar 2021 11:46:32 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 20 Mar 2021 11:46:32 +1300    

Since commit 2ce439f3 we have opened every file in the data directory  
and called fsync() at the start of crash recovery.  This can be very  
slow if there are many files, leading to field complaints of systems  
taking minutes or even hours to begin crash recovery.  
  
Provide an alternative method, for Linux only, where we call syncfs() on  
every possibly different filesystem under the data directory.  This is  
equivalent, but avoids faulting in potentially many inodes from  
potentially slow storage.  
  
The new mode comes with some caveats, described in the documentation, so  
the default value for the new setting is "fsync", preserving the older  
behavior.  
  
Reported-by: Michael Brown <michael.brown@discourse.org>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Paul Guo <guopa@vmware.com>  
Reviewed-by: Bruce Momjian <bruce@momjian.us>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: David Steele <david@pgmasters.net>  
Discussion: https://postgr.es/m/11bc2bb7-ecb5-3ad0-b39f-df632734cd81%40discourse.org  
Discussion: https://postgr.es/m/CAEET0ZHGnbXmi8yF3ywsDZvb3m9CbdsGZgfTXscQ6agcbzcZAw%40mail.gmail.com  

commit   : b822ae13ea93c18326d58d47829bbc66d36fae5c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Mar 2021 23:57:50 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Mar 2021 23:57:50 +0100    

The function added in be45be9c33 is comparing integer lists (IntList) by  
length and contents, but there were two bugs.  Firstly, it used intVal()  
to extract the value, but that's for Value nodes, not for extracting int  
values from IntList.  Secondly, it called it directly on the ListCell,  
without doing lfirst().  So just do lfirst_int() instead.  
  
Interestingly enough, this did not cause any crashes on the buildfarm,  
but valgrind rightfully complained about it.  
  
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org  

commit   : d00fbdc431192c3e429b3e91c43d364e5c7ba680    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Mar 2021 17:17:48 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Mar 2021 17:17:48 -0400    

Introduced by commit bbe0a81db69bd10bd166907c3701492a29aca294.  
  
Per buildfarm member prion.  

commit   : bbe0a81db69bd10bd166907c3701492a29aca294    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Mar 2021 15:10:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Mar 2021 15:10:38 -0400    

There is now a per-column COMPRESSION option which can be set to pglz  
(the default, and the only option in up until now) or lz4. Or, if you  
like, you can set the new default_toast_compression GUC to lz4, and  
then that will be the default for new table columns for which no value  
is specified. We don't have lz4 support in the PostgreSQL code, so  
to use lz4 compression, PostgreSQL must be built --with-lz4.  
  
In general, TOAST compression means compression of individual column  
values, not the whole tuple, and those values can either be compressed  
inline within the tuple or compressed and then stored externally in  
the TOAST table, so those properties also apply to this feature.  
  
Prior to this commit, a TOAST pointer has two unused bits as part of  
the va_extsize field, and a compessed datum has two unused bits as  
part of the va_rawsize field. These bits are unused because the length  
of a varlena is limited to 1GB; we now use them to indicate the  
compression type that was used. This means we only have bit space for  
2 more built-in compresison types, but we could work around that  
problem, if necessary, by introducing a new vartag_external value for  
any further types we end up wanting to add. Hopefully, it won't be  
too important to offer a wide selection of algorithms here, since  
each one we add not only takes more coding but also adds a build  
dependency for every packager. Nevertheless, it seems worth doing  
at least this much, because LZ4 gets better compression than PGLZ  
with less CPU usage.  
  
It's possible for LZ4-compressed datums to leak into composite type  
values stored on disk, just as it is for PGLZ. It's also possible for  
LZ4-compressed attributes to be copied into a different table via SQL  
commands such as CREATE TABLE AS or INSERT .. SELECT.  It would be  
expensive to force such values to be decompressed, so PostgreSQL has  
never done so. For the same reasons, we also don't force recompression  
of already-compressed values even if the target table prefers a  
different compression method than was used for the source data.  These  
architectural decisions are perhaps arguable but revisiting them is  
well beyond the scope of what seemed possible to do as part of this  
project.  However, it's relatively cheap to recompress as part of  
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do  
so, if the configured compression method of the table happens not to  
match what was used for some column value stored therein.  
  
Dilip Kumar. The original patches on which this work was based were  
written by Ildus Kurbangaliev, and those were patches were based on  
even earlier work by Nikita Glukhov, but the design has since changed  
very substantially, since allow a potentially large number of  
compression methods that could be added and dropped on a running  
system proved too problematic given some of the architectural issues  
mentioned above; the choice of which specific compression method to  
add first is now different; and a lot of the code has been heavily  
refactored.  More recently, Justin Przyby helped quite a bit with  
testing and reviewing and this version also includes some code  
contributions from him. Other design input and review from Tomas  
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander  
Korotkov, and me.  
  
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain  
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com  

commit   : e589c4890b05044a04207c2797e7c8af6693ea5f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Mar 2021 18:12:39 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Mar 2021 18:12:39 +0100    

The TAP test was written so that it was not waiting for the correct SQL  
command, but for output from the preceding one.  This resulted in race  
conditions, allowing the commands to run in a different order, not block  
as expected and so on.  This fixes it by inverting the order of commands  
where possible, so that observing the output guarantees the data was  
inserted properly, and waiting for a lock to appear in pg_locks.  
  
Discussion: https://postgr.es/m/CAH503wDKdYzyq7U-QJqGn%3DGm6XmoK%2B6_6xTJ-Yn5WSvoHLY1Ww%40mail.gmail.com  

commit   : 27ab1981e7c9b8fcbcb143c5f6f706441a52bbc8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:43:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:43:03 -0400    

Buildfarm member fairywren doesn't like the test case I added  
in commit 081876d75.  I'm guessing the reason is that I shouldn't  
be using a perl2host-ified path in the tar command line.  

commit   : fd31214075cc740e43edc71ca1c385c8c53047b7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Mar 2021 11:28:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Mar 2021 11:28:54 +0900    

Commit 86c23a6eb2 changed the option to specify that postgres will  
stop all other server processes by sending the signal SIGSTOP,  
from -s to -T. But previously there were comments incorrectly  
explaining that SIGSTOP behavior is set by -s option. This commit  
fixes them.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20210316.165141.1400441966284654043.horikyota.ntt@gmail.com  

commit   : 9bacdf9f536a3720976ae258238cb46c691ce9b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:21:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:21:58 -0400    

We leaked the error report from PQconninfoParse, when there was  
one.  It seems unlikely that real usage patterns would repeat  
the failure often enough to create serious bloat, but let's  
back-patch anyway to keep the code similar in all branches.  
  
Found via valgrind testing.  
Back-patch to v10 where this code was added.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : 377b7a83007d277d32ef19f7c7590c8668d504cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:09:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:09:41 -0400    

Because guc.c prefers to keep all its string values in malloc'd  
not palloc'd storage, it has to be more careful than usual to  
avoid leaks.  Error exits out of string GUC hook checks failed  
to clear the proposed value string, and error exits out of  
ProcessGUCArray() failed to clear the malloc'd results of  
ParseLongOption().  
  
Found via valgrind testing.  
This problem is ancient, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : d303849b059c3c315e5a8d4239016f8328f3296c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 21:44:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 21:44:42 -0400    

The text search cache mechanisms assume that we can clean up  
an invalidated dictionary cache entry simply by resetting the  
associated long-lived memory context.  However, that does not work  
for ispell affixes that make use of regular expressions, because  
the regex library deals in plain old malloc.  Hence, we leaked  
compiled regex(es) any time we dropped such a cache entry.  That  
could quickly add up, since even a fairly trivial regex can use up  
tens of kB, and a large one can eat megabytes.  Add a memory context  
callback to ensure that a regex gets freed when its owning cache  
entry is cleared.  
  
Found via valgrind testing.  
This problem is ancient, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : 415ffdc2205e209b6a73fb42a3fdd6e57e16c7b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:50:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:50:56 -0400    

Some code paths in this function perform syscache lookups, which  
can lead to table accesses and possibly leakage of cruft into  
the caller's context.  If said context is CacheMemoryContext,  
we eventually will have visible bloat.  But fixing this is no  
harder than moving one memory context switch step.  (The other  
callers don't have a problem.)  
  
Andres Freund and I independently found this via valgrind testing.  
Back-patch to v12 where this code was added.  
  
Discussion: https://postgr.es/m/20210317023101.anvejcfotwka6gaa@alap3.anarazel.de  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : 28644fac10731e30e70b622986a6fbbeb5a5b2f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:37:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:37:09 -0400    

Although these lists are usually NIL, and even when not empty  
are unlikely to be large, constant relcache update traffic could  
eventually result in visible bloat of CacheMemoryContext.  
  
Found via valgrind testing.  
Back-patch to v10 where this field was added.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : a16b2b960f0eec2fe367e86017b3c24ed688ba2b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Mar 2021 02:05:23 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Mar 2021 02:05:23 +0100    

The test included in cd91de0d17 had two simple flaws.  
  
Firstly, the number of rows was low and on some platforms (e.g. 32-bit)  
the sort did not require on-disk sort, so on those machines it was not  
testing the automatic removal.  The test was however failing, because  
without any temporary files the base/pgsql_tmp directory was not even  
created.  Fixed by increasing the rowcount to 5000, which should be high  
engough on any platform.  
  
Secondly, the test used a simple sleep to wait for the temporary file to  
be created.  This is obviously problematic, because on slow machines (or  
with valgrind, CLOBBER_CACHE_ALWAYS etc.) it may take a while to create  
the temporary file.  But we also want the tests run reasonably fast.  
Fixed by instead relying on a UNIQUE constraint, blocking the query that  
created the temporary file.  
  
Author: Euler Taveira  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/CAH503wDKdYzyq7U-QJqGn%3DGm6XmoK%2B6_6xTJ-Yn5WSvoHLY1Ww%40mail.gmail.com  

commit   : 5b2266e33fc74142d23685bdf54f64ad598fbdea    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Mar 2021 09:18:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Mar 2021 09:18:41 +0900    

Only "IMPORT" was showing as result of the completion, while IMPORT  
FOREIGN SCHEMA is the only command using this keyword in first  
position.  This changes the completion to show the full command name  
instead of just "IMPORT".  
  
Reviewed-by: Georgios Kokolatos, Julien Rouhaud  
Discussion: https://postgr.es/m/YFL6JneBiuMWYyoh@paquier.xyz  

commit   : 1d581ce7129d7a33cd4ad27f8f246abfa1fd2db9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 19:24:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 19:24:22 -0400    

Our coding convention requires this macro's result to be assigned  
back to the original List variable.  In this usage, since the  
List could not become empty, there was no actual bug --- but  
some compilers warned about it.  Oversight in be45be9c3.  
  
Discussion: https://postgr.es/m/35077b31-2d62-1e31-0e2e-ddb52d590b73@enterprisedb.com  

commit   : be45be9c33a85e72cdaeb9967e9f6d2d00199e09    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Mar 2021 17:45:38 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Mar 2021 17:45:38 +0100    

With grouping sets, it's possible that some of the grouping sets are  
duplicate.  This is especially common with CUBE and ROLLUP clauses. For  
example GROUP BY CUBE (a,b), CUBE (b,c) is equivalent to  
  
  GROUP BY GROUPING SETS (  
    (a, b, c),  
    (a, b, c),  
    (a, b, c),  
    (a, b),  
    (a, b),  
    (a, b),  
    (a),  
    (a),  
    (a),  
    (c, a),  
    (c, a),  
    (c, a),  
    (c),  
    (b, c),  
    (b),  
    ()  
  )  
  
Some of the grouping sets are calculated multiple times, which is mostly  
unnecessary.  This commit implements a new GROUP BY DISTINCT feature, as  
defined in the SQL standard, which eliminates the duplicate sets.  
  
Author: Vik Fearing  
Reviewed-by: Erik Rijkers, Georgios Kokolatos, Tomas Vondra  
Discussion: https://postgr.es/m/bf3805a8-d7d1-ae61-fece-761b7ff41ecc@postgresfriends.org  

commit   : cd91de0d17952b5763466cfa663e98318f26d357    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Mar 2021 16:05:03 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Mar 2021 16:05:03 +0100    

After a crash of a backend using temporary files, the files used to be  
left behind, on the basis that it might be useful for debugging. But we  
don't have any reports of anyone actually doing that, and it means the  
disk usage may grow over time due to repeated backend failures (possibly  
even hitting ENOSPC). So this behavior is a bit unfortunate, and fixing  
it required either manual cleanup (deleting files, which is error-prone)  
or restart of the instance (i.e. service disruption).  
  
This implements automatic cleanup of temporary files, controled by a new  
GUC remove_temp_files_after_crash. By default the files are removed, but  
it can be disabled to restore the old behavior if needed.  
  
Author: Euler Taveira  
Reviewed-by: Tomas Vondra, Michael Paquier, Anastasia Lubennikova, Thomas Munro  
Discussion: https://postgr.es/m/CAH503wDKdYzyq7U-QJqGn%3DGm6XmoK%2B6_6xTJ-Yn5WSvoHLY1Ww%40mail.gmail.com  

commit   : da18d829c28197efb04805a43f129f62650e50c8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Mar 2021 11:17:42 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Mar 2021 11:17:42 +0100    

pg_read_file() is the function that's in core, pg_file_read() is in  
adminpack. But when using pg_file_read() in adminpack it calls the *C*  
level function pg_read_file() in core, which probably threw the original  
author off. But the error hint should be about the SQL function.  
  
Reported-By: Sergei Kornilov  
Backpatch-through: 11  
Discussion: https://postgr.es/m/373021616060475@mail.yandex.ru  

commit   : ed62d3737c1b823f796d974060b1d0295a3dd831    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 18 Mar 2021 15:34:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 18 Mar 2021 15:34:55 +0530    

Commit c8f78b6161 added a new reloption to enable inserts in parallel-mode  
but forgot to update at one of the places about the same in docs. In  
passing, fix a typo in the same commit.  
  
Reported-by: Justin Pryzby  
Author: Justin Pryzby  
Reviewed-by: "Hou, Zhijie", Amit Kapila  
Discussion: https://postgr.es/m/20210318025228.GE11765@telsasoft.com  

commit   : c8f78b616167bf8e24bc5dc69112c37755ed3058    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 18 Mar 2021 07:25:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 18 Mar 2021 07:25:27 +0530    

Commit 05c8482f7f added the implementation of parallel SELECT for  
"INSERT INTO ... SELECT ..." which may incur non-negligible overhead in  
the additional parallel-safety checks that it performs, even when, in the  
end, those checks determine that parallelism can't be used. This is  
normally only ever a problem in the case of when the target table has a  
large number of partitions.  
  
A new GUC option "enable_parallel_insert" is added, to allow insert in  
parallel-mode. The default is on.  
  
In addition to the GUC option, the user may want a mechanism to allow  
inserts in parallel-mode with finer granularity at table level. The new  
table option "parallel_insert_enabled" allows this. The default is true.  
  
Author: "Hou, Zhijie"  
Reviewed-by: Greg Nancarrow, Amit Langote, Takayuki Tsunakawa, Amit Kapila  
Discussion: https://postgr.es/m/CAA4eK1K-cW7svLC2D7DHoGHxdAdg3P37BLgebqBOC2ZLc9a6QQ%40mail.gmail.com  
Discussion: https://postgr.es/m/CAJcOf-cXnB5cnMKqWEp2E2z7Mvcd04iLVmV=qpFJrR3AcrTS3g@mail.gmail.com  

commit   : 5f79580ad69f6e696365bdc63bc265f45bd77211    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Mar 2021 16:18:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Mar 2021 16:18:37 -0700    

When accessing replication slot stats, introduced in 98681675002d,  
pgstat_read_statsfiles() reads the data into newly allocated  
memory. Unfortunately the current memory context at that point is the  
callers, leading to leaks and use-after-free dangers.  
  
The fix is trivial, explicitly use pgStatLocalContext. There's some  
potential for further improvements, but that's outside of the scope of  
this bugfix.  
  
No backpatch necessary, feature is only in HEAD.  
  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20210317230447.c7uc4g3vbs4wi32i@alap3.anarazel.de  

commit   : 70945649d734d16be22c3d1d90dd8c3d3c1e9d89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:39:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:39:58 -0400    

Seems to have been a copy-and-paste mistake in 093129c9d.  
Per report from max1@inbox.ru.  
  
Discussion: https://postgr.es/m/161591740692.24273.4202054598867879464@wrigleys.postgresql.org  

commit   : 8620a7f6dbdf978e57cdb9f42802a0418656d863    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:18:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:18:46 -0400    

While looking at Robert Foggia's report, I noticed a passel of  
other issues in the same area:  
  
* The scheme for backslash-quoting newlines in pathnames is just  
wrong; it will misbehave if the last ordinary character in a pathname  
is a backslash.  I'm not sure why we're bothering to allow newlines  
in tablespace paths, but if we're going to do it we should do it  
without introducing other problems.  Hence, backslashes themselves  
have to be backslashed too.  
  
* The author hadn't read the sscanf man page very carefully, because  
this code would drop any leading whitespace from the path.  (I doubt  
that a tablespace path with leading whitespace could happen in  
practice; but if we're bothering to allow newlines in the path, it  
sure seems like leading whitespace is little less implausible.)  Using  
sscanf for the task of finding the first space is overkill anyway.  
  
* While I'm not 100% sure what the rationale for escaping both \r and  
\n is, if the idea is to allow Windows newlines in the file then this  
code failed, because it'd throw an error if it saw \r followed by \n.  
  
* There's no cross-check for an incomplete final line in the map file,  
which would be a likely apparent symptom of the improper-escaping  
bug.  
  
On the generation end, aside from the escaping issue we have:  
  
* If needtblspcmapfile is true then do_pg_start_backup will pass back  
escaped strings in tablespaceinfo->path values, which no caller wants  
or is prepared to deal with.  I'm not sure if there's a live bug from  
that, but it looks like there might be (given the dubious assumption  
that anyone actually has newlines in their tablespace paths).  
  
* It's not being very paranoid about the possibility of random stuff  
in the pg_tblspc directory.  IMO we should ignore anything without an  
OID-like name.  
  
The escaping rule change doesn't seem back-patchable: it'll require  
doubling of backslashes in the tablespace_map file, which is basically  
a basebackup format change.  The odds of that causing trouble are  
considerably more than the odds of the existing bug causing trouble.  
The rest of this seems somewhat unlikely to cause problems too,  
so no back-patch.  

commit   : a50e4fd028a1ece2b1a04df2c9ae6581783e9eef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:10:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:10:37 -0400    

Robert Foggia of Trustwave reported that read_tablespace_map()  
fails to prevent an overrun of its on-stack input buffer.  
Since the tablespace map file is presumed trustworthy, this does  
not seem like an interesting security vulnerability, but still  
we should fix it just in the name of robustness.  
  
While here, document that pg_basebackup's --tablespace-mapping option  
doesn't work with tar-format output, because it doesn't.  To make it  
work, we'd have to modify the tablespace_map file within the tarball  
sent by the server, which might be possible but I'm not volunteering.  
(Less-painful solutions would require changing the basebackup protocol  
so that the source server could adjust the map.  That's not very  
appetizing either.)  

commit   : 081876d75ea15c3bd2ee5ba64a794fd8ea46d794    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 14:52:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 14:52:55 -0400    

The existing test script does run pg_basebackup with the -Ft option,  
but it makes no real attempt to verify the sanity of the results.  
We wouldn't know if the output is incompatible with standard "tar"  
programs, nor if the server fails to start from the restored output.  
Notably, this means that xlog.c's read_tablespace_map() is not being  
meaningfully tested, since that code is used only in the tar-format  
case.  (We do have reasonable coverage of restoring from plain-format  
output, though it's over in src/test/recovery not here.)  
  
Hence, attempt to untar the output and start a server from it,  
rather just hoping it's OK.  
  
This test assumes that the local "tar" has the "-C directory"  
switch.  Although that's not promised by POSIX, my research  
suggests that all non-extinct tar implementations have it.  
Should the buildfarm's opinion differ, we can complicate the  
test a bit to avoid requiring that.  
  
Possibly this should be back-patched, but I'm unsure about  
whether it could work on Windows before d66b23b03.  

commit   : c783e656d41816b0328cb4bff27f11b70200770e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 13:09:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 13:09:13 -0400    

This was a bit disjointed, partly because of a not-well-considered  
decision to document SQL commands that don't return result rows as  
though they had nothing in common with commands that do.  Rearrange  
so that we have one discussion of variable substitution that clearly  
applies to all types of SQL commands, and then handle the question  
of processing command output separately.  Clarify that EXPLAIN,  
CREATE TABLE AS SELECT, and similar commands that incorporate an  
optimizable statement will act like optimizable statements for the  
purposes of variable substitution.  Do a bunch of minor wordsmithing  
in the same area.  
  
David Johnston and Tom Lane, reviewed by Pavel Stehule and David  
Steele  
  
Discussion: https://postgr.es/m/CAKFQuwYvMKucM5fnZvHSo-ah4S=_n9gmKeu6EAo=_fTrohunqQ@mail.gmail.com  

commit   : 7f7f25f15edb6eacec58179ef5285e874aa4435b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 18 Mar 2021 00:35:04 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 18 Mar 2021 00:35:04 +1300    

This reverts commit 378802e3713c6c0fce31d2390c134cd5d7c30157.  
This reverts commit 3b8981b6e1a2aea0f18384c803e21e9391de669a.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJmcqAE3MZeDCLLXa62cWM0AJbKmp2JrJYaJ86bz36LFA%40mail.gmail.com  

commit   : 9fd2952cf4920d563e9cea51634c5b364d57f71a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Mar 2021 18:07:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 Mar 2021 18:07:00 +0900    

578b229, that removed support for WITH OIDS, has changed  
CatalogTupleInsert() to not return an Oid, but one comment was still  
mentioning that.  
  
Author: Vik Fearing  
Discussion: https://postgr.es/m/fef01975-ed10-3601-7b9e-80ecef72d00b@postgresfriends.org  

commit   : e1ae40f381d0582981b1e63856bd4b060cfe2d53    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 17 Mar 2021 08:17:33 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 17 Mar 2021 08:17:33 +0100    

commit   : 378802e3713c6c0fce31d2390c134cd5d7c30157    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 18:24:45 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 18:24:45 +1300    

Commit 3048898e dropped -ING from some wait event names that correspond  
to barrier phases.  Update the phases' names to match.  
  
While we're here making cosmetic changes, also rename "DONE" to "FREE".  
That pairs better with "ALLOCATE", and describes the activity that  
actually happens in that phase (as we do for the other phases) rather  
than describing a state.  The distinction is clearer after bugfix commit  
3b8981b6 split the phase into two.  As for the growth barriers, rename  
their "ALLOCATE" phase to "REALLOCATE", which is probably a better  
description of what happens then.  Also improve the comments about  
the phases a bit.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2BMDpwF2Eo2LAvzd%3DpOh81wUTsrwU1uAwR-v6OGBB6%2B7g%40mail.gmail.com  

commit   : 3b8981b6e1a2aea0f18384c803e21e9391de669a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 17:46:39 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 17:46:39 +1300    

With very unlucky timing and parallel_leader_participation off, PHJ  
could attempt to access per-batch state just as it was being freed.  
There was code intended to prevent that by checking for a cleared  
pointer, but it was buggy.  
  
Fix, by introducing an extra barrier phase.  The new phase  
PHJ_BUILD_RUNNING means that it's safe to access the per-batch state to  
find a batch to help with, and PHJ_BUILD_DONE means that it is too late.  
The last to detach will free the array of per-batch state as before, but  
now it will also atomically advance the phase at the same time, so that  
late attachers can avoid the hazard, without the data race.  This  
mirrors the way per-batch hash tables are freed (see phases  
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).  
  
Revealed by a one-off build farm failure, where BarrierAttach() failed a  
sanity check assertion, because the memory had been clobbered by  
dsa_free().  
  
Back-patch to 11, where the code arrived.  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz  

commit   : 37929599499fe5760a9dbab48a10a898879a0d44    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 17:13:43 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 17:13:43 +1300    

It seems like a useful sanity check to be able to run "installcheck"  
against a cluster running with default_transaction_level set to  
serializable or repeatable read.  Only one thing currently fails in  
those configurations, so let's fix that.  
  
No back-patch for now, because it fails in many other places in some of  
the stable branches.  We'd have to go back and fix those too if we  
included this configuration in automated testing.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CA%2BhUKGJUaHeK%3DHLATxF1JOKDjKJVrBKA-zmbPAebOM0Se2FQRg%40mail.gmail.com  

commit   : 6b67d72b604cb913e39324b81b61ab194d94cba0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 17 Mar 2021 08:15:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 17 Mar 2021 08:15:12 +0530    

Commit ce0fdbfe97 made tablesync slots permanent and allow Drop  
Subscription to drop such slots. However, it is possible that before  
tablesync worker could get the acknowledgment of slot creation, drop  
subscription stops it and that can lead to a dangling slot on the  
publisher. Prevent cancel/die interrupts while creating a slot in the  
tablesync worker.  
  
Reported-by: Thomas Munro as per buildfarm  
Author: Amit Kapila  
Reviewed-by: Vignesh C, Takamichi Osumi  
Discussion: https://postgr.es/m/CA+hUKGJG9dWpw1cOQ2nzWU8PHjm=PTraB+KgE5648K9nTfwvxg@mail.gmail.com  

commit   : 7efeb214ad832fa96ea950d0906b1d2b96316d15    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 17 Mar 2021 07:40:23 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 17 Mar 2021 07:40:23 +0530    

Commit 464824323e added a new column substream in pg_subscription but  
forgot to update the docs.  
  
Reported-by: Peter Smith  
Author: Amit Kapila  
Reviewed-by: Peter Smith  
Discussion: https://postgr.es/m/CAHut+PuPGGASnh2Dy37VYODKULVQo-5oE=Shc6gwtRizDt==cA@mail.gmail.com  

commit   : 9e7ccd9ef64d05e87ceb1985d459bef9031205c0    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 13:43:08 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 13:43:08 +1300    

Pass CURSOR_OPT_PARALLEL_OK to pg_plan_query() so that parallel plans  
are considered when running the underlying SELECT query.  This wasn't  
done in commit e9baa5e9, which did this for CREATE MATERIALIZED VIEW,  
because it wasn't yet known to be safe.  
  
Since REFRESH always inserts into a freshly created table before later  
merging or swapping the data into place with separate operations, we can  
enable such plans here too.  
  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Hou, Zhijie <houzj.fnst@cn.fujitsu.com>  
Reviewed-by: Luc Vlaming <luc@swarm64.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/CALj2ACXg-4hNKJC6nFnepRHYT4t5jJVstYvri%2BtKQHy7ydcr8A%40mail.gmail.com  

commit   : fbe4cb3bd49f9e524f53ef77c775c1bad4d0312a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 16 Mar 2021 13:38:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 16 Mar 2021 13:38:52 -0700    

Oversight in commit d168b666823, which added bottom-up index deletion.  

commit   : 65445469d6de3670f3e027236613e093e119ec55    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 16 Mar 2021 13:11:17 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 16 Mar 2021 13:11:17 -0700    

Empty sibling pages can occasionally be much more common than any other  
event that we report on at elevel DEBUG1.  Increase the elevel for  
relevant cases to DEBUG2 to avoid overwhelming the user with relatively  
insignificant details.  

commit   : 4b12ab18c9d0735d760bf7667b158707b06e5df8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Mar 2021 16:02:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Mar 2021 16:02:49 -0400    

After reading the root cert list from the ssl_ca_file, immediately  
install it as client CA list of the new SSL context.  That gives the  
SSL context ownership of the list, so that SSL_CTX_free will free it.  
This avoids a permanent memory leak if we fail further down in  
be_tls_init(), which could happen if bogus CRL data is offered.  
  
The leak could only amount to something if the CRL parameters get  
broken after server start (else we'd just quit) and then the server  
is SIGHUP'd many times without fixing the CRL data.  That's rather  
unlikely perhaps, but it seems worth fixing, if only because the  
code is clearer this way.  
  
While we're here, add some comments about the memory management  
aspects of this logic.  
  
Noted by Jelte Fennema and independently by Andres Freund.  
Back-patch to v10; before commit de41869b6 it doesn't matter,  
since we'd not re-execute this code during SIGHUP.  
  
Discussion: https://postgr.es/m/16160-18367e56e9a28264@postgresql.org  

commit   : 4078ce65a0f7197180a9be2c6460ea4bf909bd98    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Mar 2021 15:42:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Mar 2021 15:42:20 -0400    

Don't complain about the last TOAST chunk number being different  
from what we expected if there are no TOAST chunks at all.  
In such a case, saying that the final chunk number is 0 is not  
really accurate, and the fact the value is missing from the  
TOAST table is reported separately anyway.  
  
Mark Dilger  
  
Discussion: http://postgr.es/m/AA5506CE-7D2A-42E4-A51D-358635E3722D@enterprisedb.com  

commit   : c6fc50cb40285141fad401321ae21becbaea1c59    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 16 Mar 2021 14:46:48 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 16 Mar 2021 14:46:48 -0400    

When we have posix_fadvise() available, we can improve the performance  
of an ANALYZE by quite a bit by using it to inform the kernel of the  
blocks that we're going to be asking for.  Similar to bitmap index  
scans, the number of buffers pre-fetched is based off of the  
maintenance_io_concurrency setting (for the particular tablespace or,  
if not set, globally, via get_tablespace_maintenance_io_concurrency()).  
  
Reviewed-By: Heikki Linnakangas, Tomas Vondra  
Discussion: https://www.postgresql.org/message-id/VI1PR0701MB69603A433348EDCF783C6ECBF6EF0%40VI1PR0701MB6960.eurprd07.prod.outlook.com  

commit   : 94d13d474dc61800e8a17cc1959c55815b050ecd    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 16 Mar 2021 14:46:48 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 16 Mar 2021 14:46:48 -0400    

When logging auto-vacuum and auto-analyze activity, include the I/O  
timing if track_io_timing is enabled.  Also, for auto-analyze, add the  
read rate and the dirty rate, similar to how that information has  
historically been logged for auto-vacuum.  
  
Stephen Frost and Jakub Wartak  
  
Reviewed-By: Heikki Linnakangas, Tomas Vondra  
Discussion: https://www.postgresql.org/message-id/VI1PR0701MB69603A433348EDCF783C6ECBF6EF0%40VI1PR0701MB6960.eurprd07.prod.outlook.com  

commit   : 1ea396362be1615e926ea69d666c770081a0d3ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Mar 2021 11:16:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Mar 2021 11:16:41 -0400    

Since commit ba79cb5dc, values of bind parameters have been logged  
during errors in extended query mode.  However, we only did that after  
we'd collected and converted all the parameter values, thus failing to  
offer any useful localization of invalid-parameter problems.  Add a  
separate callback that's used during parameter collection, and have it  
print the parameter number, along with the input string if text input  
format is used.  
  
Justin Pryzby and Tom Lane  
  
Discussion: https://postgr.es/m/20210104170939.GH9712@telsasoft.com  
Discussion: https://postgr.es/m/CANfkH5k-6nNt-4cSv1vPB80nq2BZCzhFVR5O4VznYbsX0wZmow@mail.gmail.com  

commit   : 015061690c6526ff9f9f7af2940e1c1541654b68    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 Mar 2021 10:36:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 Mar 2021 10:36:28 -0300    

I forgot that Windows represents newlines as \r\n, so splitting a string  
at /\s/ creates additional empty strings.  Let's rewrite that as /\s+/  
to see if that avoids those.  (There's precedent for using that pattern  
on Windows in other scripts.)  
  
Previously: 91bdf499b37b, 8ed428dc977f, 650b96707672.  
  
Per buildfarm, via Tom Lane.  
Discussion: https://postgr.es/m/3144460.1615860259@sss.pgh.pa.us  

commit   : 15639d5e8f6f278219681fec8a5668a92fb7e874    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Mar 2021 09:55:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Mar 2021 09:55:43 +0900    

This tests some basic features for progress reporting of COPY, relying  
on an INSERT trigger that gets fired when doing COPY FROM with a file or  
stdin, checking for sizes, number of tuples processed, and number of  
tuples excluded by a WHERE clause.  
  
Author: Josef Šimánek, Matthias van de Meent  
Reviewed-by: Michael Paquier, Justin Pryzby, Bharath Rupireddy, Tomas  
Vondra  
Discussion: https://postgr.es/m/CAEze2WiOcgdH4aQA8NtZq-4dgvnJzp8PohdeKchPkhMY-jWZXA@mail.gmail.com  

commit   : 9aa491abbf07ca8385a429385be8d68517384fdf    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Mar 2021 18:33:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Mar 2021 18:33:03 -0300    

New metacommands \startpipeline and \endpipeline allow the user to run  
queries in libpq pipeline mode.  
  
Author: Daniel Vérité <daniel@manitou-mail.org>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/b4e34135-2bd9-4b8a-94ca-27d760da26d7@manitou-mail.org  

commit   : acb7e4eb6b1c614c68a62fb3a6a5bba1af0a2659    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Mar 2021 18:13:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Mar 2021 18:13:42 -0300