PostgreSQL 14.0 (upcoming) commit log

commit   : 6feebcb6b44631c3dc435e971bd80c2dd218a5ab    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:54:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:54:35 -0400    

Reported-by: troy@frericks.us  
  
Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org  
  
Backpatch-through: 13  

commit   : 74cf7d46a91d601e0f8d957a7edbaeeb7df83efc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:38:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:38:15 -0400    

Add pg_resetxlog -u option to set the oldest xid in pg_control.  
Previously -x set this value be -2 billion less than the -x value.  
However, this causes the server to immediately scan all relation's  
relfrozenxid so it can advance pg_control's oldest xid to be inside the  
autovacuum_freeze_max_age range, which is inefficient and might disrupt  
diagnostic recovery.  pg_upgrade will use this option to better create  
the new cluster to match the old cluster.  
  
Reported-by: Jason Harvey, Floris Van Nee  
  
Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com  
  
Author: Bertrand Drouvot  
  
Backpatch-through: 9.6  

commit   : 24ba1a87e4056ec34c8a685633a1a14fb89e5700    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Jul 2021 10:58:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Jul 2021 10:58:21 +0900    

A check in the ZLIB portion of the test to match the name of a  
non-compressed partial segment with a completed compressed segment was  
using m//, while a simple equality check is enough.  This makes the test  
a bit stricter without impacting its coverage.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20210726.174622.826565852378770261.horikyota.ntt@gmail.com  

commit   : f7a9a3d4b24a4ad0de7992f01a0dd2a02ccd30a4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Jul 2021 10:39:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Jul 2021 10:39:05 +0900    

strtoint(), via strtol(), would skip leading whitespaces but the same  
rule was not applied for trailing whitespaces, leading to an  
inconsistent behavior.  Some tests are changed to cover more this area.  
  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/YP5Pv0d13Ct+03ve@paquier.xyz  

commit   : 21b3aa9c8faf39ef45a5223681d8947e0a00e7da    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 26 Jul 2021 12:56:33 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 26 Jul 2021 12:56:33 -0400    

Coverity complained that my commit 80ba4bb38353 added a dubious coding  
for a consistency check that there isn't more than one row for a certain  
tgrelid/tgparentid combination.  But we don't check for that explicitly  
anywhere else, and if we were to do it, it should be a full  
shouldn't-happen elog not just an assert.  It doesn't seem that this is  
very important anyway, so remove it.  
  
Discussion: https://postgr.es/m/1337562.1627224583@sss.pgh.pa.us  

commit   : f68b609230689f9886a46e5d9ab8d6cdd947e0dc    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jul 2021 17:12:28 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jul 2021 17:12:28 +0200    

Commit ad600bba04 added psql command \dX listing extended statistics  
objects, but it failed to consider search_path when selecting the  
elements so some of the returned elements might be invisible.  
  
The visibility was already considered for tab completion (added by  
commit d99d58cdc8), so adding it to the query is fairly simple.  
  
Reported and fix by Justin Pryzby, regression tests by me. Backpatch  
to PostgreSQL 14, where \dX was introduced.  
  
Batchpatch-through: 14  
Author: Justin Pryzby  
Reviewed-by: Tatsuro Yamada  
Discussion: https://postgr.es/m/c027a541-5856-75a5-0868-341301e1624b%40nttcom.co.jp_1  

commit   : 085f931f52494e1f304e35571924efa6fcdc2b44    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 26 Jul 2021 14:13:47 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 26 Jul 2021 14:13:47 +0100    

Formerly, when specifying NUMERIC(precision, scale), the scale had to  
be in the range [0, precision], which was per SQL spec. This commit  
extends the range of allowed scales to [-1000, 1000], independent of  
the precision (whose valid range remains [1, 1000]).  
  
A negative scale implies rounding before the decimal point. For  
example, a column might be declared with a scale of -3 to round values  
to the nearest thousand. Note that the display scale remains  
non-negative, so in this case the display scale will be zero, and all  
digits before the decimal point will be displayed.  
  
A scale greater than the precision supports fractional values with  
zeros immediately after the decimal point.  
  
Take the opportunity to tidy up the code that packs, unpacks and  
validates the contents of a typmod integer, encapsulating it in a  
small set of new inline functions.  
  
Bump the catversion because the allowed contents of atttypmod have  
changed for numeric columns. This isn't a change that requires a  
re-initdb, but negative scale values in the typmod would confuse old  
backends.  
  
Dean Rasheed, with additional improvements by Tom Lane. Reviewed by  
Tom Lane.  
  
Discussion: https://postgr.es/m/CAEZATCWdNLgpKihmURF8nfofP0RFtAKJ7ktY6GcZOPnMfUoRqA@mail.gmail.com  

commit   : efe080220942fb8c2fdca66a3ab436159f7db86b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 16:26:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 16:26:47 +0900    

The documentation mentioned the use of log_checkpoints, that cannot be  
used in this context.  This commit replaces log_checkpoints with  
force_parallel_mode, a developer option useful to perform checks related  
to parallelism.  
  
Oversight in 854434c.  
  
Author: Haiying Tang  
Discussion: https://postgr.es/m/OS0PR01MB6113954B883ACEB2DDC973F2FBE59@OS0PR01MB6113.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : 0806d08d4626f0a71a4e83cb399ee965a8aac99b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 23:25:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 23:25:15 -0400    

Turns out the buildfarm hasn't been testing this, which will soon change.  
  
Julien Rouhaud, per report from me  
  
Discussion: https://postgr.es/m/42557.1627229005@sss.pgh.pa.us  

commit   : 2b58f894e56a1944e824e19c92337d6bf24d9c41    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 26 Jul 2021 14:55:31 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 26 Jul 2021 14:55:31 +1200    

Adjust the header comment in get_agg_clause_costs so that it matches what  
the function currently does.  No recursive searching has been done ever  
since 0a2bc5d61.  It also does not determine the aggtranstype like the  
comment claimed. That's all done in preprocess_aggref().  
preprocess_aggref also now determines the numOrderedAggs, so remove the  
mention that get_agg_clause_costs also calculates "counts".  
  
Normally, since this is just an adjustment of a comment it might not be  
worth back-patching, but since this code is new to PG14 and that version  
is still in beta, then it seems worth having the comments match.  
  
Discussion: https://postgr.es/m/CAApHDvrrGrTJFPELrjx0CnDtz9B7Jy2XYW3Z2BKifAWLSaJYwQ@mail.gmail.com  
Backpatch-though: 14  

commit   : 4ef64c425dbcda151c9f163aadff982343808e09    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 11:13:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 11:13:37 +0900    

These have been introduced by 7fbe0c8, and could happen for  
pg_basebackup and pg_receivewal.  
  
Per report from Coverity for the ones in walmethods.c, I have spotted  
the ones in receivelog.c after more review.  
  
Backpatch-through: 10  

commit   : 28d936031a86d94806c6604480ff3f3f169b371c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 14:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 14:02:27 -0400    

The point of introducing the hash_mem_multiplier GUC was to let users  
reproduce the old behavior of hash aggregation, i.e. that it could use  
more than work_mem at need.  However, the implementation failed to get  
the job done on Win64, where work_mem is clamped to 2GB to protect  
various places that calculate memory sizes using "long int".  As  
written, the same clamp was applied to hash_mem.  This resulted in  
severe performance regressions for queries requiring a bit more than  
2GB for hash aggregation, as they now spill to disk and there's no  
way to stop that.  
  
Getting rid of the work_mem restriction seems like a good idea, but  
it's a big job and could not conceivably be back-patched.  However,  
there's only a fairly small number of places that are concerned with  
the hash_mem value, and it turns out to be possible to remove the  
restriction there without too much code churn or any ABI breaks.  
So, let's do that for now to fix the regression, and leave the  
larger task for another day.  
  
This patch does introduce a bit more infrastructure that should help  
with the larger task, namely pg_bitutils.h support for working with  
size_t values.  
  
Per gripe from Laurent Hasson.  Back-patch to v13 where the  
behavior change came in.  
  
Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us  
Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com  

commit   : d9d8aa9bb9aa2a850f53facd2c91e454129af57b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 24 Jul 2021 20:14:03 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 24 Jul 2021 20:14:03 -0700    

5a1e1d83022 was a minimal bug fix for dc7420c2c92. To avoid future bugs of  
that kind, deduplicate the choice of a relation's horizon into a new helper,  
GlobalVisHorizonKindForRel().  
  
As the code in question was only introduced in dc7420c2c92 it seems worth  
backpatching this change as well, otherwise 14 will look different from all  
other branches.  
  
A different approach to this was suggested by Matthias van de Meent.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20210621122919.2qhu3pfugxxp3cji@alap3.anarazel.de  
Backpatch: 14, like 5a1e1d83022  

commit   : 6310809c4aa146b3996a35524955c6c6943d241a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    

We have an implementation restriction that PREPARE TRANSACTION can't  
handle cases where both session-lifespan and transaction-lifespan locks  
are held on the same lockable object.  (That's because we'd otherwise  
need to acquire a new PROCLOCK entry during post-prepare cleanup, which  
is an operation that might fail.  The situation can only arise with odd  
usages of advisory locks, so removing the restriction is probably not  
worth the amount of effort it would take.)  AtPrepare_Locks attempted  
to enforce this, but its logic was many bricks shy of a load, because  
it only detected cases where the session and transaction locks had the  
same lockmode.  Locks of different modes on the same object would lead  
to the rather unhelpful message "PANIC: we seem to have dropped a bit  
somewhere".  
  
To fix, build a transient hashtable with one entry per locktag,  
not one per locktag + mode, and use that to detect conflicts.  
  
Per bug #17122 from Alexander Pyhalov.  This bug is ancient,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org  

commit   : 3779ac62d709467fe6331c8f0285d42e7487a01c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    

We previously took a hard-line attitude that callers should never print  
a null string pointer, and doing so is worthy of an assertion failure  
or crash.  However, we've long since flushed out any easy-to-find bugs  
of that nature.  What remains is a lot of code that perhaps could fail  
that way in hard-to-reach corner cases.  For example, in something as  
simple as  
    ereport(ERROR,  
            (errcode(ERRCODE_UNDEFINED_OBJECT),  
             errmsg("constraint \"%s\" for table \"%s\" does not exist",  
                    conname, get_rel_name(relid))));  
one must wonder whether it's completely guaranteed that get_rel_name  
cannot return NULL in this context.  If such a situation did occur,  
the existing policy converts what might be a pretty minor bug into  
a server crash condition.  This is not good for robustness.  
  
Hence, let's follow the lead of glibc and print "(null)" instead  
of failing.  We should, of course, still consider it a bug if that  
behavior is reachable in ordinary use; but crashing seems less  
desirable than not crashing.  
  
This fix works across-the-board in v12 and up, where we always use  
src/port/snprintf.c.  Before that, on most platforms we're at the mercy  
of the local libc, but it appears that Solaris 10 is the only supported  
platform where we'd still get a crash.  Most other platforms such as  
*BSD, macOS, and Solaris 11 have adopted glibc's behavior at some  
point.  (AIX and HPUX just print "" not "(null)", but that's close  
enough.)  I've not checked what Windows' native printf would do, but  
it doesn't matter because we've long used snprintf.c on that platform.  
  
In v12 and up, also const-ify related code so that we're not casting  
away const on the constant string.  This is just neatnik-ism, since  
next to no compilers will warn about that.  
  
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org  

commit   : 76fa3db33654e543b5c796e28c6fc5b505a19c2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 12:16:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 12:16:39 -0400    

This testing was useful when it was written, nigh twenty years ago,  
but it seems fairly pointless for any platform built in the last  
dozen or more years.  (Compare also the comments at 8a2121185.)  
Also we now have reports that the test program itself fails under  
ThreadSanitizer.  Rather than invest effort in fixing it, let's  
just drop it, and assume that the few people who still care  
already know they need to use --disable-thread-safety.  
  
Back-patch into v14, for consistency with 8a2121185.  
  
Discussion: https://postgr.es/m/CADhDkKzPSiNvA3Hyq+wSR_icuPmazG0cFe=YnC3U-CFcYLc8Xw@mail.gmail.com  

commit   : 678f5448c2d86976a98b402ef14482a8ba3b159b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 11:34:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 11:34:33 -0400    

Recently-added references to ParseState weren't covered by #include  
references, creating unwanted ordering dependencies for users of  
these headers.  
  
Oversight in commit 2bfb50b3d.  Per headerscheck/cpluspluscheck.  

commit   : bc0cc68f8a1648029424e9300b2e4457acd474a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Jul 2021 19:05:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Jul 2021 19:05:14 +0900    

This fixes two compilation failures caused by 6f164e6.  Interesting to  
see that missing <limits.h> dies not fail in Linux or even Windows.  On  
MacOS, it fails, though.  
  
Per various buildfarm members.  

commit   : 6f164e6d17616a157ea5d9e34dbb1b211c080c41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Jul 2021 18:35:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Jul 2021 18:35:03 +0900    

Most of the integer options for command-line binaries now make use of a  
single routine able to do the job, fixing issues with the detection of  
sloppy values caused for example by the use of atoi(), that fails on  
strings beginning with numerical characters with junk trailing  
characters.  
  
This commit cuts down the number of strings requiring translation by 26  
per my count, switching the code to have two error types for invalid and  
out-of-range values instead.  
  
Much more could be done here, with float or even int64 options, but  
int32 was the most appealing case as it is possible to rely on strtol()  
to do the job reliably.  Note that there are some exceptions for now,  
like pg_ctl or pg_upgrade that use their own logging logic.  A couple of  
negative TAP tests required some adjustments for the new errors  
generated.  
  
pg_dump and pg_restore tracked the maximum number of parallel jobs  
within the option parsing.  The code is refactored a bit to track that  
in the code dedicated to parallelism instead.  
  
Author: Kyotaro Horiguchi, Michael Paquier  
Reviewed-by: David Rowley, Álvaro Herrera  
Discussion: https://postgr.es/m/CALj2ACXqdG9WhqVoJ9zYf-iZt7sgK7Szv5USs=he6NnWQ2ofTA@mail.gmail.com  

commit   : 6beb38cfc9ddd4cd3d2eb5402981ebdd69a618b4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Jul 2021 11:01:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Jul 2021 11:01:22 -0400    

Animals running in Czech locale failed.  I could try to find table names  
that don't have this problem, but it seems simpler to just use the C  
locale.  
  
Per buildfarm  

commit   : 80ba4bb383538a2ee846fece6a7b8da9518b6866    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jul 2021 18:33:47 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jul 2021 18:33:47 -0400    

Renaming triggers on partitioned tables had two problems: first,  
it did not recurse to renaming the triggers on the partitions; and  
second, it failed to prohibit renaming clone triggers.  Having triggers  
with different names in partitions is pointless, and furthermore pg_dump  
would not preserve names for partitions anyway.  
  
Not backpatched -- making the ALTER TRIGGER throw an error in stable  
versions might cause problems for existing scripts.  
  
Co-authored-by: Arne Roland <A.Roland@index.de>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>  
Discussion: https://postgr.es/m/d0fd7040c2fb4de1a111b9d9ccc456b8@index.de  

commit   : 73c5d2bfee2907b7f158485a531f00ba61b054f7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jul 2021 18:03:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jul 2021 18:03:26 -0400    

Dept. of second thoughts: the new verbiage added in commit aaec237b1a2f  
is targeted at the wrong audience.  Remove the bits about git and talk  
about how to get tarballs only.  People looking for the git repo can  
look in the appendix.  That'll need to be expanded, but this commit  
doesn't do that.  
  
In passing, fix a couple of typos that snuck in with the previous  
commit.  
  
Discussion: https://postgr.es/m/713760.1626891263@sss.pgh.pa.us  

commit   : a0db4294aeffe428cdcb381fc66ba725ec588e95    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 22 Jul 2021 17:34:19 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 22 Jul 2021 17:34:19 -0400    

Bauyrzhan Sakhariyev, via Github  
  
Backpatch to v14  

commit   : 86a1aae764b03c7fe06e290e409c8d1a72ff187d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Jul 2021 09:37:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Jul 2021 09:37:35 +0200    

Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/20210716.170209.175434392011070182.horikyota.ntt%40gmail.com  

commit   : 6a2c532c2230159b909382cfa58494ef9d6df703    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Jul 2021 12:57:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Jul 2021 12:57:43 +0900    

This reverts commit 91d395f, to avoid running those tests on Windows.  
The tests are globally stable across all buildfarm members, except  
fairywren (crash of pg_receivewal) and bowerdird (SIGBREAK preventing  
the buildfarm run to complete).  Those errors are rather strange, as  
other hosts with very similar characteristics are able to run those  
tests without breaking a sweat.  
  
For now, disable those tests on Windows to turn back the buildfarm to  
green.  
  
Per discussion with Andrew Dunstan.  
  
Discussion: https://postgr.es/m/9040d5ed-6462-66a4-07ac-2923785ae563@dunslane.net  

commit   : 0207d5fbebed7eb698a7e5f3adf30fafe95bc4b9    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jul 2021 14:11:17 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jul 2021 14:11:17 +1200    

Code inlined by LLVM can crash or fail with "Relocation type not  
implemented yet!" if it tries to access thread local variables.  Don't  
inline such code.  
  
Back-patch to 11, where LLVM arrived.  Bug #16696.  
  
Author: Dmitry Marakasov <amdmi3@amdmi3.ru>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org  

commit   : 91e9e89dccdfdf4216953d3d8f5515dcdef177fb    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 22 Jul 2021 14:03:19 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 22 Jul 2021 14:03:19 +1200    

Datum sorts can be significantly faster than tuple sorts, especially when  
the data type being sorted is a pass-by-value type.  Something in the  
region of 50-70% performance improvements appear to be possible.  
  
Just in case there's any confusion; the Datum sort is only used when the  
targetlist of the Sort node contains a single column, not when there's a  
single column in the sort key and multiple items in the target list.  
  
Author: Ronan Dunklau  
Reviewed-by: James Coleman, David Rowley, Ranier Vilela, Hou Zhijie  
Tested-by: John Naylor  
Discussion: https://postgr.es/m/3177670.itZtoPt7T5@aivenronan  

commit   : 7fa1e1ef741964eeb50f33d7c72622658bb7e5f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jul 2021 18:03:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jul 2021 18:03:33 -0400    

Now that we're not having to wedge this into the straitjacket of  
the old operator table format, we can add another example to  
clarify the point about left-to-right associativity.  
  
Per suggestion from mdione at grulic.org.ar.  
  
https://postgr.es/m/162661954599.693.13700316547731859171@wrigleys.postgresql.org  

commit   : aaec237b1a2f368ed2a8794c4f48b3656750eabc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Jul 2021 13:56:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Jul 2021 13:56:15 -0400    

Reported-by: Daniel Westermann  
Discussion: https://postgr.es/m/GV0P278MB04835AAEACF894617574EB6BD25A9@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM  

commit   : bb95feabb8572f5069ad37763707862af5a81942    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 10:17:07 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 10:17:07 -0400    

In postgresql.conf, memory and file size GUCs can be specified with "B"  
(bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us"  
(microseconds) as of caf626b2c. Update postgres.conf.sample to reflect  
that fact.  
  
Pavel Luzanov  
  
Backpatch to v12, which is the earliest version that allows both of  
these units. A separate commit will document the "B" case for v11.  
  
Discussion: https://www.postgresql.org/message-id/flat/f10d16fc-8fa0-1b3c-7371-cb3a35a13b7a%40postgrespro.ru  

commit   : 004874b72e8e60966f88de2d95667fe66c0466ca    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 09:11:32 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 09:11:32 -0400    

Oversight in ea1b99a66  
  
Yukun Wang  
  
Backpatch to v14 where this parameter was introduced  
  
Discussion: https://www.postgresql.org/message-id/flat/OS0PR01MB6003FCEFF0201EF21685FD33B4E39%40OS0PR01MB6003.jpnprd01.prod.outlook.com  

commit   : 983bdc4fac492a99bb8ab5a471ca7437139e5cf6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 11:03:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 11:03:25 +0200    

Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com  

commit   : 31360381f0a5ff5193c3631e6076442352906f59    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 10:24:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 10:24:06 +0200    

Some node function names didn't match their node type names exactly.  
Fix those for consistency.  
  
Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com  

commit   : 3d25b4ea6e2c93c60566c1185d4ee79a6285089a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 09:18:32 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 09:18:32 +0200    

Rename from value to node, for consistency with similar functions.  
  
Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com  

commit   : d9a38c52cef3cf80c4259277f11d42a86ecb1952    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 08:48:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 08:48:33 +0200    

Rename from tag to type, for consistency with all other node structs.  
  
Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com  

commit   : 81d5995b4b78017ef9e5c6f151361d1fb949924c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 07:40:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Jul 2021 07:40:05 +0200    

Follow-up to 2ed532ee8c474e9767e76e1f3251cc3a0224358c, a few error  
messages in the logical replication area currently only deal with  
tables, but if we're anticipating more relkinds such as sequences  
being handled, then these messages also fall into the category  
affected by the previous patch, so adjust them too.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/c9ba5c6a-4bd5-e12c-1b3c-edbcaedbf392@enterprisedb.com  

commit   : 90b6c339b2b37ee320ff6125ef8c8ad0073aa31b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 13:52:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 13:52:37 +0900    

Back-patch to v10 where pg_import_system_collations() was added.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/b7f484692a3e283710032e68b7f40617@oss.nttdata.com  

commit   : 7fcf2faf9c7dd473208fd6d5565f88d7f733782b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 11:19:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 11:19:00 +0900    

Commit 2c03216d83 changed XLOG_FPI_FOR_HINT records so that they always  
included full-page images even when full_page_writes was disabled. However,  
in this setting, they don't need to do that because hint bit updates don't  
need to be protected from torn writes.  
  
Therefore, this commit makes XLOG_FPI_FOR_HINT records honor full_page_writes  
setting. That is, XLOG_FPI_FOR_HINT records may include no full-page images  
if full_page_writes is disabled, and WAL replay of them does nothing.  
  
Reported-by: Zhang Wenjie  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/tencent_60F11973A111EED97A8596FFECC4A91ED405@qq.com  

commit   : d9809bf8694c17e05537c5dd96cde3e67c02d52a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    

If an error was raised during our initial attempt to check whether  
a successfully-compiled expression is "simple", subsequent calls of  
exec_stmt_execsql would suppose that stmt->mod_stmt was already computed  
when it had not been.  This could lead to assertion failures in debug  
builds; in production builds the effect would typically be to act as  
if INTO STRICT had been specified even when it had not been.  Of course  
that only matters if the subsequent attempt to execute the expression  
succeeds, so that the problem can only be reached by fixing a failure  
in some referenced, inline-able SQL function and then retrying the  
calling plpgsql function in the same session.  
  
(There might be even-more-obscure ways to change the expression's  
behavior without changing the plpgsql function, but that one seems  
like the only one people would be likely to hit in practice.)  
  
The most foolproof way to fix this would be to arrange for  
exec_prepare_plan to not set expr->plan until we've finished the  
subsidiary simple-expression check.  But it seems hard to do that  
without creating reference-count leak issues.  So settle for documenting  
the hazard in a comment and fixing exec_stmt_execsql to test separately  
for whether it's computed stmt->mod_stmt.  (That adds a test-and-branch  
per execution, but hopefully that's negligible in context.)  In v11 and  
up, also fix exec_stmt_call which had a variant of the same issue.  
  
Per bug #17113 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/17113-077605ce00e0e7ec@postgresql.org  

commit   : 91d395f47aa92849b2556b1a4d6bc1ff34121a30    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:17:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:17:08 +0900    

This is a revert of 6cea447, that disabled those tests temporarily on  
Windows due to failures with bowerbird where gzflush() would fail when  
executed on a freshly-opened compressed and partial segment.  This  
problem should be taken care of now thanks to 7fbe0c8, so let's see what  
the buildfarm has to say on Windows for those tests.  
  
Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz  

commit   : 7fbe0c8c4d4fe429ee1d6383706ea5ccb0f639d3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:12:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:12:39 +0900    

The logic handling the opening of new WAL segments was fuzzy when using  
--compress if a partial, non-compressed, segment with the same base name  
existed in the repository storing those files.  In this case, using  
--compress would cause the code to first check for the existence and the  
size of a non-compressed segment, followed by the opening of a new  
compressed, partial, segment.  The code was accidentally working  
correctly on most platforms as the buildfarm has proved, except  
bowerbird where gzflush() could fail in this code path.  It is wrong  
anyway to take the code path used pre-padding when creating a new  
partial, non-compressed, segment, so let's fix it.  
  
Note that this issue exists when users mix successive runs of  
pg_receivewal with or without compression, as discovered with the tests  
introduced by ffc9dda.  
  
While on it, this refactors the code so as code paths that need to know  
about the ".gz" suffix are down from four to one in walmethods.c, easing  
a bit the introduction of new compression methods.  This addresses a  
second issue where log messages generated for an unexpected failure  
would not show the compressed segment name involved, which was  
confusing, printing instead the name of the non-compressed equivalent.  
  
Reported-by: Georgios Kokolatos  
Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz  
Backpatch-through: 10  

commit   : 01c3adcdd85f1507ef49bdf5430c59925d08de6f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 20 Jul 2021 08:15:01 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 20 Jul 2021 08:15:01 +0530    

Prevent potential buffer overruns when using strcpy to gid buffer. This  
has been introduced by commit a8fd13cab0.  
  
Reported-by: Tom Lane as per coverity  
Author: Peter Smith  
Reviewed-by: Amit Kapila  
Discussion: https://www.postgresql.org/message-id/161029.1626639923%40sss.pgh.pa.us  

commit   : dd498998a374b3d2a7f5211504f1f1aa15348cf1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:20:25 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:20:25 -0700    

Oversight in commit 1e55e7d1, which added a wraparound failsafe  
mechanism to VACUUM.  
  
Backpatch: 14-, where VACUUM failsafe was introduced.  

commit   : 28766c054f8cc6a7bbcf99497954e7a259d3edb2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:06:48 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:06:48 -0700    

Commit 3499df0d added a comment that incorrectly suggested that  
--force-index-cleanup did not appear in the same major version as the  
similar --no-index-cleanup option.  In fact, both options are new to  
PostgreSQL 14.  
  
Backpatch: 14-, where both options were introduced.  

commit   : 0c08856856f54056ce8db116e9d254fda114c383    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 20 Jul 2021 10:49:08 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 20 Jul 2021 10:49:08 +1200    

No concrete problem reported, but in the past it's been known to cause  
problems on some compilers so let's avoid doing that.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/234364.1626704007%40sss.pgh.pa.us  

commit   : 0d2cb6b2bbc3327dd002f3ecd4d5bde5851b0cdc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Jul 2021 17:21:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Jul 2021 17:21:07 -0400    

Further fix the test code in ead9e51e8236, this time by waiting until  
the checkpoint has completed before moving on; this ensures that the  
WAL segment removal has already happened when we create the next slot.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20210719.111318.2042379313472032754.horikyota.ntt@gmail.com  

commit   : 344dedfd1c24f2e2c591f1eadf8414a1f4df910a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Jul 2021 09:46:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Jul 2021 09:46:50 +0200    

It doesn't match the normal coding style.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/22016aa9-ca59-15c7-01df-f292cb558c4d@enterprisedb.com  

commit   : 4d56115f721f3f2c6d3b6f017f40b5103ca71448    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Jul 2021 09:46:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Jul 2021 09:46:50 +0200    

This just makes the progress output easier to follow.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/22016aa9-ca59-15c7-01df-f292cb558c4d@enterprisedb.com  

commit   : 2b00db4fb0c7f02f000276bfadaab65a14059168    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Jul 2021 08:01:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Jul 2021 08:01:40 +0200    

Instead of castNode(…, lfoo(…))  
  
Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Discussion: https://www.postgresql.org/message-id/flat/87eecahraj.fsf@wibble.ilmari.org  

commit   : 29abde637bbb4b8fcdc96e049813890afa5ab671    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 10:36:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 10:36:15 +0530    

We don't allow to create replication slot_name as an empty string ('') via  
SQL API pg_create_logical_replication_slot() but it is allowed to be set  
via Alter Subscription command. This will lead to apply worker repeatedly  
keep trying to stream data via slot_name '' and the user is not allowed to  
create the slot with that name.  
  
Author: Japin Li  
Reviewed-By: Ranier Vilela, Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/MEYP282MB1669CBD98E721C77CA696499B61A9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : 04cad8f7bcd63fac567e49fd72e6df42b3b251a9    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 19 Jul 2021 16:29:17 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 19 Jul 2021 16:29:17 +1200    

A couple of open flags used in an assertion didn't exist in macOS 10.4.  
Per build farm animal prairiedog.  Also add O_EXCL while here (there are  
a few more standard flags but they're not relevant and likely to be  
missing).  

commit   : d1216635610a9855a8ec139e55cd852f67d5ee81    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Jul 2021 12:39:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Jul 2021 12:39:38 +0900    

This grammar has no effect as there are no dependencies on statistics,  
but it is supported by the parser.  This is more consistent with the  
other DROP commands.  
  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm1LA=yNmzcSfy+0oe6CEAgsxXRf_-UutE3ZncFi8QkFNQ@mail.gmail.com  
Backpatch-through: 10  

commit   : dcecdfafbd2dbdfaa0f82e7710abfa65242a1d1e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 08:32:37 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 08:32:37 +0530    

Add explanation as to why the subscription needs to be disabled to allow  
slot_name as none.  
  
Author: Japin Li and Amit Kapila  
Discussion: https://postgr.es/m/MEYP282MB1669CBD98E721C77CA696499B61A9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : 2dbe8905711ba09a2214b6e835f8f0c2c4981cb3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 19 Jul 2021 08:52:00 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 19 Jul 2021 08:52:00 +1200    

Macs don't understand O_DIRECT, but they can disable caching with a  
separate fcntl() call.  Extend the file opening functions in fd.c to  
handle this for us if the caller passes in PG_O_DIRECT.  
  
For now, this affects only WAL data and even then only if you set:  
  
  max_wal_senders=0  
  wal_level=minimal  
  
This is not expected to be very useful on its own, but later proposed  
patches will make greater use of direct I/O, and it'll be useful for  
testing if developers on Macs can see the effects.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKG%2BADiyyHe0cun2wfT%2BSVnFVqNYPxoO6J9zcZkVO7%2BNGig%40mail.gmail.com  

commit   : f157db862225a7bfe041ca3f7b73e913e2a8d8d6    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 18 Jul 2021 21:08:44 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 18 Jul 2021 21:08:44 +0300    

commit   : 9e3c217bd98da803709872a8612577d88a39329a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 18 Jul 2021 21:07:24 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 18 Jul 2021 21:07:24 +0300    

It has been spotted that multiranges lack of ability to decompose them into  
individual ranges.  Subscription and proper expanded object representation  
require substantial work, and it's too late for v14.  This commit  
provides the implementation of unnest(multirange), which is quite trivial.  
unnest(multirange) is defined as a polymorphic procedure.  
  
Catversion is bumped.  
  
Reported-by: Jonathan S. Katz  
Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org  
Author: Alexander Korotkov  
Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu, Tom Lane  
Reviewed-by: Alvaro Herrera  

commit   : ba620760c4c8ca90ff83ecf7e4d46f5ec4dabd7b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 18 Jul 2021 11:08:34 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 18 Jul 2021 11:08:34 +0100    

Check for conflicting or redundant options, as we do for most other  
commands. Specifying any option more than once is at best redundant,  
and quite likely indicates a bug in the user's code.  
  
While at it, improve the error for conflicting locale options by  
adding detail text (the same as for CREATE DATABASE).  
  
Bharath Rupireddy, reviewed by Vignesh C. Some additional hacking by  
me.  
  
Discussion: https://postgr.es/m/CALj2ACWtL6fTLdyF4R_YkPtf1YEDb6FUoD5DGAki3rpD+sWqiA@mail.gmail.com  

commit   : 8589299e03fff012e0bbb9716693750a0d68eef7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 17 Jul 2021 13:19:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 17 Jul 2021 13:19:17 -0400    

The new test code added in ead9e51e8236 is racy -- it hinges on  
shared-memory state, which changes before the WARNING message is logged.  
Put it the other way around.  
  
Backpatch to 13.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202107161809.zclasccpfcg3@alvherre.pgsql  

commit   : 665c5855e5820531f500dad50f29f377af537ecc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    

We had documentation of default_transaction_isolation et al,  
but for some reason not of transaction_isolation et al.  
AFAICS this is just an ancient oversight, so repair.  
  
Per bug #17077 from Yanliang Lei.  
  
Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org  

commit   : f0e21f2f61675f4e56ae53d32ea54d587a7c2257    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 17:29:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 17:29:22 -0400    

pg_dump failed to preserve the 'enabled' flag (which can be not only  
disabled, but also REPLICA or ALWAYS) for partitions which had it  
changed from their respective parents.  Attempt to handle that by  
including a definition for such triggers in the dump, but replace the  
standard CREATE TRIGGER line with an ALTER TRIGGER line.  
  
Backpatch to 11, where these triggers can exist.  In branches 11 and 12,  
pick up a few test lines from commit b9b408c48724 to verify that  
pg_upgrade is okay with these arrangements.  
  
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com  

commit   : df80fa2ee50478391445cef03e42c1b3d64fccca    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 13:01:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 13:01:43 -0400    

When triggers are cloned from partitioned tables to their partitions,  
the 'tgenabled' flag (origin/replica/always/disable) was not propagated.  
Make it so that the flag on the trigger on partition is initially set to  
the same value as on the partitioned table.  
  
Add a test case to verify the behavior.  
  
Backpatch to 11, where this appeared in commit 86f575948c77.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com  

commit   : ead9e51e82363a0e492d56aee83ed11b3759a615    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 12:07:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 12:07:30 -0400    

When some slots are invalidated due to the max_slot_wal_keep_size limit,  
the old segment horizon should move forward to stay within the limit.  
However, in commit c6550776394e we forgot to call KeepLogSeg again to  
recompute the horizon after invalidating replication slots.  In cases  
where other slots remained, the limits would be recomputed eventually  
for other reasons, but if all slots were invalidated, the limits would  
not move at all afterwards.  Repair.  
  
Backpatch to 13 where the feature was introduced.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reported-by: Marcin Krupowicz <mk@071.ovh>  
Discussion: https://postgr.es/m/17103-004130e8f27782c9@postgresql.org  

commit   : 46111fb7b57876a87eb0630ec12ad30950e38a39    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Jul 2021 10:35:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Jul 2021 10:35:38 +0200    

commit   : 6cea447e6a10cd7ef511470e809a894a013e6a18    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 16 Jul 2021 13:21:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 16 Jul 2021 13:21:18 +0900    

As reported by buildfarm member bowerbird, those tests are unstable on  
Windows.  The failure produced there points to a problem with gzflush(),  
that fails to sync a file freshly-opened, with a gzFile properly  
opened.  While testing this myself with MSVC, I bumped into a different  
error where a file could simply not be opened, so this makes me rather  
doubtful that testing this area on Windows is a good idea if this  
finishes with random concurrency failures.  This requires more  
investigation, and keeping this buildfarm member red is not a good thing  
in the long-term, so for now this just disables this set of tests on  
Windows.  
  
Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz  

commit   : 830ef61bd8d0ac4c89c21a895047c1b3a6b202f3    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 15 Jul 2021 23:22:58 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 15 Jul 2021 23:22:58 +0200    

Ensure to properly mark up function parameters in text with <parameter>,  
avoid using <acronym> for terms which aren't acronyms and properly place  
the ", and" in a value list. The acronym removal is a follow-up to commit  
fb72a7b8c3 which removed it for minmax-multi.  In passing, also fix an  
incorrectly cased word.  
  
Author: Ekaterina Kiryanova <e.kiryanova@postgrespro.ru>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/c050ecbc-80b2-b360-3c1d-9fe6a6a11bb5@postgrespro.ru  
Backpatch-through: v14  

commit   : a49d081235997c67e8aab7a523b17e8d1cb93184    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:41:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:41:47 -0400    

As of v14, pg_depend contains almost 7000 "pin" entries recording  
the OIDs of built-in objects.  This is a fair amount of bloat for  
every database, and it adds time to pg_depend lookups as well as  
initdb.  We can get rid of all of those entries in favor of an OID  
range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned".  
  
(template1 and the public schema are exceptions.  Those exceptions  
are now wired into IsPinnedObject() instead of initdb's code for  
filling pg_depend, but it's the same amount of cruft either way.)  
  
The contents of pg_shdepend are modified likewise.  
  
Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us  

commit   : e529b2dc37ac80ccebd76cdbb14966d3b40819c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:00:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:00:43 -0400    

Autoconf's AC_CHECK_DECLS() always defines HAVE_DECL_whatever  
as 1 or 0, but some of the entries in msvc/Solution.pm showed  
such symbols as "undef" instead of 0.  Fix that for consistency.  
There's no live bug in current usages AFAICS, but it's not hard  
to imagine one creeping in if more-complex #if tests get added.  
  
Back-patch to v13, which is as far back as Solution.pm contains  
this data.  The inconsistency still exists in the manually-filled  
pg_config_ext.h.win32 files of older branches; but as long as the  
problem is only latent, it doesn't seem worth the trouble to  
clean things up there.  
  
Discussion: https://postgr.es/m/3185430.1626133592@sss.pgh.pa.us  

commit   : 0da3c1bc3f7261d5157f5b86ade88e8b379f8686    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 21:25:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 21:25:03 +0900    

The OpenBSD implementation of gzip considers only files suffixed by "Z",  
"gz", "z", "tgz" or "taz" as valid targets, discarding anything else and  
making a command using --test exit with an error code of 512 if anything  
invalid is found.  The test introduced in ffc9dda tested a WAL segment  
suffixed as .gz.partial, enough to make the test fail.  
  
Testing only a full segment is fine enough in terms of coverage, so  
simplify the code by discarding the .gz.partial segment in this check.  
This should be enough to make the test pass with OpenBSD environments.  
  
Per report from curculio.  
  
Discussion: https://postgr.es/m/YPAdf9r5aJbDoHoq@paquier.xyz  

commit   : 768ea9bcf98120eef01a6deea9c5c6997b153ab1    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 15 Jul 2021 14:18:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 15 Jul 2021 14:18:19 +0300    

This commit fixes the description of a couple of multirange operators and  
oprjoin for another multirange operator.  The change of oprjoin is more  
cosmetic since both old and new functions return the same constant.  
  
These cosmetic changes don't worth catalog incompatibility between 14beta2  
and 14beta3.  So, catversion isn't bumped.  
  
Discussion: https://postgr.es/m/CAPpHfdv9OZEuZDqOQoUKpXhq%3Dmc-qa4gKCPmcgG5Vvesu7%3Ds1w%40mail.gmail.com  
Backpatch-throgh: 14  

commit   : 2bfb50b3df11399ed80347dd03bfaf8cd5acf962    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 15 Jul 2021 08:49:45 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 15 Jul 2021 08:49:45 +0100    

When reporting "conflicting or redundant options" errors, try to  
ensure that errposition() is used, to help the user identify the  
offending option.  
  
Formerly, errposition() was invoked in less than 60% of cases. This  
patch raises that to over 90%, but there remain a few places where the  
ParseState is not readily available. Using errdetail() might improve  
the error in such cases, but that is left as a task for the future.  
  
Additionally, since this error is thrown from over 100 places in the  
codebase, introduce a dedicated function to throw it, reducing code  
duplication.  
  
Extracted from a slightly larger patch by Vignesh C. Reviewed by  
Bharath Rupireddy, Alvaro Herrera, Dilip Kumar, Hou Zhijie, Peter  
Smith, Daniel Gustafsson, Julien Rouhaud and me.  
  
Discussion: https://postgr.es/m/CALDaNm33FFSS5tVyvmkoK2cCMuDVxcui=gFrjti9ROfynqSAGA@mail.gmail.com  

commit   : ffc9ddaea33f6dfd3dfa95828a0970fbb617bf8a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 15:53:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 15:53:20 +0900    

There is a non-trivial amount of code that handles ZLIB compression in  
pg_receivewal, from basics like the format name, the calculation of the  
start streaming position and of course the compression itself, but there  
was no automated coverage for it.  
  
This commit introduces a set of conditional tests (if the build supports  
ZLIB) to cover the creation of ZLIB-compressed WAL segments, the  
handling of the partial, compressed, WAL segments and the compression  
operation in itself.  Note that there is an extra phase checking the  
validity of the generated files by using directly a gzip command, passed  
down by the Makefile of pg_receivewal.  This part is skipped if the  
command cannot be found, something likely going to happen on Windows  
with MSVC except if one sets the variable GZIP_PROGRAM in the  
environment of the test.  
  
This set of tests will become handy for upcoming patches that add more  
options for the compression methods used by pg_receivewal, like LZ4, to  
make sure that no existing facilities are broken.  
  
Author: Georgios Kokolatos  
Reviewed-by: Gilles Darold, Michael Paquier  
Discussion: https://postgr.es/m/07BK3Mk5aEOsTwGaY77qBVyf9GjoEzn8TMgHLyPGfEFPIpTEmoQuP2P4c7teesjSg-LPeUafsp1flnPeQYINMSMB_UpggJDoduB5EDYBqaQ=@protonmail.com  

commit   : dc2db1eac365b97c9129393acfe11102859f9e23    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 15:00:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 15:00:45 +0900    

A code path asserted that the archiver was dead, but a check made that  
impossible to happen.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACW=CYE1ars+2XyPTEPq0wQvru4c0dPZ=Nrn3EqNBkksvQ@mail.gmail.com  
Backpatch-throgh: 14  

commit   : 5865e064abfbbe11ebfc09881be009c0f69b4dc2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Jul 2021 12:23:47 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Jul 2021 12:23:47 +1200    

Build farm animals running ancient HPUX and Solaris have a non-standard  
sigwait() from draft versions of POSIX, so they didn't like commit  
7c09d279.  To avoid the problem in general, only try to use sigwait() if  
it's declared by <signal.h> and matches the expected declaration.  To  
select the modern declaration on Solaris (even in non-threaded  
programs), move -D_POSIX_PTHREAD_SEMANTICS into the right place to  
affect all translation units.  
  
Also fix the error checking.  Modern sigwait() doesn't set errno.  
  
Thanks to Tom Lane for help with this.  
  
Discussion: https://postgr.es/m/3187588.1626136248%40sss.pgh.pa.us  

commit   : 9aa8268faa0ec2904f55e85be5ec7b365c98edd1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Jul 2021 23:54:56 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Jul 2021 23:54:56 +0200    

commit   : be850f1822e4b54d1d570eefa8a7242788011634    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jul 2021 14:15:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jul 2021 14:15:12 -0400    

This allows Param substitution to produce just the same result  
as writing a constant value literally would have done.  While  
it hardly matters so far as the current core code is concerned,  
extensions might take more interest in node location fields.  
  
Julien Rouhaud  
  
Discussion: https://postgr.es/m/20170311220932.GJ15188@nol.local  

commit   : c203dcddf997180000bc574a60313f3437e35af9    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 14 Jul 2021 09:52:04 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 14 Jul 2021 09:52:04 -0400    

Commit 0563a3a8b changed how partition constraints were generated such  
that this function no longer computes the mapping of parent attnos to  
child attnos.  
  
This is an external function that extensions could use, so this is  
potentially a breaking change. No external callers are known, however,  
and this will make it simpler to write such callers in the future.  
  
Author: Hou Zhijie  
Reviewed-by: David Rowley, Michael Paquier, Soumyadeep Chakraborty  
Discussion: https://www.postgresql.org/message-id/flat/OS0PR01MB5716A75A45BE46101A1B489894379@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : eec57115e4c866f26bdc8bcbe3e2e7be4c6d0450    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 14 Jul 2021 13:08:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 14 Jul 2021 13:08:28 +0300    

Previously, we would send each line as a separate CopyData message.  
That's pretty wasteful if the table is narrow, as each CopyData message  
has 5 bytes of overhead. For efficiency, buffer up and pack 8 kB of  
input data into each CopyData message.  
  
The server also sends each line as a separate CopyData message in COPY TO  
STDOUT, and that's similarly wasteful. But that's documented in the FE/BE  
protocol description, so changing that would be a wire protocol break.  
  
Reviewed-by: Aleksander Alekseev  
Discussion: https://www.postgresql.org/message-id/40b2cec0-d0fb-3191-2ae1-9a3fe16a7e48%40iki.fi  

commit   : b4deefc39b933b9808645667117f2d8208092794    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 14 Jul 2021 11:04:15 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 14 Jul 2021 11:04:15 +0200    

Reported-By: Peter Eisentraut  
Backpatch-through: 14  
Discussion: https://postgr.es/m/8f5e63b8-e8ed-0f80-d8c4-68222624c200@enterprisedb.com  

commit   : 55b2a2340758da8ff11357d719d169f264ac7112    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Jul 2021 09:15:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Jul 2021 09:15:14 +0200    

commit   : a8fd13cab0ba815e9925dc9676e6309f699b5f72    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 14 Jul 2021 07:33:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 14 Jul 2021 07:33:50 +0530    

To add support for streaming transactions at prepare time into the  
built-in logical replication, we need to do the following things:  
  
* Modify the output plugin (pgoutput) to implement the new two-phase API  
callbacks, by leveraging the extended replication protocol.  
  
* Modify the replication apply worker, to properly handle two-phase  
transactions by replaying them on prepare.  
  
* Add a new SUBSCRIPTION option "two_phase" to allow users to enable  
two-phase transactions. We enable the two_phase once the initial data sync  
is over.  
  
We however must explicitly disable replication of two-phase transactions  
during replication slot creation, even if the plugin supports it. We  
don't need to replicate the changes accumulated during this phase,  
and moreover, we don't have a replication connection open so we don't know  
where to send the data anyway.  
  
The streaming option is not allowed with this new two_phase option. This  
can be done as a separate patch.  
  
We don't allow to toggle two_phase option of a subscription because it can  
lead to an inconsistent replica. For the same reason, we don't allow to  
refresh the publication once the two_phase is enabled for a subscription  
unless copy_data option is false.  
  
Author: Peter Smith, Ajin Cherian and Amit Kapila based on previous work by Nikhil Sontakke and Stas Kelvich  
Reviewed-by: Amit Kapila, Sawada Masahiko, Vignesh C, Dilip Kumar, Takamichi Osumi, Greg Nancarrow  
Tested-By: Haiying Tang  
Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru  
Discussion: https://postgr.es/m/CAA4eK1+opiV4aFTmWWUF9h_32=HfPOW9vZASHarT0UA5oBrtGw@mail.gmail.com  

commit   : 6c9c2831668345122fd0f92280b30f3bbe2dd4e6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jul 2021 10:37:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jul 2021 10:37:26 +0900    

The internals of the frontend-side callbacks for SASL are visible in  
libpq-int.h, but the header was not getting installed.  This would cause  
compilation failures for applications playing with the internals of  
libpq.  
  
Issue introduced in 9fd8557.  
  
Author: Mikhail Kulagin  
Reviewed-by: Jacob Champion  
Discussion: https://postgr.es/m/05ce01d777cb$40f31d60$c2d95820$@postgrespro.ru  

commit   : 83f4fcc65503c5d4e5d5eefc8e7a70d3c9a6496f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 14 Jul 2021 12:43:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 14 Jul 2021 12:43:58 +1200    

"Result Cache" was never a great name for this node, but nobody managed  
to come up with another name that anyone liked enough.  That was until  
David Johnston mentioned "Node Memoization", which Tom Lane revised to  
just "Memoize".  People seem to like "Memoize", so let's do the rename.  
  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210708165145.GG1176@momjian.us  
Backpatch-through: 14, where Result Cache was introduced  

commit   : d68a00391214be2020e49be4b55f761d47a5c229    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jul 2021 15:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jul 2021 15:01:01 -0400    

The name introduced by commit 4656e3d66 was agreed to be unreasonably  
long.  To match this change, rename initdb's recently-added  
--clobber-cache option to --discard-caches.  
  
Discussion: https://postgr.es/m/1374320.1625430433@sss.pgh.pa.us  

commit   : e0271d5f1e871dd61efc26bda8a0b556c7935901    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:56:59 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:56:59 +1200    

There's no point in checking if an INT8 sequence has a seqmin and seqmax  
value is outside the range of the minimum and maximum values for an int64  
type.  These both use the same underlying types so an INT8 certainly  
cannot be outside the minimum and maximum values supported by int64.  
  
This code is fairly harmless and it seems likely that most compilers  
would optimize it out anyway, never-the-less, let's remove it replacing  
it with a small comment to mention why the check is not needed.  
  
Author: Greg Nancarrow, with the comment revised by David Rowley  
Discussion: https://postgr.es/m/CAJcOf-c9KBUZ8ow_6e%3DWSfbbEyTKfqV%3DVwoFuODQVYMySHtusw%40mail.gmail.com  

commit   : 5bd38d2f2846c7e387d04a16c4372da0de7b1221    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:27:05 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:27:05 +1200    

41469253e went to the trouble of removing a theoretical bug from  
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's  
make this a little more robust by also setting the tuple to NULL so that  
should we be called again we won't end up doing a pfree on the already  
pfree'd tuple. Per advice from Tom Lane.  
  
Discussion: https://postgr.es/m/3188192.1626136953@sss.pgh.pa.us  
Backpatch-through: 9.6, same as 41469253e  

commit   : 41469253e970b539a4ae75226dd4f226b7b2bc8c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 12:40:16 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 12:40:16 +1200    

This fixes a theoretical bug in tuplesort.c which, if a bounded sort was  
used in combination with a byval Datum sort (tuplesort_begin_datum), when  
switching the sort to a bounded heap in make_bounded_heap(), we'd call  
free_sort_tuple().  The problem was that when sorting Datums of a byval  
type, the tuple is NULL and free_sort_tuple() would free the memory for it  
regardless of that.  This would result in a crash.  
  
Here we fix that simply by adding a check to see if the tuple is NULL  
before trying to disassociate and free any memory belonging to it.  
  
The reason this bug is only theoretical is that nowhere in the current  
code base do we do tuplesort_set_bound() when performing a Datum sort.  
However, let's backpatch a fix for this as if any extension uses the code  
in this way then it's likely to cause problems.  
  
Author: Ronan Dunklau  
Discussion: https://postgr.es/m/CAApHDvpdoqNC5FjDb3KUTSMs5dg6f+XxH4Bg_dVcLi8UYAG3EQ@mail.gmail.com  
Backpatch-through: 9.6, oldest supported version  

commit   : 7c09d2797ecdf779e5dc3289497be85675f3d134    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 13 Jul 2021 11:13:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 13 Jul 2021 11:13:48 +1200    

Allow a pager to be used by the \watch command.  This works but isn't  
very useful with traditional pagers like "less", so use a different  
environment variable.  The popular open source tool "pspg" (also by  
Pavel) knows how to display the output if you set PSQL_WATCH_PAGER="pspg  
--stream".  
  
To make \watch react quickly when the user quits the pager or presses  
^C, and also to increase the accuracy of its timing and decrease the  
rate of useless context switches, change the main loop of the \watch  
command to use sigwait() rather than a sleeping/polling loop, on Unix.  
  
Supported on Unix only for now (like pspg).  
  
Author: Pavel Stehule <pavel.stehule@gmail.com>  
Author: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/CAFj8pRBfzUUPz-3gN5oAzto9SDuRSq-TQPfXU_P6h0L7hO%2BEhg%40mail.gmail.com  

commit   : f014b1b9bb8eda4e82c1805969dbae2b07b7d54d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jul 2021 19:17:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jul 2021 19:17:35 -0400    

Apple's mechanism for dealing with functions that are available  
in only some OS versions confuses AC_CHECK_FUNCS, and therefore  
AC_REPLACE_FUNCS.  We can use AC_CHECK_DECLS instead, so long as  
we enable -Werror=unguarded-availability-new.  This allows people  
compiling for macOS to control whether or not preadv/pwritev are  
used by setting MACOSX_DEPLOYMENT_TARGET, rather than supplying  
a back-rev SDK.  (Of course, the latter still works, too.)  
  
James Hilliard  
  
Discussion: https://postgr.es/m/20210122193230.25295-1-james.hilliard1@gmail.com  

commit   : f10f0ae420ee62400876ab34dca2c09c20dcd030    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jul 2021 17:01:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jul 2021 17:01:29 -0400    

The idea behind this patch is to design out bugs like the one fixed  
by commit 9d523119f.  Previously, once one did RelationOpenSmgr(rel),  
it was considered okay to access rel->rd_smgr directly for some  
not-very-clear interval.  But since that pointer will be cleared by  
relcache flushes, we had bugs arising from overreliance on a previous  
RelationOpenSmgr call still being effective.  
  
Now, very little code except that in rel.h and relcache.c should ever  
touch the rd_smgr field directly.  The normal coding rule is to use  
RelationGetSmgr(rel) and not expect the result to be valid for longer  
than one smgr function call.  There are a couple of places where using  
the function every single time seemed like overkill, but they are now  
annotated with large warning comments.  
  
Amul Sul, after an idea of mine.  
  
Discussion: https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com  

commit   : 5b60cf35f566697030a2895dfe27dde2e34dd370    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    

commit   : 4c64b51dc51f8ff7e3e51eebfe8d10469a577df1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    

This should have been removed in commit 7e30c186da, which split the loop  
into two. Only the first loop uses the 'from' variable; updating it in  
the second loop is bogus. It was never read after the first loop, so this  
was harmless and surely optimized away by the compiler, but let's be tidy.  
  
Backpatch to all supported versions.  
  
Author: Ranier Vilela  
Discussion: https://www.postgresql.org/message-id/CAEudQAoWq%2BAL3BnELHu7gms2GN07k-np6yLbukGaxJ1vY-zeiQ%40mail.gmail.com  

commit   : 2c9b46c090e76c62f24563b9be2c34e6b92e9329    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 14:46:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 14:46:08 +0900    

This reverts commit 54fb8c7, as per the issues reported by fairywren  
when it comes to MinGW because of the lack of microsoft_native_stat()  
there.  Using just stat() for MSVC is not sufficient to take care of the  
concurrency problems with files pending on deletion.  It may be possible  
to paint some __MINGW64__ in the code to switch to a different  
implementation of stat() in this build context, but I am not sure either  
if relying on the implementation of stat() in MinGW to take care of the  
problems we are trying to fix is enough or not.  So this needs more  
study.  
  
Discussion: https://postgr.es/m/YOvOlfRrIO0yGtgw@paquier.xyz  
Backpatch-through: 14  

commit   : 54fb8c7ddf152629021cab3ac3596354217b7d81    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 13:02:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 13:02:31 +0900    

The code introduced by bed9075 to enhance the stat() implementation on  
Windows for file sizes larger than 4GB fails to properly detect files  
pending for deletion with its method based on NtQueryInformationFile()  
or GetFileInformationByHandleEx(), as proved by Alexander Lakhin in a  
custom TAP test of his own.  
  
The method used in the implementation of open() to sleep and loop when  
when failing on ERROR_ACCESS_DENIED (EACCES) is showing much more  
stability, so switch to this method.  This could still lead to issues if  
the permission problem stays around for much longer than the timeout of  
1 second used, but that should (hopefully) never happen in  
performance-critical paths.  Still, there could be a point in increasing  
the timeouts for the sake of machines that handle heavy loads.  
  
Note that WIN32's open() now uses microsoft_native_stat() as it should  
be similar to stat() when working around issues with concurrent file  
deletions.  
  
I have spent some time testing this patch with pgbench in combination  
of the SQL functions from genfile.c, as well as running the TAP test  
provided on the thread with MSVC builds, and this looks much more  
stable than the previous method.  
  
Author: Alexander Lakhin  
Reviewed-by: Tom Lane, Michael Paquier,	Justin Pryzby  
Discussion: https://postgr.es/m/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com  
Backpatch-through: 14  

commit   : 127404fbe28455d6e8183fa58f3b7aefeba8f909    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 11:05:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 11:05:27 +0900    

ld_upper, ld_lower, pd_special and the page size have been using  
smallint as return type, which could cause those fields to return  
negative values in certain cases for builds configures with a page size  
of 32kB.  
  
Bump pageinspect to 1.10.  page_header() is able to handle the correct  
return type of those fields at runtime when using an older version of  
the extension, with some tests are added to cover that.  
  
Author: Quan Zongliang  
Reviewed-by: Michael Paquier, Bharath Rupireddy  
Discussion: https://postgr.es/m/8b8ec36e-61fe-14f9-005d-07bc85aa4eed@yeah.net  

commit   : 626731db26ae2617e41536678440c3817128a006    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    

Although we were careful to lock the object being added or dropped,  
we failed to get any sort of lock on the extension itself.  This  
allowed the ALTER to proceed in parallel with a DROP EXTENSION,  
which is problematic for a couple of reasons.  If both commands  
succeeded we'd be left with a dangling link in pg_depend, which  
would cause problems later.  Also, if the ALTER failed for some  
reason, it might try to print the extension's name, and that could  
result in a crash or (in older branches) a silly error message  
complaining about extension "(null)".  
  
Per bug #17098 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org  

commit   : 0e39a608ed5545cc6b9d538ac937c3c1ee8cdc36    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 11 Jul 2021 19:50:55 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 11 Jul 2021 19:50:55 +1200    

Commit 547f04e changed pgbench to use microsecond accounting, but  
introduced a couple of logging and aggregation bugs:  
  
1.  We print Unix epoch timestamps so that you can correlate them with  
other logs, but these were inadvertently changed to use a  
system-dependent reference epoch.  Compute Unix timestamps, and begin  
aggregation intervals on the boundaries of whole Unix epoch seconds, as  
before.  
  
2.  The user-supplied aggregation interval needed to be scaled.  
  
Back-patch to 14.  
  
Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Author: Yugo NAGATA <nagata@sraoss.co.jp>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reported-by: YoungHwan Joo <rulyox@gmail.com>  
Reported-by: Gregory Smith <gregsmithpgsql@gmail.com>  
Discussion: https://postgr.es/m/CAF7igB1r6wRfSCEAB-iZBKxkowWY6%2BdFF2jObSdd9%2BiVK%2BvHJg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAHLJuCW_8Vpcr0%3Dt6O_gozrg3wXXWXZXDioYJd3NhvKriqgpfQ%40mail.gmail.com  

commit   : dd0e37cc1598050ec38fa289908487d4f5c96dca    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 14:15:48 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 14:15:48 -0700    

If an error occurred in the wrong place, it was possible to leave an  
unintialized entry in the hash table, leading to a crash. Fixed.  
  
Also, be more careful about the order of operations so that an  
allocation error doesn't leak memory in CacheMemoryContext or  
unnecessarily advance NextRecordTypmod.  
  
Backpatch through version 11. Earlier versions (prior to 35ea75632a5)  
do not exhibit the problem, because an uninitialized hash entry  
contains a valid empty list.  
  
Author: Sait Talha Nisanci <Sait.Nisanci@microsoft.com>  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/HE1PR8303MB009069D476225B9A9E194B8891779@HE1PR8303MB0090.EURPRD83.prod.outlook.com  
Backpatch-through: 11  

commit   : 9f6be2e79f88c65cef7cfeb0580e8b2ba74974f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Jul 2021 13:19:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Jul 2021 13:19:30 -0400    

Sigh ... I was expecting AC_CHECK_LIB to do something it didn't,  
namely update LIBS.  This led to not finding ldap_initialize.  
Fix by moving the probe for ldap_initialize.  In some sense this  
is more correct anyway, since (at least for now) we care about  
whether ldap_initialize exists in libldap not libldap_r.  
  
Per buildfarm member elver and local testing.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 44bd0126c70b5b90e8e2d604833a6476abbbffe6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 Jul 2021 21:45:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 10 Jul 2021 21:45:28 +0900    

The following checks are added, to make the SASL infrastructure more  
aware of defects when implementing new mechanisms:  
- Detect that no output is generated by a mechanism if an exchange fails  
in the backend, failing if there is a message waiting to be sent.  
- Handle zero-length messages in the frontend.  The backend handles that  
already, and SCRAM would complain if sending empty messages as this is  
not authorized for this mechanism, but other mechanisms may want this  
capability (the SASL specification allows that).  
- Make sure that a mechanism generates a message in the middle of the  
exchange in the frontend.  
  
SCRAM, as implemented, respects all these requirements already, and the  
recent refactoring of SASL done in 9fd8557 helps in documenting that in  
a cleaner way.  
  
Analyzed-by: Jacob Champion  
Author: Michael Paquier  
Reviewed-by: Jacob Champion  
Discussion: https://postgr.es/m/3d2a6f5d50e741117d6baf83eb67ebf1a8a35a11.camel@vmware.com  

commit   : e7fc488ad67caaad33f6d5177081884495cb81cb    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 10 Jul 2021 12:42:59 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 10 Jul 2021 12:42:59 +0100    

This fixes an overflow error when using the numeric * operator if the  
result has more than 16383 digits after the decimal point by rounding  
the result. Overflow errors should only occur if the result has too  
many digits *before* the decimal point.  
  
Discussion: https://postgr.es/m/CAEZATCUmeFWCrq2dNzZpRj5+6LfN85jYiDoqm+ucSXhb9U2TbA@mail.gmail.com  

commit   : 53c38a086a8001d63401671755638bc95c7fa1c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 16:59:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 16:59:07 -0400    

I incorrectly diagnosed the reason why hoverfly is unhappy.  
Looking closer, it appears that it fails to link libldap  
unless libssl is also present; so the problem was my  
idea of clearing LIBS before making the check.  Revert  
to essentially the original coding, except that instead  
of failing when libldap_r isn't there, use libldap.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : ab09679429009bfed4bd894a6187afde0b7bdfcd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Jul 2021 15:57:59 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Jul 2021 15:57:59 -0400    

When sending queries in pipeline mode, we were careless about leaving  
the connection in the right state so that PQgetResult would behave  
correctly; trying to read further results after sending a query after  
having read a result with an error would sometimes hang.  Fix by  
ensuring internal libpq state is changed properly.  All the state  
changes were being done by the callers of pqAppendCmdQueueEntry(); it  
would have become too repetitious to have this logic in each of them, so  
instead put it all in that function and relieve callers of the  
responsibility.  
  
Add a test to verify this case.  Without the code fix, this new test  
hangs sometimes.  
  
Also, document that PQisBusy() would return false when no queries are  
pending result.  This is not intuitively obvious, and NULL would be  
obtained by calling PQgetResult() at that point, which is confusing.  
Wording by Boris Kolpackov.  
  
In passing, fix bogus use of "false" to mean "0", per Ranier Vilela.  
  
Backpatch to 14.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Boris Kolpackov <boris@codesynthesis.com>  
Discussion: https://postgr.es/m/boris.20210624103805@codesynthesis.com  

commit   : 8e7811e952b4e0993330f7ac1fb1448a1ca69b9a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 08:48:19 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 08:48:19 -0700    

The requirement that IDENTIFY_SYSTEM be run before START_REPLICATION  
was both undocumented and unnecessary. Remove the error and ensure  
that ThisTimeLineID is initialized in START_REPLICATION.  
  
Elect not to backport because this requirement was expected behavior  
(even if inconsistently enforced), and is not likely to cause any  
major problem.  
  
Author: Jeff Davis  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/de4bbf05b7cd94227841c433ea6ff71d2130c713.camel%40j-davis.com  

commit   : 31e8cfac5845fa57e1805f4ff81e00ab78dff025    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    

In commit d0a02bdb8, I'd supposed that uniformly probing for  
ldap_bind would make the intent clearer.  However, that seems  
not to work on AIX, for obscure reasons (maybe it's a macro  
there?).  Revert to the former behavior of probing  
ldap_simple_bind for thread-safe cases and ldap_bind otherwise.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : d23ac62afa646b7073a7f0db0a137308459a263b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 13:38:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 13:38:24 -0400    

Commit 7266d0997 added code to pull up simple constant function  
results, converting the RTE_FUNCTION RTE to a dummy RTE_RESULT  
RTE since it no longer need be scanned.  But I forgot to clear  
the LATERAL flag if the RTE has it set.  If the function reduced  
to a constant, it surely contains no lateral references so this  
simplification is logically OK.  It's needed because various other  
places will Assert that RESULT RTEs aren't LATERAL.  
  
Per bug #17097 from Yaoguang Chen.  Back-patch to v13 where the  
faulty code came in.  
  
Discussion: https://postgr.es/m/17097-3372ef9f798fc94f@postgresql.org  

commit   : d0a02bdb8c2576b5aa607f127320e444080bd579    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    

The separate libldap_r is gone and libldap itself is now always  
thread-safe.  Unfortunately there seems no easy way to tell by  
inspection whether libldap is thread-safe, so we have to take  
it on faith that libldap is thread-safe if there's no libldap_r.  
That should be okay, as it appears that libldap_r was a standard  
part of the installation going back at least 20 years.  
  
Report and patch by Adrian Ho.  Back-patch to all supported  
branches, since people might try to build any of them with  
a newer OpenLDAP.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : a9da1934e971b38ab360ce80a352fbfc4d2d986b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    

Since the executor can't cope with a utility statement appearing  
as a node of a plan tree, we can't support cases where a rewrite  
rule inserts a NOTIFY into an INSERT/UPDATE/DELETE command appearing  
in a WITH clause of a larger query.  (One can imagine ways around  
that, but it'd be a new feature not a bug fix, and so far there's  
been no demand for it.)  RewriteQuery checked for this, but it  
missed the case where the DML command rewrites to *only* a NOTIFY.  
That'd lead to crashes later on in planning.  Add the missed check,  
and improve the level of testing of this area.  
  
Per bug #17094 from Yaoguang Chen.  It's been busted since WITH  
was introduced, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17094-bf15dff55eaf2e28@postgresql.org  

commit   : ca2e4472ba7b6e5e8cd8955eacffb90e4d88d085    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 18:56:00 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 18:56:00 +1200    

There was talk about adding units all the way up to yottabytes but it  
seems quite far-fetched that anyone would need those.  Since such large  
units are not exactly commonplace, it seems unlikely that having  
pg_size_pretty outputting unit any larger than petabytes would actually be  
helpful to anyone.  
  
Since petabytes are on the horizon, let's just add those only.  Maybe one  
day we'll get to add additional units, but it will likely be a while  
before we'll need to think beyond petabytes in regards to the size of a  
database.  
  
Author: David Christensen  
Discussion: https://postgr.es/m/CAOxo6XKmHc_WZip-x5QwaOqFEiCq_SVD0B7sbTZQk+qqcn2qaw@mail.gmail.com  

commit   : 0f80b47d24b470babd61f2d9927d1956075f771d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Jul 2021 15:27:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Jul 2021 15:27:36 +0900    

These should have been part of 4035cd5, that introduced LZ4 support for  
wal_compression.  

commit   : 2f783380641db4cc598acd108186a446e4919290    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    

Commit 6753333f stopped using semaphores as the sleep/wake mechanism for  
heavyweight locks, but some obsolete references to that scheme remained  
in comments.  As with similar commit 25b93a29, back-patch all the way.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA%2BhUKGLafjB1uzXcy%3D%3D2L3cy7rjHkqOVn7qRYGBjk%3D%3DtMJE7Yg%40mail.gmail.com  

commit   : 56ff8b29919f75a078969766393b9e20871a75c8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 16:29:02 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 16:29:02 +1200    

We've grown 2 versions of pg_size_pretty over the years, one for BIGINT  
and one for NUMERIC.  Both should output the same, but keeping them in  
sync is harder than needed due to neither function sharing a source of  
truth about which units to use and how to transition to the next largest  
unit.  
  
Here we add a static array which defines the units that we recognize and  
have both pg_size_pretty and pg_size_pretty_numeric use it.  This will  
make adding any units in the future a very simple task.  
  
The table contains all information required to allow us to also modify  
pg_size_bytes to use the lookup table, so adjust that too.  
  
There are no behavioral changes here.  
  
Author: David Rowley  
Reviewed-by: Dean Rasheed, Tom Lane, David Christensen  
Discussion: https://postgr.es/m/CAApHDvru1F7qsEVL-iOHeezJ+5WVxXnyD_Jo9nht+Eh85ekK-Q@mail.gmail.com  

commit   : 55fe609387685de1c754332e260b2d0e17d257dc    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 14:04:30 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 14:04:30 +1200    

Due to how pg_size_pretty(bigint) was implemented, it's possible that when  
given a negative number of bytes that the returning value would not match  
the equivalent positive return value when given the equivalent positive  
number of bytes.  This was due to two separate issues.  
  
1. The function used bit shifting to convert the number of bytes into  
larger units.  The rounding performed by bit shifting is not the same as  
dividing.  For example -3 >> 1 = -2, but -3 / 2 = -1.  These two  
operations are only equivalent with positive numbers.  
  
2. The half_rounded() macro rounded towards positive infinity.  This meant  
that negative numbers rounded towards zero and positive numbers rounded  
away from zero.  
  
Here we fix #1 by dividing the values instead of bit shifting.  We fix #2  
by adjusting the half_rounded macro always to round away from zero.  
  
Additionally, adjust the pg_size_pretty(numeric) function to be more  
explicit that it's using division rather than bit shifting.  A casual  
observer might have believed bit shifting was used due to a static  
function being named numeric_shift_right.  However, that function was  
calculating the divisor from the number of bits and performed division.  
Here we make that more clear.  This change is just cosmetic and does not  
affect the return value of the numeric version of the function.  
  
Here we also add a set of regression tests both versions of  
pg_size_pretty() which test the values directly before and after the  
function switches to the next unit.  
  
This bug was introduced in 8a1fab36a. Prior to that negative values were  
always displayed in bytes.  
  
Author: Dean Rasheed, David Rowley  
Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com  
Backpatch-through: 9.6, where the bug was introduced.  

commit   : 387925893edf2a3a30a8ddf2c6474d8a7eb056a5    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 8 Jul 2021 12:45:09 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 8 Jul 2021 12:45:09 +0200    

Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/50250765-5B87-4AD7-9770-7FCED42A6175@yesql.se  

commit   : 2ed532ee8c474e9767e76e1f3251cc3a0224358c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Jul 2021 09:38:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Jul 2021 09:38:52 +0200    

Most error messages about a relkind that was not supported or  
appropriate for the command was of the pattern  
  
    "relation \"%s\" is not a table, foreign table, or materialized view"  
  
This style can become verbose and tedious to maintain.  Moreover, it's  
not very helpful: If I'm trying to create a comment on a TOAST table,  
which is not supported, then the information that I could have created  
a comment on a materialized view is pointless.  
  
Instead, write the primary error message shorter and saying more  
directly that what was attempted is not possible.  Then, in the detail  
message, explain that the operation is not supported for the relkind  
the object was.  To simplify that, add a new function  
errdetail_relkind_not_supported() that does this.  
  
In passing, make use of RELKIND_HAS_STORAGE() where appropriate,  
instead of listing out the relkinds individually.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/flat/dc35a398-37d0-75ce-07ea-1dd71d98f8ec@2ndquadrant.com  

commit   : b9734c13f168ef0d487aa122e486ca9b6dd6aa59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Jul 2021 15:21:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Jul 2021 15:21:25 -0400    

In 86dc90056, I'd written find_modifytable_subplan with the assumption  
that if the immediate child of a ModifyTable is a Result, it must be  
a projecting Result with a subplan.  However, if the UPDATE or DELETE  
has a provably-constant-false WHERE clause, that's not so: we'll  
generate a dummy subplan with a childless Result.  Add the missing  
null-check so we don't crash on such cases.  
  
Per report from Alexander Pyhalov.  
  
Discussion: https://postgr.es/m/b9a6f53549456b2f3e2fd150dcd79d72@postgrespro.ru  

commit   : 9d2a7757347cb1adb48599fce4dcde0f1fc9e9ae    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 21:54:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 21:54:47 +0900    

This commit fixes wrong wording like "a fewer kinds"  
in the description about track_planning option.  
  
Back-patch to v13 where pg_stat_statements.track_planning was added.  
  
Author: Justin Pryzby  
Reviewed-by: Julien Rouhaud, Fujii Masao  
Discussion: https://postgr.es/m/20210418233615.GB7256@telsasoft.com  

commit   : 29f45e299e7ffa1df0db44b8452228625479487f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 7 Jul 2021 16:29:17 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 7 Jul 2021 16:29:17 +1200    

Similar to 50e17ad28, which allowed hash tables to be used for IN clauses  
with a set of constants, here we add the same feature for NOT IN clauses.  
  
NOT IN evaluates the same as: WHERE a <> v1 AND a <> v2 AND a <> v3.  
Obviously, if we're using a hash table we must be exactly equivalent to  
that and return the same result taking into account that either side of  
the condition could contain a NULL.  This requires a little bit of  
special handling to make work with the hash table version.  
  
When processing NOT IN, the ScalarArrayOpExpr's operator will be the <>  
operator.  To be able to build and lookup a hash table we must use the  
<>'s negator operator.  The planner checks if that exists and is hashable  
and sets the relevant fields in ScalarArrayOpExpr to instruct the executor  
to use hashing.  
  
Author: David Rowley, James Coleman  
Reviewed-by: James Coleman, Zhihong Yu  
Discussion: https://postgr.es/m/CAApHDvoF1mum_FRk6D621edcB6KSHBi2+GAgWmioj5AhOu2vwQ@mail.gmail.com  

commit   : d854720df6df68cfe1432342e33c9e3020572a51    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 11:13:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 11:13:40 +0900    

Previously the values such as '100$%$#$#', '9,223,372,' were accepted and  
treated as valid integers for postgres_fdw options batch_size and fetch_size.  
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options  
for which an error is thrown. This was because endptr was not used  
while converting strings to integers using strtol.  
  
This commit changes the logic so that it uses parse_int function  
instead of strtol as it serves the purpose by returning false in case  
if it is unable to convert the string to integer. Note that  
this function also rounds off the values such as '100.456' to 100 and  
'100.567' or '100.678' to 101.  
  
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.  
  
Since parse_int and parse_real are being used for reloptions and GUCs,  
it is more appropriate to use in postgres_fdw rather than using strtol  
and strtod directly.  
  
Back-patch to v14.  
  
Author: Bharath Rupireddy  
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com  

commit   : 9fd85570d179f10f93344d722005f7086b3c31ca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Jul 2021 10:55:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Jul 2021 10:55:15 +0900    

The code of SCRAM and SASL have been tightly linked together since SCRAM  
exists in the core code, making hard to apprehend the addition of new  
SASL mechanisms, but these are by design different facilities, with  
SCRAM being an option for SASL.  This refactors the code related to both  
so as the backend and the frontend use a set of callbacks for SASL  
mechanisms, documenting while on it what is expected by anybody adding a  
new SASL mechanism.  
  
The separation between both layers is neat, using two sets of callbacks  
for the frontend and the backend to mark the frontier between both  
facilities.  The shape of the callbacks is now directly inspired from  
the routines used by SCRAM, so the code change is straight-forward, and  
the SASL code is moved into its own set of files.  These will likely  
change depending on how and if new SASL mechanisms get added in the  
future.  
  
Author: Jacob Champion  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/3d2a6f5d50e741117d6baf83eb67ebf1a8a35a11.camel@vmware.com  

commit   : 955b3e0f9269639fb916cee3dea37aee50b82df0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 18:10:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 18:10:11 -0400    

Previously, all CustomScan providers had to support projections,  
but there may be cases where this is inconvenient.  Add a flag  
bit to say if it's supported.  
  
Important item for the release notes: this is non-backwards-compatible  
since the default is now to assume that CustomScan providers can't  
project, instead of assuming that they can.  It's fail-soft, but could  
result in visible performance penalties due to adding unnecessary  
Result nodes.  
  
Sven Klemm, reviewed by Aleksander Alekseev; some cosmetic fiddling  
by me.  
  
Discussion: https://postgr.es/m/CAMCrgp1kyakOz6c8aKhNDJXjhQ1dEjEnp+6KNT3KxPrjNtsrDg@mail.gmail.com  

commit   : 5798ca529935698ab976780565fb2b4d8d34d810    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 6 Jul 2021 17:48:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 6 Jul 2021 17:48:41 -0400    

The original coding was not quoting the complete failing command, and it  
wasn't printing the reason for the failure either.  Do both.  
  
This is cosmetic only, so no backpatch.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/202106301524.eq5pblzstapj@alvherre.pgsql  

commit   : 64919aaab45076445051245c9bcd48dd84abebe7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 14:23:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 14:23:09 -0400    

Joel Jacobson reported that deep nesting of trivial (flattenable)  
views results in O(N^3) growth of planning time for N-deep nesting.  
It turns out that a large chunk of this cost comes from copying around  
the "subquery" sub-tree of each view's RTE_SUBQUERY RTE.  But once we  
have successfully flattened the subquery, we don't need that anymore,  
because the planner isn't going to do anything else interesting with  
that RTE.  We already zap the subquery pointer during setrefs.c (cf.  
add_rte_to_flat_rtable), but it's useless baggage earlier than that  
too.  Clearing the pointer as soon as pull_up_simple_subquery is done  
with the RTE reduces the cost from O(N^3) to O(N^2); which is still  
not great, but it's quite a lot better.  Further improvements will  
require rethinking of the RTE data structure, which is being considered  
in another thread.  
  
Patch by me; thanks to Dean Rasheed for review.  
  
Discussion: https://postgr.es/m/797aff54-b49b-4914-9ff9-aa42564a4d7d@www.fastmail.com  

commit   : c7b7311f6177b90fe5033b8ed2c10dfcbb863eb6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 12:36:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 12:36:12 -0400    

As in 50371df26, this is a bad idea since the callback can't really  
know what error is being thrown and thus whether or not it is safe  
to attempt catalog accesses.  Rather than pushing said accesses into  
the mainline code where they'd usually be a waste of cycles, we can  
look at the query's rangetable instead.  
  
This change does mean that we'll be printing query aliases (if any  
were used) rather than the table or column's true name.  But that  
doesn't seem like a bad thing: it's certainly a more useful definition  
in self-join cases, for instance.  In any case, it seems unlikely that  
any applications would be depending on this detail, so it seems safe  
to change.  
  
Patch by me.  Original complaint by Andres Freund; Bharath Rupireddy  
noted the connection to conversion_error_callback.  
  
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de  

commit   : ab2e19987ff66f83dfb99b5c541d9e05e8b0ede3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    

Our code has supported fractional-minute UTC offsets for ages, but  
there was no mention of the possibility in the main docs, and only  
a very indirect reference in Appendix B.  Improve that.  
  
Discussion: https://postgr.es/m/162543102827.697.5755498651217979813@wrigleys.postgresql.org  

commit   : 8aafb02616753f5c6c90bbc567636b73c0cbb9d4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Jul 2021 07:46:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Jul 2021 07:46:50 +0530    

Instead of using multiple parameters in parse_subscription_options  
function signature, use the struct SubOpts that encapsulate all the  
subscription options and their values. It will be useful for future work  
where we need to add other options in the subscription. Also, use bitmaps  
to pass the supported and retrieve the specified options much like the way  
it is done in the commit a3dc926009.  
  
Author: Bharath Rupireddy  
Reviewed-By: Peter Smith, Amit Kapila, Alvaro Herrera  
Discussion: https://postgr.es/m/CALj2ACXtoQczfNsDQWobypVvHbX2DtgEHn8DawS0eGFwuo72kw@mail.gmail.com  

commit   : 9ee91cc583802c6507fbc31c348a79e63a10f956    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jul 2021 12:38:50 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jul 2021 12:38:50 +1200    

Author: James Coleman  
Discussion: https://postgr.es/m/CAAaqYe8f8ENA0i1PdBtUNWDd2sxHSMgscNYbjhaXMuAdfBrZcg@mail.gmail.com  

commit   : 53d86957e980efa06f15232b8cff430d4cc6dd64    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jul 2021 12:24:43 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jul 2021 12:24:43 +1200    

In each of the create_*_bound() functions for LIST, RANGE and HASH  
partitioning, there were a large number of palloc calls which could be  
reduced down to a much smaller number.  
  
In each of these functions, an array was built so that we could qsort it  
before making the PartitionBoundInfo. For LIST and HASH partitioning, an  
array of pointers was allocated then each element was allocated within  
that array.  Since the number of items of each dimension is known  
beforehand, we can just allocate a single chunk of memory for this.  
  
Similarly, with all partition strategies, we're able to reduce the number  
of allocations to build the ->datums field.  This is an array of Datum  
pointers, but there's no need for the Datums that each element points to  
to be singly allocated.  One big chunk will do.  For RANGE partitioning,  
the PartitionBoundInfo->kind field can get the same treatment.  
  
We can apply the same optimizations to partition_bounds_copy().  Doing  
this might have a small effect on cache performance when searching for the  
correct partition during partition pruning or DML on a partitioned table.  
However, that's likely to be small and this is mostly about reducing  
palloc overhead.  
  
Author: Nitin Jadhav, Justin Pryzby, David Rowley  
Reviewed-by: Justin Pryzby, Zhihong Yu  
Discussion: https://postgr.es/m/flat/CAMm1aWYFTqEio3bURzZh47jveiHRwgQTiSDvBORczNEz2duZ1Q@mail.gmail.com  

commit   : 2aca19f2989aa938ece7306678f5494a984ece3f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Jul 2021 08:10:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Jul 2021 08:10:59 +0900    

This concerns pg_stop_backup() and BASE_BACKUP, when waiting for the  
WAL segments required for a backup to be archived.  This simplifies a  
bit the handling of the wait event used in this code path.  
  
Author: Bharath Rupireddy  
Reviewed-by: Michael Paquier, Stephen Frost  
Discussion: https://postgr.es/m/CALj2ACU4AdPCq6NLfcA-ZGwX7pPCK5FgEj-CAU0xCKzkASSy_A@mail.gmail.com  

commit   : 9753324b7d9eba0aaf7e12942f52c240bfc7da7c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    

Commit 03ffc4d6d added logic to bypass all caching behavior in  
LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled.  It doesn't  
look like I stopped to think much about what that would cost, but  
recent investigation shows that the cost is enormous: it roughly  
doubles the time needed for cache-clobber test runs.  
  
There does seem to be value in this behavior when trying to test  
the opclass-cache loading logic itself, but for other purposes the  
cost is excessive.  Hence, let's back off to doing this only when  
debug_invalidate_system_caches_always is at least 3; or in older  
branches, when CLOBBER_CACHE_RECURSIVELY is defined.  
  
While here, clean up some other minor issues in LookupOpclassInfo.  
Re-order the code so we aren't left with broken cache entries (leading  
to later core dumps) in the unlikely case that we suffer OOM while  
trying to allocate space for a new entry.  (That seems to be my  
oversight in 03ffc4d6d.)  Also, in >= v13, stop allocating one array  
entry too many.  That's evidently left over from sloppy reversion in  
851b14b0c.  
  
Back-patch to all supported branches, mainly to reduce the runtime  
of cache-clobbering buildfarm animals.  
  
Discussion: https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us  

commit   : c04c767059b8460b99f6aa4aae5450ab3ee257a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 14:34:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 14:34:47 -0400    

In 741d7f104, I tried to make the reports from canceled steps come out  
after the pg_cancel_backend() steps, since that was the most common  
ordering before.  However, that doesn't ensure that a canceled step  
doesn't report even later, as shown in a recent failure on buildfarm  
member idiacanthus.  Rather than complicating things even more with  
additional annotations, let's just force the cancel's effect to be  
reported first.  It's not *that* unnatural-looking.  
  
Back-patch to v14 where these test cases appeared.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2021-07-02%2001%3A40%3A04  

commit   : f025f2390e13d7da69da595086fb982bbaf7f329    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 5 Jul 2021 10:16:42 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 5 Jul 2021 10:16:42 +0100    

Formerly various numeric aggregate functions supported parallel  
aggregation by having each worker convert partial aggregate values to  
Numeric and use numeric_send() as part of serializing their state.  
That's problematic, since the range of Numeric is smaller than that of  
NumericVar, so it's possible for it to overflow (on either side of the  
decimal point) in cases that would succeed in non-parallel mode.  
  
Fix by serializing NumericVars instead, to avoid the overflow risk and  
ensure that parallel and non-parallel modes work the same.  
  
A side benefit is that this improves the efficiency of the  
serialization/deserialization code, which can make a noticeable  
difference to performance with large numbers of parallel workers.  
  
No back-patch due to risk from changing the binary format of the  
aggregate serialization states, as well as lack of prior field  
complaints and low probability of such overflows in practice.  
  
Patch by me. Thanks to David Rowley for review and performance  
testing, and Ranier Vilela for an additional suggestion.  
  
Discussion: https://postgr.es/m/CAEZATCUmeFWCrq2dNzZpRj5+6LfN85jYiDoqm+ucSXhb9U2TbA@mail.gmail.com  

commit   : 903d9aa7801e3198ca24e90be805362ad11b6ec3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Jul 2021 08:26:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Jul 2021 08:26:00 +0200    

commit   : e360aa0530b6d1f9e43f2aca760203de0421ef5e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 5 Jul 2021 09:36:11 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 5 Jul 2021 09:36:11 +0530    

A new chapter for Hash Indexes, designed to help users understand how  
they work and when to use them.  
  
Backpatch-through 10 where we have made hash indexes durable.  
  
Author: Simon Riggs  
Reviewed-By: Justin Pryzby, Amit Kapila  
Discussion: https://postgr.es/m/CANbhV-HRjNPYgHo--P1ewBrFJ-GpZPb9_25P7=Wgu7s7hy_sLQ@mail.gmail.com  

commit   : 0f06359fb3622b289485306727300dd31f96fd9d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Jul 2021 20:59:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Jul 2021 20:59:04 +0900    

Author: Greg Sabino Mullane  
Discussion: https://postgr.es/m/CAKAnmmJYH2FBn_+Vwd2FD5SaKn8hjhAXOCHpZc6n4wXaUaW_SA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : ec34040af104a1d25233eccd5715863ace6cbb10    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 22:28:38 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 22:28:38 +1200    

Document that setting maintenance_work_mem to values over 1GB has no  
effect on VACUUM.  
  
Reported-by: Martín Marqués  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A%40mail.gmail.com  
Backpatch-through: 9.6, oldest supported release  

commit   : 63b1af94375cc2be06a5d6a932db24cd8e9f45e9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 18:47:31 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 18:47:31 +1200    

Here we alter the code that calls build_pertrans_for_aggref() so that the  
function no longer needs to special-case whether it's dealing with an  
aggtransfn or an aggcombinefn.  This allows us to reuse the  
build_aggregate_transfn_expr() function and just get rid of the  
build_aggregate_combinefn_expr() completely.  
  
All of the special case code that was in build_pertrans_for_aggref() has  
been moved up to the calling functions.  
  
This saves about a dozen lines of code in nodeAgg.c and a few dozen more  
in parse_agg.c  
  
Also, rename a few variables in nodeAgg.c to try to make it more clear  
that we're working with either a aggtransfn or an aggcombinefn.  Some of  
the old names would have you believe that we were always working with an  
aggtransfn.  
  
Discussion: https://postgr.es/m/CAApHDvptMQ9FmF0D67zC_w88yVnoNVR2+kkOQGUrCmdxWxLULQ@mail.gmail.com  

commit   : 792259591c0fc19c42247fc7668b1064d1e850d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jul 2021 11:21:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jul 2021 11:21:40 -0400    

Disable this check altogether in --enable-coverage builds,  
because newer versions of gcc insert exit() as well as abort()  
calls for that.  Also disable it on AIX and Solaris, because  
those platforms tend to provide facilities such as libldap  
as static libraries, which then get included in libpq's shlib.  
We can't expect such libraries to honor our coding rules.  
(That platform list might need additional tweaking, but I think  
this is enough to keep the buildfarm happy.)  
  
Per reports from Jacob Champion and Noah Misch.  
  
Discussion: https://postgr.es/m/3128896.1624742969@sss.pgh.pa.us  

commit   : d390bb62a6332f8a913c2c2021d56d6dba5a1dce    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 20:42:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 20:42:46 -0400    

Reported-by: tom@crystae.net  
  
Discussion: https://postgr.es/m/162345756191.14472.9754568432103008703@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : c552e171d16e461c7af60cfe1a891c87be9cbbbf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 18:00:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 18:00:30 -0400    

Reported-by: eric.mutta@gmail.com  
  
Discussion: https://postgr.es/m/162395467510.686.11947486273299446208@wrigleys.postgresql.org  
  
Backpatch-through: 14  

commit   : 50371df266d4c8f4faaf448cbd789d9697443952    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Jul 2021 16:04:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Jul 2021 16:04:54 -0400    

The existing code tried to do syscache lookups in an already-failed  
transaction, which is problematic to say the least.  After some  
consideration of alternatives, the best fix seems to be to just drop  
type names from the error message altogether.  The table and column  
names seem like sufficient localization.  If the user is unsure what  
types are involved, she can check the local and remote table  
definitions.  
  
Having done that, we can also discard the LogicalRepTypMap hash  
table, which had no other use.  Arguably, LOGICAL_REP_MSG_TYPE  
replication messages are now obsolete as well; but we should  
probably keep them in case some other use emerges.  (The complexity  
of removing something from the replication protocol would likely  
outweigh any savings anyhow.)  
  
Masahiko Sawada and Bharath Rupireddy, per complaint from Andres  
Freund.  Back-patch to v10 where this code originated.  
  
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de  

commit   : 6bd3ec62d9d7921fad2125bbeb5f2eafbbb261e5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 2 Jul 2021 11:59:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 2 Jul 2021 11:59:55 +0200    

Reported-by: Ranier Vilela <ranier.vf@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAEudQAp%3DZwKjrP4L%2BCzqV7SmWiaQidPPRqj4tqdjDG4KBx5yrg%40mail.gmail.com  

commit   : 70685385d70f8da73ab189a72f46311091ff09be    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Jul 2021 12:58:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Jul 2021 12:58:34 +0900    

This has the advantage to make a process more responsive when the  
postmaster dies, even if the wait time was rather limited as there was  
only a 50ms timeout here.  Another advantage of this change is for  
monitoring, as we gain a new wait event for the end-of-vacuum  
truncation.  
  
Author: Bharath Rupireddy  
Reviewed-by: Aleksander Alekseev, Thomas Munro, Michael Paquier  
Discussion: https://postgr.es/m/CALj2ACU4AdPCq6NLfcA-ZGwX7pPCK5FgEj-CAU0xCKzkASSy_A@mail.gmail.com  

commit   : a2595e039c4745d82f361ea15d692cac114575cc    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 2 Jul 2021 13:07:16 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 2 Jul 2021 13:07:16 +1200    

Remove redundant local variable assignments left behind by commit  
2fc7af5e966.  
  
Author: Quan Zongliang <quanzongliang@yeah.net>  
Reviewed-by: Jacob Champion <pchampion@vmware.com>  
Discussion: https://postgr.es/m/de141d14-4fd6-3148-99bf-856b71aa948a%40yeah.net  

commit   : b44669b2ca6a510b2c81cbe74c704d59226d729c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Jul 2021 09:35:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Jul 2021 09:35:12 +0900    

This commit removes a dependency to the central logging facilities in  
the JSON parsing routines of src/common/, which existed to log errors  
when seeing error codes that do not match any existing values in  
JsonParseErrorType, which is not something that should never happen.  
  
The routine providing a detailed error message based on the error code  
is made backend-only, the existing code being unsafe to use in the  
frontend as the error message may finish by being palloc'd or point to a  
static string, so there is no way to know if the memory of the message  
should be pfree'd or not.  The only user of this routine in the frontend  
was pg_verifybackup, that is changed to use a more generic error message  
on parsing failure.  
  
Note that making this code more resilient to OOM failures if used in  
shared libraries would require much more work as a lot of code paths  
still rely on palloc() & friends, but we are not sure yet if we need to  
go down to that.  Still, removing the dependency to logging is a step  
toward more portability.  
  
This cleans up the handling of check_stack_depth() while on it, as it  
exists only in the backend.  
  
Per discussion with Jacob Champion and Tom Lane.  
  
Discussion: https://postgr.es/m/YNwL7kXwn3Cckbd6@paquier.xyz  

commit   : 1708f6b38aaf1b9375b5ca82792425410c98d441    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 22:23:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 22:23:37 +0200    

commit   : 7355c241ed002496d70882eccea6027726e2fb5a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 15:38:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 15:38:06 -0400    

commit   : c0fdc963704983ebd5908dc5acfb4d52303091a4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 21:27:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 21:27:39 +0200    

commit   : b8c4261e5e8dc5c20d033970ec584991638ca041    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 14:21:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 14:21:09 -0400    

These are the same as world and install-world respectively, but without  
building or installing the documentation. There are many reasons for  
wanting to be able to do this, including speed, lack of documentation  
building tools, and wanting to build other formats of the documentation.  
Plans for simplifying the buildfarm client code include using these  
targets.  
  
Backpatch to all live branches.  
  
Discussion: https://postgr.es/m/6a421136-d462-b043-a8eb-e75b2861f3df@dunslane.net  

commit   : b741f4c3ee67666aa333dbb25bd71906b3474def    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jul 2021 13:33:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jul 2021 13:33:05 -0400    

Commit 4656e3d66 replaced the "#define CLOBBER_CACHE_ALWAYS"  
testing mechanism with a GUC, which has been a great help for  
doing cache-clobber testing in more efficient ways; but there  
is a gap in the implementation.  The only way to do cache-clobber  
testing during an initdb run is to use the old method with #define,  
because one can't set the GUC from outside.  Improve this by  
adding a switch to initdb for the purpose.  
  
(Perhaps someday we should let initdb pass through arbitrary  
"-c NAME=VALUE" switches.  Quoting difficulties dissuaded me  
from attempting that right now, though.)  
  
Back-patch to v14 where 4656e3d66 came in.  
  
Discussion: https://postgr.es/m/1582507.1624227029@sss.pgh.pa.us  

commit   : d700518d744e53994fdded14b23ebc15b031b0dd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Jul 2021 12:56:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Jul 2021 12:56:30 -0400    

Commit 0e69f705cc1a introduced code to analyze partitioned table;  
however, that code fails to preserve pg_class.relhasindex correctly.  
Fix by observing whether any indexes exist rather than accidentally  
falling through to assuming none do.  
  
Backpatch to 14.  
  
Author: Alexander Pyhalov <a.pyhalov@postgrespro.ru>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>  
Discussion: https://postgr.es/m/CALNJ-vS1R3Qoe5t4tbzxrkpBtzRbPq1dDcW4RmA_a+oqweF30w@mail.gmail.com  

commit   : 2f7bae2f924d8213a76370f825dc15eb0aa79796    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jul 2021 10:45:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jul 2021 10:45:12 -0400    

Further fixes for commit dc227eb82.  Per suggestion from  
Peter Eisentraut, use a stamp-file to control when the check  
is run, avoiding repeated executions during "make all".  
Also, remove "-g" switch for nm: it's useless and some versions  
of nm consider it to conflict with "-u".  (Thanks to Noah Misch  
for running down that portability issue.)  
  
Discussion: https://postgr.es/m/3128896.1624742969@sss.pgh.pa.us  

commit   : a0fc813266467d666b8f09ccccaccb700326a296    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 08:29:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 08:29:10 -0400    

The prove_installcheck recipe in src/Makefile.global.in was emitting  
bogus paths for a couple of elements when used with PGXS. Here we create  
a separate recipe for the PGXS case that does it correctly. We also take  
the opportunity to make the make the file more readable by breaking up  
the prove_installcheck and prove_check recipes across several lines, and  
to remove the setting for REGRESS_SHLIB to src/test/recovery/Makefile,  
which is the only set of tests that actually need it.  
  
Backpatch to all live branches  
  
Discussion: https://postgr.es/m/f2401388-936b-f4ef-a07c-a0bcc49b3300@dunslane.net  

commit   : c8bf5098cbc4f32ca724d830d45d5ceb2ad7f96d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Jul 2021 15:32:57 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Jul 2021 15:32:57 +0300    

Before, if you specified multiple --rmgr options, only the last one took  
effect. It seems more sensible to select all the specified resource  
managers.  
  
Reviewed-By: Daniel Gustafsson, Julien Rouhaud  
Discussion: https://www.postgresql.org/message-id/98344bc2-e222-02ad-a75b-81ffc614c155%40iki.fi  

commit   : 71ba45a3602da0bdbb518e16e3990cfcf21e5f73    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 09:17:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 09:17:44 +0200    

There is a syntactic ambiguity in the SQL standard.  Since UNBOUNDED  
is a non-reserved word, it could be the name of a function parameter  
and be used as an expression.  There is a grammar hack to resolve such  
cases as the keyword.  Add some tests to record this behavior.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://www.postgresql.org/message-id/flat/b2a09a77-3c8f-7c68-c9b7-824054f87d98%40enterprisedb.com  

commit   : 3788c66788e9f8c6904c6fe903724c1f44812c4d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Jul 2021 15:29:06 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Jul 2021 15:29:06 +1200    

Several places were performing a tight loop to determine the first power  
of 2 number that's > or >= the required memory.  Instead of using a loop  
for that, we can use pg_nextpower2_32 or pg_nextpower2_64.  When we need a  
power of 2 number equal to or greater than a given amount, we just pass  
the amount to the nextpower2 function.  When we need a power of 2 greater  
than the amount, we just pass the amount + 1.  
  
Additionally, in tsearch there were a couple of locations that were  
performing a while loop when a simple "if" would have done.  In both of  
these locations only 1 item is being added, so the loop could only have  
ever iterated once.  Changing the loop into an if statement makes the code  
very slightly more optimal as the condition is checked once rather than  
twice.  
  
There are quite a few remaining locations that increase the size of the  
buffer in the following form:  
  
  while (reqsize >= buflen)  
  {  
     buflen *= 2;  
     buf = repalloc(buf, buflen);  
  }  
  
These are not touched in this commit.  repalloc will error out for sizes  
larger than MaxAllocSize.  Changing these to use pg_nextpower2_32 would  
remove the chance of that error being raised.  It's unclear from the code  
if the sizes could ever become that large, so err on the side of caution.  
  
Discussion: https://postgr.es/m/CAApHDvp=tns7RL4PH0ZR0M+M-YFLquK7218x=0B_zO+DbOma+w@mail.gmail.com  
Reviewed-by: Zhihong Yu  

commit   : e45b0dfa1f1028948decad3abd3b0f6e913a44b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Jun 2021 10:52:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Jun 2021 10:52:20 -0400    

Give up on trying to mechanically forbid abort() within libpq.  
Even though there are no such calls in the source code, we've now  
seen three different scenarios where build toolchains silently  
insert such calls: gcc does it for profiling, some platforms  
implement assert() using it, and icc does so for no visible reason.  
Checking for accidental use of exit() seems considerably more  
important than checking for abort(), so we'll settle for doing  
that for now.  
  
Also, filter out __cxa_atexit() to avoid a false match.  It seems  
that OpenBSD inserts a call to that despite the fact that libpq  
contains no C++ code.  
  
Discussion: https://postgr.es/m/3128896.1624742969@sss.pgh.pa.us  

commit   : 3465c8a8692fb628bc2710fbeedb9aeb534b0400    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 30 Jun 2021 20:57:07 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 30 Jun 2021 20:57:07 +0900    

Previously the descriptions of tup_returned and tup_fetched columns  
in pg_stat_database view were confusing. This commit improves them  
so that they represent the following formulas of those columns  
more accurately.  
  
* pg_stat_database.tup_returned  
    = sum(pg_stat_all_tables.seq_tup_read)  
    + sum(pg_stat_all_indexes.idx_tup_read)  
  
* pg_stat_database.tup_fetched  
    = sum(pg_stat_all_tables.idx_tup_fetch)  
  
In these formulas, note that the counters for some system catalogs  
like pg_database shared across all databases of a cluster are excluded  
from the calculations of sum.  
  
Author: Masahiro Ikeda  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/9eeeccdb-5dd7-90f9-2807-a4b5d2b76ca3@oss.nttdata.com  

commit   : 61d599ede7424d88bbd4006b968bae366b6b9f5d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 30 Jun 2021 19:33:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 30 Jun 2021 19:33:18 +0900    

Author: Shinya Kato  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/TYAPR01MB2896DEB25C3B0D57F6139768C40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com  

commit   : 735dc1a09469002fd659a4b1f5d582377b318977    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Jun 2021 08:29:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Jun 2021 08:29:03 +0200    

Instead of just writing warnings for invalid cross-catalog lookups,  
count the errors and error out at the end.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/ca8ee41d-241b-1bf3-71f0-aaf1add6d3c5%40enterprisedb.com  

commit   : ab5e48f153cfea2c571dc177ae96faf4ab072b8e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 11:29:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 11:29:53 +0530    

A few variables have been using 10 as a magic constant while  
PG_STAT_GET_REPLICATION_SLOT_COLS can be used instead.  
  
Author: Masahiko Sawada  
Reviewed-By: Amit Kapila  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/CAD21AoBvqODDfmD17DkEuPCvV2KbruukXQ2Vwrv5Xi-TsAsTJA@mail.gmail.com  

commit   : 52d26d560e272613c501e35b24fbf8d710de4b8a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 09:37:59 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 09:37:59 +0530    

Until now, we didn't allow to stream the changes in logical replication  
till we receive speculative confirm or the next DML change record after  
speculative inserts. The reason was that we never use to process  
speculative aborts but after commit 4daa140a2f it is possible to process  
them so we can allow streaming once we receive speculative abort after  
speculative insertion.  
  
We decided to backpatch to 14 where the feature for streaming in progress  
transactions have been introduced as this is a minor change and makes that  
functionality better.  
  
Author: Amit Kapila  
Reviewed-By: Dilip Kumar  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAA4eK1KdqmTCtrBR6oFfGELrLLbDLDedL6zACcsUOQuTJBj1vw@mail.gmail.com  

commit   : cda03cfed6b8bd5f64567bccbc9578fba035691e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 08:45:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 08:45:47 +0530    

Extend the replication command CREATE_REPLICATION_SLOT to support the  
TWO_PHASE option. This will allow decoding commands like PREPARE  
TRANSACTION, COMMIT PREPARED and ROLLBACK PREPARED for slots created with  
this option. The decoding of the transaction happens at prepare command.  
  
This patch also adds support of two-phase in pg_recvlogical via a new  
option --two-phase.  
  
This option will also be used by future patches that allow streaming of  
transactions at prepare time for built-in logical replication. With this,  
the out-of-core logical replication solutions can enable replication of  
two-phase transactions via replication protocol.  
  
Author: Ajin Cherian  
Reviewed-By: Jeff Davis, Vignesh C, Amit Kapila  
Discussion:  
https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru  
https://postgr.es/m/64b9f783c6e125f18f88fbc0c0234e34e71d8639.camel@j-davis.com  

commit   : 17707c059cf4bf610e3b1833df5ca17cf223fe5f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 11:48:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 11:48:53 +0900    

Reaching PITR on such a transaction would cause the generation of a LOG  
message mentioning a transaction committed, not aborted.  
  
Oversight in 4f1b890.  
  
Author: Simon Riggs  
Discussion: https://postgr.es/m/CANbhV-GJ6KijeCgdOrxqMCQ+C8QiK657EMhCy4csjrPcEUFv_Q@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 4c9f50d116461617848601e97dbc6f122b0a6f14    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 09:58:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 09:58:59 +0900    

This commit prevents pg_checksums to do a rewrite of a block if it has  
no need to, in the case where the computed checksum matches with what's  
already stored in the block read.  This is helpful to accelerate  
successive runs of the tool when the previous ones got interrupted, for  
example.  
  
The number of blocks and files written is tracked and reported by the  
tool once finished.  Note that the final flush of the data folder  
happens even if no blocks are written, as it could be possible that a  
previous interrupted run got stopped while doing a flush.  
  
Author: Greg Sabino Mullane  
Reviewed-by: Paquier Michael, Julien Rouhaud  
Discussion: https://postgr.es/m/CAKAnmmL+k6goxmVzQJB+0bAR0PN1sgo6GDUXJhyhUmVMze1QAw@mail.gmail.com  

commit   : 178ec460db0a0ced46ac5a01a28a704ca6251e53    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Jun 2021 23:18:09 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Jun 2021 23:18:09 +0300    

 * Fix enumeration of the multirange operators in calc_multirangesel() and  
   calc_multirangesel() switches.  
 * Add more regression tests for matching to empty ranges/multiranges.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/c5269c65-f967-77c5-ff7c-15e621c47f6a%40gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 14, where multiranges were introduced  

commit   : b71a9cb31e46b08aeac35a4355936165648b3c49    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 15:01:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 15:01:29 -0400    

The original coding required that PQpipelineSync had been called before  
the first call to PQgetResult, and failure to do that would result in an  
unexpected NULL result being returned.  Fix by setting the right state  
when a query is sent, rather than leaving it unchanged and having  
PQpipelineSync apply the necessary state change.  
  
A new test case to verify the behavior is added, which relies on the new  
PQsendFlushRequest() function added by commit a7192326c74d.  
  
Backpatch to 14, where pipeline mode was added.  
  
Reported-by: Boris Kolpackov <boris@codesynthesis.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/boris.20210616110321@codesynthesis.com  

commit   : a7192326c74da417d024a189da4d33c1bf1b40b6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 14:37:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 14:37:39 -0400    

This new libpq function allows the application to send an 'H' message,  
which instructs the server to flush its outgoing buffer.  
  
This hasn't been needed so far because the Sync message already requests  
a buffer; and I failed to realize that this was needed in pipeline mode  
because PQpipelineSync also causes the buffer to be flushed.  However,  
sometimes it is useful to request a flush without establishing a  
synchronization point.  
  
Backpatch to 14, where pipeline mode was introduced in libpq.  
  
Reported-by: Boris Kolpackov <boris@codesynthesis.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106252350.t76x73nt643j@alvherre.pgsql  

commit   : dd2364ced98553e0217bfe8f621cd4b0970db74a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 14:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 14:34:31 -0400    

Commit efbfb6424 added logic for reporting exactly which existing  
partition conflicts when complaining that a new hash partition's  
modulus isn't compatible with the existing ones.  However, it  
misunderstood the partitioning data structure, and would select  
the wrong partition in some cases, or crash outright due to fetching  
a bogus table OID in other cases.  
  
Per bug #17076 from Alexander Lakhin.  Fix by Amit Langote;  
some further work on the code comments by me.  
  
Discussion: https://postgr.es/m/17076-89a16ae835d329b9@postgresql.org  

commit   : dc227eb82ea8bf6919cd81a182a084589ddce7f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 11:46:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 11:46:17 -0400    

Directly exiting or aborting seems like poor form for a general-purpose  
library.  Now that libpq liberally uses bits out of src/common/,  
it's very easy to accidentally include code that would do something  
unwanted like calling exit(1) after OOM --- see for example 8ec00dc5c.  
Hence, add a simple cross-check that no such calls have made it into  
libpq.so.  
  
The cross-check depends on nm(1) being available and being able to  
work on a shared library, which probably isn't true everywhere.  
But we can just make the test silently do nothing if nm fails.  
As long as the check is effective on common platforms, that should  
be good enough.  (By the same logic, I've not worried about providing  
an equivalent test in MSVC builds.)  
  
Discussion: https://postgr.es/m/3128896.1624742969@sss.pgh.pa.us  

commit   : aaddf6ba09e25878e792f0d15f725370e19396df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 11:31:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 11:31:08 -0400    

Doing an abort() seems all right in development builds, but not in  
production builds of general-purpose libraries.  However, the functions  
that were doing this lack any way to report a failure back up to their  
callers.  It seems like we can just get away with ignoring failures in  
production builds, since (a) no such failures have been reported in the  
dozen years that the code's been like this, and (b) failure to enforce  
mutual exclusion during fe-auth.c operations would likely not cause any  
problems anyway in most cases.  (The OpenSSL callbacks that use this  
macro are obsolete, so even less likely to cause interesting problems.)  
  
Possibly a better answer would be to break compatibility of the  
pgthreadlock_t callback API, but in the absence of field problem  
reports, it doesn't really seem worth the trouble.  
  
Discussion: https://postgr.es/m/3131385.1624746109@sss.pgh.pa.us  

commit   : 48cb244fb9aca1620e35a14617ca5869b3ea065a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 29 Jun 2021 00:44:57 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 29 Jun 2021 00:44:57 -0700    

The behavior changed sometime after Perl 5.8.9, and "man perlre" says it  
"may lead to confusing results."  Per buildfarm member gaur.  This  
repairs commit a7a7be1f2fa6b9f0f48e69f12256d8f588af729b.  
  
Discussion: https://postgr.es/m/20210629053627.GA2061079@rfd.leadboat.com  

commit   : 6a6389a08b228aa6bd21ced7a9c5151bf6f7f0a2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Jun 2021 07:57:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Jun 2021 07:57:16 +0200    

Instead of defining symbols such as AmOidIndexId explicitly, include  
them as an argument of DECLARE_INDEX() and have genbki.pl generate the  
way as the table OID symbols from the CATALOG() declaration.  
  
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/ccef1e46-a404-25b1-9b4c-85f2c08e1f28%40enterprisedb.com  

commit   : 445e36ad4e14480a3c97d0f973a3532912424e85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Jun 2021 13:57:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Jun 2021 13:57:45 +0900    

Oversight in 4035cd5, spotted by Tom Lane.  
  
Discussion: https://postgr.es/m/365778.1624941613@sss.pgh.pa.us  

commit   : 47f514dd9a0022a04d321b627b2e991cb85396e2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Jun 2021 11:54:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Jun 2021 11:54:11 +0900    

This is reproducible with gcc using at least -O0.  The last checks  
validating the compression of a block could not be reached with this  
variable not set, but let's be clean.  
  
Oversight in 4035cd5, per buildfarm member lapwing.  

commit   : 4035cd5d4eee4dae797bfc77ab07f8dcd8781b41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Jun 2021 11:17:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Jun 2021 11:17:55 +0900    

The logic is implemented so as there can be a choice in the compression  
used when building a WAL record, and an extra per-record bit is used to  
track down if a block is compressed with PGLZ, LZ4 or nothing.  
  
wal_compression, the existing parameter, is changed to an enum with  
support for the following backward-compatible values:  
- "off", the default, to not use compression.  
- "pglz" or "on", to compress FPWs with PGLZ.  
- "lz4", the new mode, to compress FPWs with LZ4.  
  
Benchmarking has showed that LZ4 outclasses easily PGLZ.  ZSTD would be  
also an interesting choice, but going just with LZ4 for now makes the  
patch minimalistic as toast compression is already able to use LZ4, so  
there is no need to worry about any build-related needs for this  
implementation.  
  
Author: Andrey Borodin, Justin Pryzby  
Reviewed-by: Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/3037310D-ECB7-4BF1-AF20-01C10BB33A33@yandex-team.ru  

commit   : cc2c7d65fc27e877c9f407587b0b92d46cd6dd16    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    

The previous commit addressed the chief consequences of a race condition  
between InstallXLogFileSegment() and KeepFileRestoredFromArchive().  Fix  
three lesser consequences.  A spurious durable_rename_excl() LOG message  
remained possible.  KeepFileRestoredFromArchive() wasted the proceeds of  
WAL recycling and preallocation.  Finally, XLogFileInitInternal() could  
return a descriptor for a file that KeepFileRestoredFromArchive() had  
already unlinked.  That felt like a recipe for future bugs.  
  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  

commit   : 2b3e4672f7602a6bb46a0735a1b41b635508b290    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    

Before a restartpoint finishes PreallocXlogFiles(), a startup process  
KeepFileRestoredFromArchive() call can unlink the preallocated segment.  
If a CHECKPOINT sql command had elicited the restartpoint experiencing  
the race condition, that sql command failed.  Moreover, the restartpoint  
omitted its log_checkpoints message and some inessential resource  
reclamation.  Prevent the ERROR by skipping open() of the segment.  
Since these consequences are so minor, no back-patch.  
  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  

commit   : 421484f79c0b80209fa766eb00dbc2453a753273    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:56 -0700    

Only initdb used it.  initdb refuses to operate on a non-empty directory  
and generally does not cope with pre-existing files of other kinds.  
Hence, use the opportunity to simplify.  
  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  

commit   : 85656bc3050f0846f53de95768b0f9f9df410560    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    

Infrequently, the mismatch caused log_checkpoints messages and  
TRACE_POSTGRESQL_CHECKPOINT_DONE() to witness an "added" count too high  
by one.  Since that consequence is so minor, no back-patch.  
  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  

commit   : c53c6b98d38a4d238b2fe2ddcea63c33b0a61376    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    

Cold paths, initdb and end-of-recovery, used it.  Don't optimize them.  
  
Discussion: https://postgr.es/m/20210202151416.GB3304930@rfd.leadboat.com  

commit   : 7ac10f692054e2690aa6f80efdd98bd283c94b10    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    

As we do for other attributes of the public schema, omit the COMMENT  
command when its payload would match what initdb had installed.  For  
dumps that do carry this new COMMENT command, non-superusers restoring  
them are likely to get an error.  
  
Reviewed by Asif Rehman.  
  
Discussion: https://postgr.es/m/ab48a34c-60f6-e388-502a-3e5fe46a2dae@postgresfriends.org  

commit   : a7a7be1f2fa6b9f0f48e69f12256d8f588af729b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 28 Jun 2021 18:34:55 -0700    

As a side effect, this corrects dumps of public schema ACLs in databases  
where the DBA dropped and recreated that schema.  
  
Reviewed by Asif Rehman.  
  
Discussion: https://postgr.es/m/20201229134924.GA1431748@rfd.leadboat.com  

commit   : 14b2ffaf7ffdd199937e8bcba8b459da5491bcb6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 18:05:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 18:05:46 -0400    

Mention expectations for email notifications of appropriate lists  
when a branch is made or retired.  
  
(I've been doing that informally for years, but it's better to have  
it written down.)  

commit   : bc49ab3c277b6b478bdad80c1ae36f926a33b4a6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Jun 2021 13:08:46 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Jun 2021 13:08:46 -0700    

Update RELEASE_CHANGES to direct the reader towards completing the steps  
outlined in the pgindent README, both as a pre-beta task and as a task  
to be performed when starting a new development cycle.  
  
This makes it less likely that somebody will miss updating the  
.git-blame-ignore-revs file when running pgindent against the tree as a  
routine release change task.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAH2-Wz=2PjF4As8dWECArsXxLKganYmQ-s0UeGqHHbHhqDKqeA@mail.gmail.com  

commit   : 6f5d9bce57a7bb29ba61f0bf4fd465a26de9fc28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 14:17:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 14:17:41 -0400    

Causing a core dump on out-of-memory seems pretty unfriendly,  
and surely is far outside the expected behavior of a general-purpose  
library.  Just print an error message (as we did already) and return.  
These functions unfortunately don't have an error return convention,  
but code using them is probably just looking for a quick-n-dirty  
print method and wouldn't bother to check anyway.  
  
Although these functions are semi-deprecated, it still seems  
appropriate to back-patch this.  In passing, also back-patch  
b90e6cef1, just to reduce cosmetic differences between the  
branches.  
  
Discussion: https://postgr.es/m/3122443.1624735363@sss.pgh.pa.us  

commit   : 01697e92a460b10fde43707b29391c8deb69573e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 12:40:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 12:40:37 -0400    

Instead use the common/int.h functions to check for integer overflow  
in a more C-standard-compliant fashion.  This is motivated by recent  
failures on buildfarm member moonjelly, where it appears that  
development-tip gcc is optimizing without regard to the -fwrapv  
switch.  Presumably that's a gcc bug that will be fixed soon, but  
we might as well install cleaner coding here rather than wait.  
  
(This does not address the question of whether we'll ever be able  
to get rid of using -fwrapv.  Testing shows that this spot is the  
only place where doing so creates visible regression test failures,  
but unfortunately that proves very little.)  
  
Back-patch to v12.  The common/int.h functions exist in v11, but  
that branch doesn't use them in any client-side code.  I judge  
that this case isn't interesting enough in the real world to take  
even a small risk of issues from being the first such use.  
  
Tom Lane and Fabien Coelho  
  
Discussion: https://postgr.es/m/73927.1624815543@sss.pgh.pa.us  

commit   : ba135fa537ab5c2fca0d589c826ebb3ecf98b2f1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Jun 2021 09:22:24 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 28 Jun 2021 09:22:24 -0700    

Add entry for recent commit e1c1c30f.  

commit   : 596b5af1d3675b58d4018acd64217e2f627da3e4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Jun 2021 11:31:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Jun 2021 11:31:16 -0400    

Let the hacking begin ...  

commit   : e1c1c30f635390b6a3ae4993e8cac213a33e6e3f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Jun 2021 11:05:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Jun 2021 11:05:54 -0400    

Along the way make a slight adjustment to  
src/include/utils/queryjumble.h to avoid an unused typedef.  

commit   : c31833779d5a4775d7220be4b9143bec66c9a9fd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 28 Jun 2021 08:36:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 28 Jun 2021 08:36:44 +0200    

commit   : ee3fdb8f3465b3a5937a7fe647b7b6584a600647    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 10:56:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 10:56:53 +0530    

We were using RelationGetIndexList() to update the relation's replica  
identity index but instead, we can directly use RelationGetReplicaIndex()  
which uses the same functionality. This is a minor code readability  
improvement.  
  
Author: Japin Li  
Reviewed-By: Takamichi Osumi, Amit Kapila  
Discussion: https://postgr.es/m/4C99A862-69C8-431F-960A-81B1151F1B89@enterprisedb.com  

commit   : b786304c2904a4e444fe740bbc2e0b69efacc19d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 09:29:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 09:29:38 +0530    

When we cannot immediately acquire XactSLRULock in exclusive mode at  
commit time, we add ourselves to a list of processes that need their XIDs  
status update. We do this if the clog page where we need to update the  
current transaction status is the same as the group leader's clog page,  
otherwise, we allow the caller to clear it by itself. Now, when we can't  
add ourselves to any group, we were not clearing the current proc if it  
has already become a member of some group which was leading to an  
assertion failure when the same proc was assigned to another backend after  
the current backend exits.  
  
Reported-by: Alexander Lakhin  
Bug: 17072  
Author: Amit Kapila  
Tested-By: Alexander Lakhin  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/17072-2f8764857ef2c92a@postgresql.org  

commit   : 34a8b64b4e5f0cd818e5cc7f98846de57938ea57    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 28 Jun 2021 15:17:43 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 28 Jun 2021 15:17:43 +1200    

The setting has no effect except during startup.  It's still nice to be  
able to change it dynamically, which is expected to be pretty useful to  
an admin following crash recovery when restarting the cluster is not so  
appealing.  
  
Per discussions following commits 2941138e6 and 61752afb2.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20210529192321.GM2082%40telsasoft.com  

commit   : 79718c1c6c007c27e9c1b8e92bd96d17067606fa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 12:11:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 12:11:18 +0900    

copy_data is not a supported option with this sub-command of ALTER  
SUBSCRIPTION, which would not make a variable related to it initialized  
after parsing the option set in DefElems.  A refresh could then refer to  
it.  
  
Author: Ranier Vilela  
Reviewed-by: Peter Smith  
Discussion: https://postgr.es/m/CAEudQAp5P8nr=ze2Gv=BMj=DJFZnrvendZCZcC-fos3QiDe2sg@mail.gmail.com  

commit   : 09a69f6e23369847cf11cd03c999a0342d47bbcc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 11:17:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 11:17:05 +0900    

83158f7 has improved index_set_state_flags() so as it is possible to use  
transactional updates when updating pg_index state flags, but there was  
not really a test case which stressed directly the possibility it fixed.  
This commit adds such a test, using a predicate that looks valid in  
appearance but calls a stable function.  
  
Author: Andrey Lepikhov  
Discussion: https://postgr.es/m/9b905019-5297-7372-0ad2-e1a4bb66a719@postgrespro.ru  
Backpatch-through: 9.6  

commit   : 642c0697c96b9c6ba5d194653a329f7820565f01    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    

specscanner.l leaked a kilobyte of memory per token of the spec file.  
Apparently somebody thought that the introductory code block would be  
executed once; but it's once per yylex() call.  
  
A couple of functions in isolationtester.c leaked small amounts of  
memory due to not bothering to free one-time allocations.  Might  
as well improve these so that valgrind gives this program a clean  
bill of health.  Also get rid of an ugly static variable.  
  
Coverity complained about one of the one-time leaks, which led me  
to try valgrind'ing isolationtester, which led to discovery of the  
larger leak.  

commit   : c302a6139072fed9410204fa9e751d95930e05ff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 27 Jun 2021 09:41:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 27 Jun 2021 09:41:16 +0200    

Take some untranslatable things out of the message and replace by  
format placeholders, to reduce translatable strings and reduce  
translation mistakes.  

commit   : dcffc9ba8a1e0ab1b0a57e9b9d38e3dc9960f83f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 15:45:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 15:45:16 -0400    

commit   : 8ec00dc5cd70e0e579e9fbf8661bc46f5ccd8078    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 14:20:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 14:20:17 -0400    

Commit c0cb87fbb unwisely introduced a dependency on the StringInfo  
machinery in fe-connect.c.  We must not use that in libpq, because  
it will do a summary exit(1) if it hits OOM, and that is not  
appropriate behavior for a general-purpose library.  The goal of  
allowing arbitrary line lengths in service files doesn't seem like  
it's worth a lot of effort, so revert back to the previous method  
of using a stack-allocated buffer and failing on buffer overflow.  
  
This isn't an exact revert though.  I kept that patch's refactoring  
to have a single exit path, as that seems cleaner than having each  
error path know what to do to clean up.  Also, I made the fixed-size  
buffer 1024 bytes not 256, just to push off the need for an expandable  
buffer some more.  
  
There is more to do here; in particular the lack of any mechanical  
check for this type of mistake now seems pretty hazardous.  But this  
fix gets us back to the level of robustness we had in v13, anyway.  
  
Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com  

commit   : d5a2c413fcdd187dc16c4fab16610af7d4849cc1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 13:52:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 13:52:48 +0900    

The version string is grabbed from PACKAGE_VERSION in pg_config.h in the  
MSVC build since 8f4fb4c6, but an error message referenced a variable  
that existed before that.  This had no consequences except if one messes  
up enough with the version number of the build.  
  
Author: Anton Voloshin  
Discussion: https://postgr.es/m/af79ee1b-9962-b299-98e1-f90a289e19e6@postgrespro.ru  
Backpatch-through: 13  

commit   : 704e1dbd9aa29a0b46c356f1803ad55cbdef2c20    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 12:39:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 12:39:54 +0900    

002_pgbench_no_server was printing some array pointers instead of the  
actual contents of those arrays for the expected outputs of stdout and  
stderr for a tested command.  This does not add any new information that  
can help with debugging as the test names allow to track failure  
locations, if any.  
  
This commit simply removes those logs as the rest of the printed  
information is redundant with command_checks_all().  
  
Per discussion with Andrew Dunstan and Álvaro Herrera.  
  
Discussion: https://postgr.es/m/YNXNFaG7IgkzZanD@paquier.xyz  
Backpatch-through: 11  

commit   : 5a0f1c8c0193f0dd7fba50c22d96781fa2414007    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    

It's not really necessary for this function to open or lock the  
relation associated with the pg_policy entry it's modifying.  The  
error checks it's making on the rel are if anything counterproductive  
(e.g., if we don't want to allow installation of policies on system  
catalogs, here is not the place to prevent that).  In particular, it  
seems just wrong to insist on an ownership check.  That has the net  
effect of forcing people to use superuser for DROP OWNED BY, which  
surely is not an effect we want.  Also there is no point in rebuilding  
the dependencies of the policy expressions, which aren't being  
changed.  Lastly, locking the table also seems counterproductive; it's  
not helping to prevent race conditions, since we failed to re-read the  
pg_policy row after acquiring the lock.  That means that concurrent  
DDL would likely result in "tuple concurrently updated/deleted"  
errors; which is the same behavior this code will produce, with less  
overhead.  
  
Per discussion of bug #17062.  Back-patch to all supported versions,  
as the failure cases this eliminates seem just as undesirable in 9.6  
as in HEAD.  
  
Discussion: https://postgr.es/m/1573181.1624220108@sss.pgh.pa.us  

commit   : 8a80562d732c0da1ddcc9fb88dfb976f4b846577    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 11:18:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 11:18:15 -0400    

Now that this has been back-patched, it's no longer a new feature  
for v14.  

commit   : 38ff135d9466c35b506b1049fedef73047907be0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 20:15:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 20:15:24 +0900    

This fixes a couple of problems within the so-said code of this commit  
subject:  
- Replace the use of open() with slurp_file(), fixing an issue reported  
by buildfarm member fairywren whose perl installation keep around CRLF  
characters, causing the matching patterns for the logs to fail.  
- Remove the eval block, which is not really necessary.  
  
This set of issues has come into light after fixing a different issue  
with c13585fe, and this is wrong since this code has been introduced.  
  
Reported-by: Andrew Dunstan, and buildfarm member fairywren  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/0f49303e-7784-b3ee-200b-cbf67be2eb9e@dunslane.net  
Backpatch-through: 11  

commit   : 3af10943ce21450e299b3915b9cad47cd90369e9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 11:40:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 11:40:06 +0200    

commit   : e59d428f34297cd0eb67e3b4e4b8c8bc58504921    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 09:51:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 09:51:24 +0200    

ALTER SUBSCRIPTION DROP PUBLICATION does not actually support  
copy_data option, so remove it from tab completion.  
  
Also, reword the error message that is thrown when all the  
publications from a subscription are specified to be dropped.  
  
Also, made few doc and cosmetic adjustments.  
  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CALDaNm21RwsDzs4xj14ApteAF7auyyomHNnp+NEL-sH8m-jMvQ@mail.gmail.com  

commit   : 63e6d05bf34da58eef7cd1ed461b9c8315177a38    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 08:11:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 08:11:10 +0200    

Use "floating point" rather than "float4", like everywhere else in  
this context.  
  
Author: Shinya11.Kato@nttdata.com  
Discussion: https://www.postgresql.org/message-id/flat/TYAPR01MB28965989AF84B57FC351B97BC40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com  

commit   : a60c4c5c1a99746485123ae93fbd3e58c78e5d62    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 07:55:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 07:55:34 +0200    

In gistinitpage, pageSize variable looks redundant, instead just  
pass BLCKSZ. This will be consistent with its peers BloomInitPage,  
brin_page_init and SpGistInitPage.  
  
Author: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/CALj2ACWj=V1k5591eeZK2sOg2FYuBUp6azFO8tMkBtGfXf8PMQ@mail.gmail.com  

commit   : 847c62ee76cbc237b3a204ca94b1b12811d698e3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Jun 2021 08:22:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Jun 2021 08:22:44 +0530    

Author: Guillaume Lelarge  
Discussion: https://www.postgresql.org/message-id/CAECtzeXf3_oZoU6mgFCOy5+pDZ5n4XtH0Da4a5n_KacraVWiHQ@mail.gmail.com  

commit   : 15ff5401d1719aaf6c9a47e5abea517cc2bcbaf1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 11:29:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 11:29:03 +0900    

This adds MITM and SNI as acronyms, as the documentation already had  
them marked up with <acronym>.  
  
While on it, make sure to spell man-in-the-middle with dashes  
consistently, and add acronyms for those new terms where appropriate.  
  
Author: Daniel Gustafsson  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se  

commit   : 87b2124dfa0782a697ea7b90aff15a6f6117a720    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 09:56:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 09:56:44 +0900    

fairywren is not happy with the pattern checks introduced by c13585f.  
I am not sure if this outlines a bug in pgbench or if the regex patterns  
used in the tests are too restrictive for this buildfarm member's  
environment.  This adds more debugging information to show the log  
entries that do not match with the expected pattern, to help in finding  
out what's happening.  That seems like a good addition in the long-term  
anyway as that may not be the only issue in this area.  
  
Discussion: https://postgr.es/m/YNUad2HvgW+6eXyo@paquier.xyz  

commit   : 797b0fc0b078c7b4c46ef9f2d9e47aa2d98c6c63    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 08:40:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 08:40:16 +0900    

The main goal of this option is to allow inspecting temporary files for  
debugging purposes, so moving the parameter there is natural.  
  
Oversight in cd91de0.  
  
Reported-by: Justin Pryzby  
Author: Euler Taveira  
Discussion: https://postgr.es/m/20210612004347.GP16435@telsasoft.com  

commit   : 9b4e4cfe66ff133717c1b8ba3c2725d525c3e67c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 25 Jun 2021 09:55:26 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 25 Jun 2021 09:55:26 +1200    

LLVM 13 (due out in September) has changed the semantics of  
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to  
avoid a double-free that causes crashes and bad query results.  
  
A proactive change seems necessary to avoid having a window of time  
where our respective latest releases would interact badly.  It's  
possible that the situation could change before then, though.  
  
Thanks to Fabien Coelho for monitoring bleeding edge LLVM and Andres  
Freund for tracking down the change.  
  
Back-patch to 11, where the JIT code arrived.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLEy8mgtN7BNp0ooFAjUedDTJj5dME7NxLU-m91b85siA%40mail.gmail.com  

commit   : c13585fe9e55813cf9feac67fe7b65d3a78fff92    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 06:52:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 06:52:36 +0900    

The logic checking for the format of per-thread logs used grep() with  
directly "$re", which would cause the test to consider all the logs as  
a match without caring about their format at all.  Using "/$re/" makes  
grep() perform a regex test, which is what we want here.  
  
While on it, improve some of the tests to be more picky with the  
patterns expected and add more comments to describe the tests.  
  
Issue discovered while digging into a separate patch.  
  
Author: Fabien Coelho, Michael Paquier  
Discussion: https://postgr.es/m/YNPsPAUoVDCpPOGk@paquier.xyz  
Backpatch-through: 11  

commit   : 802177090992511c610804da54a4603d4f50c594    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Jun 2021 15:02:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Jun 2021 15:02:13 -0400    

The queries involving ft1_nopw don't stably return the same row  
anymore.  I surmise that an autovacuum hitting "S 1"."T 1"  
right after the updates introduced by f61db909d/5843659d0 freed  
some space, changing where subsequent insertions get stored.  
It's only by good luck that these results were stable before,  
though, since a LIMIT without ORDER BY isn't well defined,  
and it's not like we've ever treated that table as append-only  
in this test script.  
  
Since we only really care whether these commands succeed or not,  
just replace "SELECT *" with "SELECT 1".  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2021-06-23%2019%3A52%3A08  

commit   : 9b8ed0f52bffceaccf6fa650ffe482e7da20fbf2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    

In previous commit, I missed that relmap_redo() was also not acquiring the  
RelationMappingLock. Thanks to Thomas Munro for pointing that out.  
  
Backpatch-through: 9.6, like previous commit.  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com  

commit   : b6d8d2073f228d9f7198f1f9826d8f6ab643c219    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    

Contrary to the comment here, POSIX does not guarantee atomicity of a  
read(), if another process calls write() concurrently. Or at least Linux  
does not. Add locking to load_relmap_file() to avoid the race condition.  
  
Fixes bug #17064. Thanks to Alexander Lakhin for the report and test case.  
  
Backpatch-through: 9.6, all supported versions.  
Discussion: https://www.postgresql.org/message-id/17064-bb0d7904ef72add3@postgresql.org  

commit   : f08722cf83ab1fabee948a4e5754bf6236ad700b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 11:51:58 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 11:51:58 +0530    

Commits 9de77b5453 and ac4645c015 missed to update the logical replication  
message formats section in the docs.  
  
Author: Brar Piening  
Reviewed-by: Amit Kapila  
Discussion: https://www.postgresql.org/message-id/cc70956c-e578-e54f-49e6-b5d68c89576f@gmx.de  

commit   : c66fb78ebb4f473bb4fd8773de3cda9339e14f81    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 09:13:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 09:13:46 +0530    

Reported-by: Simon Riggs  
Author: Takamichi Osumi  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de  

commit   : a443c1b2d6a646cf90a8afc193c07ed12a2bf045    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    

For no obvious reason, isolationtester has always insisted that  
session and step names be written with double quotes.  This is  
fairly tedious and does little for test readability, especially  
since the names that people actually choose almost always look  
like normal identifiers.  Hence, let's tweak the lexer to allow  
SQL-like identifiers not only double-quoted strings.  
  
(They're SQL-like, not exactly SQL, because I didn't add any  
case-folding logic.  Also there's no provision for U&"..." names,  
not that anyone's likely to care.)  
  
There is one incompatibility introduced by this change: if you write  
"foo""bar" with no space, that used to be taken as two identifiers,  
but now it's just one identifier with an embedded quote mark.  
  
I converted all the src/test/isolation/ specfiles to remove  
unnecessary double quotes, but stopped there because my  
eyes were glazing over already.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/759113.1623861959@sss.pgh.pa.us  

commit   : 2031e1668e5577e64cfed29da69a34903d5a5227    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    

The syntax summaries for CREATE FUNCTION and allied commands  
made it look like LEAKPROOF is an alternative to  
IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal  
option.  Improve that.  
  
Per gripe from aazamrafeeque0.  Thanks to David Johnston for  
suggestions.  
  
Discussion: https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org  

commit   : 126cdaf47af275f76b2f2ddb023bfdc6f018ae30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:01:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:01:32 -0400    

Our uses of gss_display_status() and gss_display_name() assumed  
that the gss_buffer_desc strings returned by those functions are  
null-terminated.  It appears that they generally are, given the  
lack of field complaints up to now.  However, the available  
documentation does not promise this, and some man pages  
for gss_display_status() show examples that rely on the  
gss_buffer_desc.length field instead of expecting null  
termination.  Also, we now have a report that on some  
implementations, clang's address sanitizer is of the opinion  
that the byte after the specified length is undefined.  
  
Hence, change the code to rely on the length field instead.  
  
This might well be cosmetic rather than fixing any real bug, but  
it's hard to be sure, so back-patch to all supported branches.  
While here, also back-patch the v12 changes that made pg_GSS_error  
deal honestly with multiple messages available from  
gss_display_status.  
  
Per report from Sudheer H R.  
  
Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com  

commit   : 4a054069a36032a59afceb07f3b837f09ab1a2e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 11:12:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 11:12:31 -0400    

Previously, isolationtester displayed SQL query results using some  
ad-hoc code that clearly hadn't had much effort expended on it.  
Field values longer than 14 characters weren't separated from  
the next field, and usually caused misalignment of the columns  
too.  Also there was no visual separation of a query's result  
from subsequent isolationtester output.  This made test result  
files confusing and hard to read.  
  
To improve matters, let's use libpq's PQprint() function.  Although  
that's long since unused by psql, it's still plenty good enough  
for the purpose here.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/582362.1623798221@sss.pgh.pa.us  

commit   : 24043c27b46f873211177e3460ab09dc011802a5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 23 Jun 2021 09:53:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 23 Jun 2021 09:53:18 -0400    

The code to signal a running walsender when its reserved WAL size grows  
too large is completely uncovered before this commit; this adds coverage  
for that case.  
  
This test involves sending SIGSTOP to walsender and walreceiver, then  
advancing enough WAL for a checkpoint to trigger, then sending SIGCONT.  
  
There's no precedent for STOP signalling in Perl tests, and my reading  
of relevant manpages says it's likely to fail on Windows.  Because of  
this, this test is always skipped on that platform.  
  
This version fixes a couple of rarely hit race conditions in the  
previous attempt 09126984a263; most notably, both LOG string searches  
are loops, not just the second one; we acquire the start-of-log position  
before STOP-signalling; and reference the correct process name in the  
test description.  All per Tom Lane.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106102202.mjw4huiix7lo@alvherre.pgsql  

commit   : 741d7f1047fe52da7ced6fa9cea661ce9320c8d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    

We've long contended with isolation test results that aren't entirely  
stable.  Some test scripts insert long delays to try to force stable  
results, which is not terribly desirable; but other erratic failure  
modes remain, causing unrepeatable buildfarm failures.  I've spent a  
fair amount of time trying to solve this by improving the server-side  
support code, without much success: that way is fundamentally unable  
to cope with diffs that stem from chance ordering of arrival of  
messages from different server processes.  
  
We can improve matters on the client side, however, by annotating  
the test scripts themselves to show the desired reporting order  
of events that might occur in different orders.  This patch adds  
three types of annotations to deal with (a) test steps that might or  
might not complete their waits before the isolationtester can see them  
waiting; (b) test steps in different sessions that can legitimately  
complete in either order; and (c) NOTIFY messages that might arrive  
before or after the completion of a step in another session.  We might  
need more annotation types later, but this seems to be enough to deal  
with the instabilities we've seen in the buildfarm.  It also lets us  
get rid of all the long delays that were previously used, cutting more  
than a minute off the runtime of the isolation tests.  
  
Back-patch to all supported branches, because the buildfarm  
instabilities affect all the branches, and because it seems desirable  
to keep isolationtester's capabilities the same across all branches  
to simplify possible future back-patching of tests.  
  
Discussion: https://postgr.es/m/327948.1623725828@sss.pgh.pa.us  

commit   : d102aafb6259a6a412803d4b1d8c4f00aa17f67e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 17:48:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 17:48:39 -0400    

Commits 84f5c2908 et al missed the need to cover plpgsql's "simple  
expression" code path.  If the first thing we execute after a  
COMMIT/ROLLBACK is one of those, rather than a full-fledged SPI command,  
we must explicitly do EnsurePortalSnapshotExists() to make sure we have  
an outer snapshot.  Note that it wouldn't be good enough to just push a  
snapshot for the duration of the expression execution: what comes back  
might be toasted, so we'd better have a snapshot protecting it.  
  
The test case demonstrating this fact cheats a bit by marking a SQL  
function immutable even though it fetches from a table.  That's  
nothing that users haven't been seen to do, though.  
  
Per report from Jim Nasby.  Back-patch to v11, like the previous fix.  
  
Discussion: https://postgr.es/m/378885e4-f85f-fc28-6c91-c4d1c080bf26@amazon.com  

commit   : 8e638845ff6bb255ad1dea15831089a234535391    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 22 Jun 2021 09:06:32 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 22 Jun 2021 09:06:32 -0700    

Add a .git-blame-ignore-revs file with a list of pgindent, pgperlyidy,  
and reformat-dat-files commit hashes.  Postgres hackers that configure  
git to use the ignore file will get git-blame output that avoids  
attributing line changes to the ignored indent commits.  This makes  
git-blame output much easier to work with in practice.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAH2-Wz=cVh3GHTP6SdLU-Gnmt2zRdF8vZkcrFdSzXQ=WhbWm9Q@mail.gmail.com  

commit   : bafad2c5b261a1449bed60ebac9e7918ebcc42b4    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 21 Jun 2021 17:07:55 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 21 Jun 2021 17:07:55 -0400    

commit   : 5a1e1d83022b976ebdec5cfa8f255c4278b75b8e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 21 Jun 2021 05:13:46 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 21 Jun 2021 05:13:46 -0700    

In dc7420c2c92 I (Andres) accidentally used  
RelationIsAccessibleInLogicalDecoding() as the sole condition to use the  
non-shared catalog horizon in GetOldestNonRemovableTransactionId(). That is  
incorrect, as RelationIsAccessibleInLogicalDecoding() checks whether wal_level  
is logical.  
  
The correct check, as done e.g. in GlobalVisTestFor(), is to check  
IsCatalogRelation() and RelationIsAccessibleInLogicalDecoding().  
  
The observed misbehavior of this bug was that there could be an endless loop  
in lazy_scan_prune(), because the horizons used in heap_page_prune() and the  
individual tuple liveliness checks did not match. Likely there are other  
potential consequences as well.  
  
A later commit will unify the determination which horizon has to be used, and  
add additional assertions to make it easier to catch a bug like this.  
  
Reported-By: Justin Pryzby <pryzby@telsasoft.com>  
Diagnosed-By: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Discussion: https://postgr.es/m/CAEze2Wg32Y9+WJfw=aofkRx1ZRFt_Ev6bNPc4PSaz7PjSFtZgQ@mail.gmail.com  

commit   : 8d29d45d9b3cab95a866efbcdd9138b3d76741b3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Jun 2021 23:11:23 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Jun 2021 23:11:23 +1200    

linitial_node() fails in assert enabled builds if the given pointer is  
not of the specified type.  Here the type is IntList.  The code thought  
it should be expecting List, but it was wrong.  
  
In the existing tests which run this code the initial list element is  
always NIL.  Since linitial_node() allows NULL, we didn't trigger any  
assert failures in the existing regression tests.  
  
There is still some discussion as to whether we need a few more tests in  
this area, but for now, since beta2 is looming, fix the bug first.  
  
Bug: #17067  
Discussion: https://postgr.es/m/17067-665d50fa321f79e0@postgresql.org  
Reported-by: Yaoguang Chen  

commit   : a7bb0ce58f56ee8907c3f49c52d99f502536c796    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 12:32:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 12:32:14 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 70796ae860c444c764bb591c885f22cac1c168ec  

commit   : 047a259e35b9dde2dad5fd0e5d5d784bb327b848    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 21 Jun 2021 02:48:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 21 Jun 2021 02:48:11 -0700    

Jie Zhang  
  
Discussion: https://postgr.es/m/TYWPR01MB767844835390EDD8DB276D75F90A9@TYWPR01MB7678.jpnprd01.prod.outlook.com  

commit   : 97b7134186490b36e01efc9d2feaf7038c666457    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 11:17:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 11:17:49 +0200    

Code comments were claiming that verify_heapam() was checking  
privileges on the relation it was operating on, but it didn't actually  
do that.  Perhaps earlier versions of the patch did that, but now the  
access is regulated by privileges on the function.  Remove the wrong  
comments.  

commit   : 69a58bfe4ab05567a8fab8bdce7f3095ed06b99c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 21 Jun 2021 01:09:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 21 Jun 2021 01:09:32 -0400    

commit   : 90855908b751d40f67352fa0252e0fcdaa7e317b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 20 Jun 2021 23:53:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 20 Jun 2021 23:53:00 -0400    

Reported-by: Masahiko Sawada  
  
Discussion: https://postgr.es/m/CAD21AoCTHyouoGv-xt1qNjjvPbGMErLi0AJncByTvr66Nq7j8g@mail.gmail.com  

commit   : e8f201ab82be234b2f103234cf9f262f9afeaeba    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 20 Jun 2021 18:14:00 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 20 Jun 2021 18:14:00 -0700    

The failsafe can trigger when index processing is already disabled.  
This can happen when VACUUM's INDEX_CLEANUP parameter is "off" and the  
failsafe happens to trigger.  Remove assertions that assume that index  
processing is directly tied to the failsafe.  
  
Oversight in commit c242baa4, which made it possible for the failsafe to  
trigger in a two-pass strategy VACUUM that has yet to make its first  
call to lazy_vacuum_all_indexes().  

commit   : 96795176810b979a2bf1f4563bdcb161679d5b95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 20 Jun 2021 12:28:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 20 Jun 2021 12:28:08 -0400    

This reverts commit 09126984a263; the test case added there failed once  
in circumstances that remain mysterious.  It seems better to remove the  
test for now so that 14beta2 doesn't have random failures built in.  

commit   : 5843659d091bfb6f2c60e010ea1fd00e55ee6ada    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Jun 2021 11:48:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Jun 2021 11:48:44 -0400    

Buildfarm members ayu and tern have sometimes shown a different  
plan than expected for this query.  I'd been unable to reproduce  
that before today, but I finally realized what is happening.  
If there is a concurrent open transaction (probably an autovacuum  
run in the buildfarm, but this can also be arranged manually),  
then the index entries for the rows removed by the DELETE a few  
lines up are not killed promptly, causing a change in the planner's  
estimate of the extremal value of ft2.c1, which moves the rowcount  
estimate for "c1 > 1100" by enough to change the join plan from  
nestloop to hash.  
  
To fix, change the query condition to "c1 > 1000", causing the  
hash plan to be preferred whether or not a concurrent open  
transaction exists.  Since this UPDATE is tailored to be a no-op,  
nothing else changes.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-09%2022%3A45%3A48  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-13%2022%3A38%3A18  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2021-06-20%2004%3A55%3A36  

commit   : 6991e774e0304f5ef488cf1ae4fa79578b6ae3d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jun 2021 11:44:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jun 2021 11:44:39 -0400    

We had a request to provide a way to test at compile time for the  
availability of the new pipeline features.  More generally, it  
seems like a good idea to provide a way to test via #ifdef for  
all new libpq API features.  People have been using the version  
from pg_config.h for that; but that's more likely to represent the  
server version than the libpq version, in the increasingly-common  
scenario where they're different.  It's safer if libpq-fe.h itself  
is the source of truth about what features it offers.  
  
Hence, establish a policy that starting in v14 we'll add a suitable  
feature-is-present macro to libpq-fe.h when we add new API there.  
(There doesn't seem to be much point in applying this policy  
retroactively, but it's not too late for v14.)  
  
Tom Lane and Alvaro Herrera, per suggestion from Boris Kolpackov.  
  
Discussion: https://postgr.es/m/boris.20210617102439@codesynthesis.com  

commit   : 2731ce1bd550d08f3fdd7bcb1497af4b95170976    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 19 Jun 2021 11:30:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 19 Jun 2021 11:30:33 +0530    

Commit e7eea52b2d has introduced a new function  
RelationGetIdentityKeyBitmap which omits to handle the case where there is  
no replica identity index on a relation.  
  
Author: Mark Dilger  
Reviewed-by: Takamichi Osumi, Amit Kapila  
Discussion: https://www.postgresql.org/message-id/4C99A862-69C8-431F-960A-81B1151F1B89@enterprisedb.com  

commit   : 3499df0dee8c4ea51d264a674df5b5e31991319a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 18 Jun 2021 20:04:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 18 Jun 2021 20:04:07 -0700    

Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding  
reloption): make it into a ternary style boolean parameter.  It now  
exposes a third option, "auto".  The "auto" option (which is now the  
default) enables the "bypass index vacuuming" optimization added by  
commit 1e55e7d1.  
  
"VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM  
simply do any required index vacuuming, regardless of how few dead  
tuples are encountered during the first scan of the target heap relation  
(unless there are exactly zero).  This gives users a way of opting out  
of the "bypass index vacuuming" optimization, if for whatever reason  
that proves necessary.  It is also expected to be used by PostgreSQL  
developers as a testing option from time to time.  
  
"VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it  
forcibly disables both index vacuuming and index cleanup.  It's not  
expected to be used much in PostgreSQL 14.  The failsafe mechanism added  
by commit 1e55e7d1 addresses the same problem in a simpler way.  
INDEX_CLEANUP can now be thought of as a testing and compatibility  
option.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-By: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com  

commit   : 09126984a2631db8dd6299f23954e0dede69735f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Jun 2021 18:42:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Jun 2021 18:42:00 -0400    

The code to signal a running walsender when its reserved WAL size grows  
too large is completely uncovered before this commit; this adds coverage  
for that case.  
  
This test involves sending SIGSTOP to walsender and walreceiver and  
running a checkpoint while advancing WAL, then sending SIGCONT.  There's  
no precedent for this coding in Perl tests, and my reading of relevant  
manpages says it's likely to fail on Windows.  Because of this, this  
test is always skipped on that platform.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106102202.mjw4huiix7lo@alvherre.pgsql  

commit   : d21fca084356946664bfce19d66d2df2bb873cbd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    

Ordinarily, a pg_policy.polroles array wouldn't list the same role  
more than once; but CREATE POLICY does not prevent that.  If we  
perform DROP OWNED BY on a role that is listed more than once,  
RemoveRoleFromObjectPolicy either suffered an assertion failure  
or encountered a tuple-updated-by-self error.  Rewrite it to cope  
correctly with duplicate entries, and add a CommandCounterIncrement  
call to prevent the other problem.  
  
Per discussion, there's other cleanup that ought to happen here,  
but this seems like the minimum essential fix.  
  
Per bug #17062 from Alexander Lakhin.  It's been broken all along,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17062-11f471ae3199ca23@postgresql.org  

commit   : 84bee9610965331d5110971d8de390a5bbe2effc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 17:05:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 17:05:23 -0400    

Commit 547f04e73 caused pgbench to start printing its version number,  
which seems like a fine idea, but it needs a bit more work:  
* Print the server version number too, when different.  
* Print the PG_VERSION string, not some reconstructed approximation.  
  
This patch copies psql's well-tested code for the same purpose.  
  
Discussion: https://postgr.es/m/1226654.1624036821@sss.pgh.pa.us  

commit   : 7c337b6b527b7052e6a751f966d5734c56f668b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 11:22:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 11:22:58 -0400    

In the "simple Query" code path, it's fine for parse analysis or  
execution of a utility statement to scribble on the statement's node  
tree, since that'll just be thrown away afterwards.  However it's  
not fine if the node tree is in the plan cache, as then it'd be  
corrupted for subsequent executions.  Up to now we've dealt with  
that by having individual utility-statement functions apply  
copyObject() if they were going to modify the tree.  But that's  
prone to errors of omission.  Bug #17053 from Charles Samborski  
shows that CREATE/ALTER DOMAIN didn't get this memo, and can  
crash if executed repeatedly from plan cache.  
  
In the back branches, we'll just apply a narrow band-aid for that,  
but in HEAD it seems prudent to have a more principled fix that  
will close off the possibility of other similar bugs in future.  
Hence, let's hoist the responsibility for doing copyObject up into  
ProcessUtility from its children, thus ensuring that it happens for  
all utility statement types.  
  
Also, modify ProcessUtility's API so that its callers can tell it  
whether a copy step is necessary.  It turns out that in all cases,  
the immediate caller knows whether the node tree is transient, so  
this doesn't involve a huge amount of code thrashing.  In this way,  
while we lose a little bit in the execute-from-cache code path due  
to sometimes copying node trees that wouldn't be mutated anyway,  
we gain something in the simple-Query code path by not copying  
throwaway node trees.  Statements that are complex enough to be  
expensive to copy are almost certainly ones that would have to be  
copied anyway, so the loss in the cache code path shouldn't be much.  
  
(Note that this whole problem applies only to utility statements.  
Optimizable statements don't have the issue because we long ago made  
the executor treat Plan trees as read-only.  Perhaps someday we will  
make utility statement execution act likewise, but I'm not holding  
my breath.)  
  
Discussion: https://postgr.es/m/931771.1623893989@sss.pgh.pa.us  
Discussion: https://postgr.es/m/17053-3ca3f501bbc212b4@postgresql.org  

commit   : 0a4efdc7ebf2584257b166c87e82797eb92815b5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Jun 2021 06:51:12 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Jun 2021 06:51:12 -0400    

The fast default code added in Release 11 omitted to check that the  
table a fast default was being added to was a plain table. Thus one  
could be added to a foreign table, which predicably blows up. Here we  
perform that check.  
  
In addition, on the back branches, since some of these might have  
escaped into the wild, if we encounter a missing value for  
an attribute of something other than a plain table we ignore it.  
  
Fixes bug #17056  
  
Backpatch to release 11,  
  
Reviewed by: Andres Freund, Álvaro Herrera and Tom Lane  

commit   : 981524d2e3aa3f28d364c472e34f5386be846811    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Jun 2021 17:57:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Jun 2021 17:57:09 +0900    

Commit d75288fb27 made WAL archiver process an auxiliary process.  
An auxiliary process needs to handle barrier events but the commit  
forgot to make archiver process do that.  
  
Reported-by: Thomas Munro  
Author: Fujii Masao  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGLah2w1pWKHonZP_+EQw69=q56AHYwCgEN8GDzsRG_Hgw@mail.gmail.com  

commit   : f80979f659d39e238e95444e6752142799428078    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Jun 2021 14:22:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Jun 2021 14:22:31 +0900    

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se  

commit   : d24c5658a80c8f5037e9e1948de311d3f3350f12    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    

One of the error paths left *members uninitialized. That's not a live  
bug, because most callers don't look at *members when the function  
returns -1, but let's be tidy. One caller, in heap_lock_tuple(), does  
"if (members != NULL) pfree(members)", but AFAICS it never passes an  
invalid 'multi' value so it should not reach that error case.  
  
The callers are also a bit inconsistent in their expectations.  
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others  
pfree() it if "nmembers >= 0", and others if "nmembers > 0". That's  
not a live bug either, because the function should never return 0, but  
add an Assert for that to make it more clear. I left the callers alone  
for now.  
  
I also moved the line where we set *nmembers. It wasn't wrong before,  
but I like to do that right next to the 'return' statement, to make it  
clear that it's always set on return.  
  
Also remove one unreachable return statement after ereport(ERROR), for  
brevity and for consistency with the similar if-block right after it.  
  
Author: Greg Nancarrow with the additional changes by me  
Backpatch-through: 9.6, all supported versions  

commit   : 3cb828dbe26087e7754f49f3cfe3ed036d5af439    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Jun 2021 09:56:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Jun 2021 09:56:05 +0530    

In a synchronous logical setup, locking [user] catalog tables can cause  
deadlock. This is because logical decoding of transactions can lock  
catalog tables to access them so exclusively locking those in transactions  
can lead to deadlock. To avoid this users must refrain from having  
exclusive locks on catalog tables.  
  
Author: Takamichi Osumi  
Reviewed-by: Vignesh C, Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de  

commit   : 131ea3e908d3c97a2fe1ab25cce5046dd5cb905f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    

When stuffing a plan from the plancache into a Portal, one is  
not supposed to risk throwing an error between GetCachedPlan and  
PortalDefineQuery; if that happens, the plan refcount incremented  
by GetCachedPlan will be leaked.  I managed to break this rule  
while refactoring code in 9dbf2b7d7.  There is no visible  
consequence other than some memory leakage, and since nobody is  
very likely to trigger the relevant error conditions many times  
in a row, it's not surprising we haven't noticed.  Nonetheless,  
it's a bug, so rearrange the order of operations to remove the  
hazard.  
  
Noted on the way to looking for a better fix for bug #17053.  
This mistake is pretty old, so back-patch to all supported  
branches.  

commit   : 99cea49d6525e30bc3768e4ffb95377e7584dea1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Jun 2021 22:53:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Jun 2021 22:53:31 +0200    

Commit b676ac443b optimized handling of tuple slots with bulk inserts  
into foreign tables, so that the slots are initialized only once and  
reused for all batches. The data was however copied into the slots only  
after the initialization, inserting duplicate values when the slot gets  
reused. Fixed by moving the ExecCopySlot outside the init branch.  
  
The existing postgres_fdw tests failed to catch this due to inserting  
data into foreign tables without unique indexes, and then checking only  
the number of inserted rows. This adds a new test with both a unique  
index and a check of inserted values.  
  
Reported-by: Alexander Pyhalov  
Discussion: https://postgr.es/m/7a8cf8d56b3d18e5c0bccd6cd42d04ac%40postgrespro.ru  

commit   : 6b787d9e32005867ee3660d1ea20f447810a403d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 11:52:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 11:52:05 -0400    

I started out with the goal of reporting ERRCODE_CONNECTION_FAILURE  
when walrcv_connect() fails, but as I looked around I realized that  
whoever wrote this code was of the opinion that errcodes are purely  
optional.  That's not my understanding of our project policy.  Hence,  
make sure that an errcode is provided in each ereport that (a) is  
ERROR or higher level and (b) isn't arguably an internal logic error.  
Also fix some very dubious existing errcode assignments.  
  
While this is not per policy, it's also largely cosmetic, since few  
of these cases could get reported to applications.  So I don't  
feel a need to back-patch.  
  
Discussion: https://postgr.es/m/2189704.1623512522@sss.pgh.pa.us  

commit   : d0303bc8d2670d11c9df9220aa08a2c33529e100    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jun 2021 12:34:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jun 2021 12:34:32 +0300    

Since commit c24dcd0cfd, we have been using pg_pread() to read the WAL  
file, which doesn't change the seek position (unless we fall back to  
the implementation in src/port/pread.c). Update comment accordingly.  
  
Backpatch-through: 12, where we started to use pg_pread()  

commit   : d3c878499c9d639ff06e0664d06b8c731e30c2fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:11:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:11:45 -0400    

This should have been updated in 533e9c6b0, but it was overlooked.  
Given the lack of complaints, I won't bother back-patching.  

commit   : f6352a0d4e437ac8bc266f77df22d064592056c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:09:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:09:14 -0400    

aborted-keyrevoke_2.out was apparently needed when it was added (in  
commit 0ac5ad513) to handle the case of serializable transaction mode.  
However, the output in serializable mode actually matches the regular  
aborted-keyrevoke.out file, and AFAICT has done so for a long time.  
There's no need to keep dragging this variant along.  

commit   : 54a5ed22016940d7ad5060ed62d23473924756a1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    

TestLib::perl2host can take a file argument as well as a directory  
argument, so that code becomes substantially simpler. Also add comments  
on why we're using forward slashes, and why we're setting  
PERL_BADLANG=0.  
  
Discussion: https://postgr.es/m/e9947bcd-20ee-027c-f0fe-01f736b7e345@dunslane.net  

commit   : 817bb0a7d1e02df4643d37304aed8574cf43f629    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 21:43:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 21:43:17 +0300    

Reported-by: Tom Lane  
Discussion: https://postgr.es/m/CAPpHfdvcnw3x7jdV3r52p4%3D5S4WUxBCzcQKB3JukQHoicv1LSQ%40mail.gmail.com  

commit   : 958cfbcf2dd338e3179c2d8a35f48bde020eba60    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 15 Jun 2021 08:59:36 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 15 Jun 2021 08:59:36 -0700    

Bugfix commit 5fc89376 effectively made the lock_waiter_detected field  
from vacuumlazy.c's global state struct into private state owned by  
lazy_truncate_heap().  Finish this off by replacing the struct field  
with a local variable.  

commit   : ad2da246c69dd5ec55764d4b6066f3b0c0d24ca2    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 16:06:32 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 16:06:32 +0300    

Discussion: https://postgr.es/m/CAFj8pRDioOxiJgmgw9TqQqZ3CxnJC4P5B2Oospf2eMgAjJuewA%40mail.gmail.com  
Author: Pavel Stehule, Alexander Korotkov  
Reviewed-by: Justin Pryzby, Tom Lane  

commit   : 29854ee8d1ca4a46adb7e84deb17e6fb18e531cc    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 15:59:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 15:59:20 +0300    

It has been spotted that multiranges lack of ability to decompose them into  
individual ranges.  Subscription and proper expanded object representation  
require substantial work, and it's too late for v14.  This commit  
provides the implementation of unnest(multirange) and cast multirange as  
an array of ranges, which is quite trivial.  
  
unnest(multirange) is defined as a polymorphic procedure.  The catalog  
description of the cast underlying procedure is duplicated for each multirange  
type because we don't have anyrangearray polymorphic type to use here.  
  
Catversion is bumped.  
  
Reported-by: Jonathan S. Katz  
Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org  
Author: Alexander Korotkov  
Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu  

commit   : 4daa140a2f50e9a160bc180c3997ee13c7aabf9e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 08:28:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 08:28:36 +0530    

During decoding for speculative inserts, we were relying for cleaning  
toast hash on confirmation records or next change records. But that  
could lead to multiple problems (a) memory leak if there is neither a  
confirmation record nor any other record after toast insertion for a  
speculative insert in the transaction, (b) error and assertion failures  
if the next operation is not an insert/update on the same table.  
  
The fix is to start queuing spec abort change and clean up toast hash  
and change record during its processing. Currently, we are queuing the  
spec aborts for both toast and main table even though we perform cleanup  
while processing the main table's spec abort record. Later, if we have a  
way to distinguish between the spec abort record of toast and the main  
table, we can avoid queuing the change for spec aborts of toast tables.  
  
Reported-by: Ashutosh Bapat  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com  

commit   : 0a1e80c5c4f094087257fc4284a87e0bc7bca591    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:58:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:58:26 -0400    

This should have been updated in d2d8a229b, but it was overlooked.  
According to 31a877f18 which added it, this file is meant to show the  
results you get under default_transaction_isolation = serializable.  
We've largely lost track of that goal in other isolation tests, but  
as long as we've got this one, it should be right.  
  
Noted while fooling about with the isolationtester.  

commit   : ffbe9dec13599fa786ea6567df1c6a3f3ee3c673    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:28:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:28:21 -0400    

This should have been removed in 43e084197, which removed the  
corresponding spec file.  Noted while fooling about with the  
isolationtester.  

commit   : 5f1df62a459b51ab3bb625a0ee5e655429254257    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    

It was unable to wait on a backend that had already left the procarray.  
Users tolerant of that limitation can poll pg_stat_activity.  Other  
users can employ the "timeout" argument of pg_terminate_backend().  
  
Reviewed by Bharath Rupireddy.  
  
Discussion: https://postgr.es/m/20210605013236.GA208701@rfd.leadboat.com  

commit   : 0aac73e6a2602696d23aa7a9686204965f9093dc    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    

Revert the pg_description entry to its v13 form, since those messages  
usually remain shorter and don't discuss individual parameters.  No  
catversion bump, since pg_description content does not impair backend  
compatibility or application compatibility.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20210612182743.GY16435@telsasoft.com  

commit   : 33c509956704e1d918077b51ccd954f2e201a8f5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Jun 2021 16:31:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Jun 2021 16:31:12 -0400    

I overlooked that one condition was logically inverted.  The fix is a  
little bit more involved than simply negating the condition, to make  
the code easier to read.  
  
Fix some outdated comments left by the same commit, while at it.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/YMRlmB3/lZw8YBH+@paquier.xyz  

commit   : 86b222b09071d3918c5c55b164d22b2236d3f872    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:14:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:14:04 -0400    

Items related to logical replication attribution and BRIN indexes  
  
Reported-by: Tomas Vondra, John Naylor  
  
Discussion: https://postgr.es/m/0db66294-a668-2caa-2b5e-a8db60b30662@enterprisedb.com, CAFBsxsH21KnteYdk33F1oZu2O726NSD6_XBq51Tn0jytsA1AnA@mail.gmail.com  

commit   : a2559d4093725592a3fd5da8a4c7ac7c883115a0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:03:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:03:18 -0400    

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

commit   : 25dfb5a831a1b8a83a8a68453b4bbe38a5ef737e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 12:49:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 12:49:05 -0400    

User-defined objects that reference some built-in array functions will  
need to be recreated in PG 14.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210608225618.GR16435@telsasoft.com  

commit   : 2d689babe3cb50dcb29f6ed595a61d56e518c0d8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 14:57:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 14:57:22 +0900    

An object found as dropped when digging into the list of objects  
returned by pg_event_trigger_ddl_commands() could cause a cache lookup  
error, as the calls grabbing for the object address and the type name  
would fail if the object was missing.  
  
Those lookup errors could be seen with combinations of ALTER TABLE  
sub-commands involving identity columns.  The lookup logic is changed in  
this code path to get a behavior similar to any other SQL-callable  
function by ignoring objects that are not found, taking advantage of  
2a10fdc.  The back-branches are not changed, as they require this commit  
that is too invasive for stable branches.  
  
While on it, add test cases to exercise event triggers with identity  
columns, and stress more cases with the event ddl_command_end for  
relations.  
  
Author: Sven Klemm, Aleksander Alekseev, Michael Paquier  
Discussion: https://postgr.es/m/CAMCrgp2R1cEXU53iYKtW6yVEp2_yKUz+z=3-CTrYpPP+xryRtg@mail.gmail.com  

commit   : dbab0c07e5ba1f19a991da2d72972a8fe9a41bda    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 09:25:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 09:25:50 +0900    

The extra checks added by the recompression of toast data introduced in  
bbe0a81 is proving to have a performance impact on VACUUM or CLUSTER  
even if no recompression is done.  This is more noticeable with more  
toastable columns that contain non-NULL values.  
  
Improvements could be done to make those extra checks less expensive,  
but that's not material for 14 at this stage, and we are not sure either  
if the code path of VACUUM FULL/CLUSTER is adapted for this job.  
  
Per discussion with several people, including Andres Freund, Robert  
Haas, Álvaro Herrera, Tom Lane and myself.  
  
Discussion: https://postgr.es/m/20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de  

commit   : f807e3410fdfc29ced6590c7c2afa76637e001ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    

Recent glibc versions have made mktime() fail if tm_isdst is  
inconsistent with the prevailing timezone; in particular it fails for  
tm_isdst = 1 when the zone is UTC.  (This seems wildly inconsistent  
with the POSIX-mandated treatment of "incorrect" values for the other  
fields of struct tm, so if you ask me it's a bug, but I bet they'll  
say it's intentional.)  This has been observed to cause cosmetic  
problems when pg_restore'ing an archive created in a different  
timezone.  
  
To fix, do mktime() using the field values from the archive, and if  
that fails try again with tm_isdst = -1.  This will give a result  
that's off by the UTC-offset difference from the original zone, but  
that was true before, too.  It's not terribly critical since we don't  
do anything with the result except possibly print it.  (Someday we  
should flush this entire bit of logic and record a standard-format  
timestamp in the archive instead.  That's not okay for a back-patched  
bug fix, though.)  
  
Also, guard our only other use of mktime() by having initdb's  
build_time_t() set tm_isdst = -1 not 0.  This case could only have  
an issue in zones that are DST year-round; but I think some do exist,  
or could in future.  
  
Per report from Wells Oliver.  Back-patch to all supported  
versions, since any of them might need to run with a newer glibc.  
  
Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com  

commit   : 9d97c3408319b43718e4b85bc694697db1af32c6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    

Translate path slashes on target directory path. This was confusing old  
branches, but is applied to all branches for the sake of uniformity.  
Perl is perfectly able to understand paths with forward slashes.  
  
Along the way, restore the previous archive_wait query, for the sake of  
uniformity with other tests, per gripe from Tom Lane.  

commit   : a9e0b3b08fe38d5e31f03ea96859ff5e413d4a38    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:07:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:07:39 +0900    

This is similar to the work done in 8279f68 for TestLib.pm, where  
environment variables set may cause unwanted failures if using a  
temporary installation with pg_regress.  The list of variables reset is  
adjusted in each stable branch depending on what is supported.  
  
Comments are added to remember that the lists in TestLib.pm and  
pg_regress.c had better be kept in sync.  
  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/YMNR9GYDn+fHlMta@paquier.xyz  
Backpatch-through: 9.6  

commit   : f452aaf7d4a96cfcecd6c60ccd294ffe7b8ea088    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 15:12:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 15:12:10 -0400    

Several TAP tests use poll_query_until() to wait for the postmaster  
to restart.  They were checking to see if a trivial query  
(e.g. "SELECT 1") succeeds.  However, that's problematic in the wake  
of commit 11e9caff8, because now that we feed said query to psql  
via stdin, we risk IPC::Run whining about a SIGPIPE failure if psql  
quits before reading the query.  Hence, we can't use a nonempty  
query in cases where we need to wait for connection failures to  
stop happening.  
  
Per the precedent of commits c757a3da0 and 6d41dd045, we can pass  
"undef" as the query in such cases to ensure that IPC::Run has  
nothing to write.  However, then we have to say that the expected  
output is empty, and this exposes a deficiency in poll_query_until:  
if psql fails altogether and returns empty stdout, poll_query_until  
will treat that as a success!  That's because, contrary to its  
documentation, it makes no actual check for psql failure, looking  
neither at the exit status nor at stderr.  
  
To fix that, adjust poll_query_until to insist on empty stderr as  
well as a stdout match.  (I experimented with checking exit status  
instead, but it seems that psql often does exit(1) in cases that we  
need to consider successes.  That might be something to fix someday,  
but it would be a non-back-patchable behavior change.)  
  
Back-patch to v10.  The test cases needing this exist only as far  
back as v11, but it seems wise to keep poll_query_until's behavior  
the same in v10, in case we back-patch another such test case in  
future.  (9.6 does not currently need this change, because in that  
branch poll_query_until can't be told to accept empty stdout as  
a success case.)  
  
Per assorted buildfarm failures, mostly on hoverfly.  
  
Discussion: https://postgr.es/m/CAA4eK1+zM6L4QSA1XMvXY_qqWwdUmqkOS1+hWvL8QcYEBGA1Uw@mail.gmail.com  

commit   : 1250aad42520fd5a3db68d6381997b7e1f9bb4aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    

Previously, a zero value for the relfilenode resulted in  
a confusing error message about "unexpected duplicate".  
This function returns NULL for other invalid relfilenode  
values, so zero should be treated likewise.  
  
It's been like this all along, so back-patch to all supported  
branches.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20210612023324.GT16435@telsasoft.com  

commit   : fe6a20ce54cbbb6fcfe9f6675d563af836ae799a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 12:59:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 12:59:15 -0400    

Using an Assert to check the validity of incoming messages is an  
extremely poor decision.  In a debug build, it should not be that easy  
for a broken or malicious remote client to crash the logrep worker.  
The consequences could be even worse in non-debug builds, which will  
fail to make such checks at all, leading to who-knows-what misbehavior.  
Hence, promote every Assert that could possibly be triggered by wrong  
or out-of-order replication messages to a full test-and-ereport.  
  
To avoid bloating the set of messages the translation team has to cope  
with, establish a policy that replication protocol violation error  
reports don't need to be translated.  Hence, all the new messages here  
use errmsg_internal().  A couple of old messages are changed likewise  
for consistency.  
  
Along the way, fix some non-idiomatic or outright wrong uses of  
hash_search().  
  
Most of these mistakes are new with the "streaming replication"  
patch (commit 464824323), but a couple go back a long way.  
Back-patch as appropriate.  
  
Discussion: https://postgr.es/m/1719083.1623351052@sss.pgh.pa.us  

commit   : c3652f976b7696a96a9c5606cc2d613af77e2e63    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    

Commit caba8f0d43 wasn't quite right for msys, as demonstrated by  
several buildfarm animals, including jacana and fairywren. We need to  
use the msys perl in the archive command, but call it in such a way that  
Windows will understand the path. Furthermore, inside the copy script we  
need to convert a Windows path to an msys path.  

commit   : b56b83aa0d6e044cf38d553f7a87f4b84708cac6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 16:29:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 16:29:11 +0900    

This routine is designed to never return an empty description or NULL,  
providing description fallbacks even if missing objects are accepted,  
but it included a code path where this was considered possible.  All the  
callers of this routine already consider NULL as not possible, so  
change a bit the code to map with the assumptions of the callers, and  
add more comments close to the callers of this routine to outline the  
behavior expected.  
  
This code is new as of 2a10fdc, so no backpatch is needed.  
  
Discussion: https://postgr.es/m/YMNY6RGPBRCeLmFb@paquier.xyz  

commit   : bfd96b7a3dc26a8384d4185d274573fb6a46b033    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 15:29:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 15:29:48 +0900    

ab55d74 has introduced some tests with rows found as missing in logical  
replication subscriptions for partitioned tables, relying on a logic  
with a lookup of the logs generated, scanning the whole file.  This  
commit makes the logic more precise, by scanning the logs only from the  
position before the key queries are run to the position where we check  
for the logs.  This will reduce the risk of issues with log patterns  
overlapping with each other if those tests get more complicated in the  
future.  
  
Per discussion with Tom Lane.  
  
Discussion: https://postgr.es/m/YMP+Gx2S8meYYHW4@paquier.xyz  
Backpatch-through: 13  

commit   : d8e950d3ae7b33a2064a4fb39b7829334b0b47bc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 11 Jun 2021 21:22:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 11 Jun 2021 21:22:21 -0700    

941697c3c1a changed ProcArrayAdd()/Remove() substantially. As reported by  
zhanyi, I missed that due to the introduction of the PGPROC->pgxactoff  
ProcArrayRemove() does not need to search for the position in  
procArray->pgprocnos anymore - that's pgxactoff. Remove the search loop.  
  
The removal of the search loop reduces assertion coverage a bit - but we can  
easily do better than before by adding assertions to other loops over  
pgprocnos elements.  
  
Also do a bit of cleanup, mostly by reducing line lengths by introducing local  
helper variables and adding newlines.  
  
Author: zhanyi <w@hidva.com>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/tencent_5624AA3B116B3D1C31CA9744@qq.com  

commit   : d120e66fac87f768ea2289d2d923d0ee4262ec0f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 21:01:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 21:01:52 -0400    

Reported-by: Justin Pryzby  

commit   : 0725913982e5e06895a32a9eeea2c59a13978927    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 19:51:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 19:51:35 -0400    

commit   : 5cc1cd502879d642da799e1fd12619d83d987369    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 19:07:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 19:07:32 -0400    

We were already reporting it, but only after the parallel workers were  
finished, which is visibly much later than what happens in a serial  
build.  
  
With this change we report it when the leader starts its own sort phase  
when participating in the build (the normal case).  Now this might  
happen a little later than when the workers start their sorting phases,  
but a) communicating the actual phase start from workers is likely to be  
a hassle, and b) the sort phase start is pretty fuzzy anyway, since  
sorting per se is actually initiated by tuplesort.c internally earlier  
than tuplesort_performsort() is called.  
  
Backpatch to pg12, where the progress reporting code for CREATE INDEX  
went in.  
  
Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Reviewed-by: Greg Nancarrow <gregn4422@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/1128176d-1eee-55d4-37ca-e63644422adb  

commit   : ab55d742eb7162c22ee60f1e15e07d2a60063c4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jun 2021 16:12:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jun 2021 16:12:36 -0400    

apply_handle_tuple_routing(), having detected and reported that  
the tuple it needed to update didn't exist, tried to update that  
tuple anyway, leading to a null-pointer dereference.  
  
logicalrep_partition_open() failed to ensure that the  
LogicalRepPartMapEntry it built for a partition was fully  
independent of that for the partition root, leading to  
trouble if the root entry was later freed or rebuilt.  
  
Meanwhile, on the publisher's side, pgoutput_change() sometimes  
attempted to apply execute_attr_map_tuple() to a NULL tuple.  
  
The first of these was reported by Sergey Bernikov in bug #17055;  
I found the other two while developing some test cases for this  
sadly under-tested code.  
  
Diagnosis and patch for the first issue by Amit Langote; patches  
for the others by me; new test cases by me.  Back-patch to v13  
where this logic came in.  
  
Discussion: https://postgr.es/m/17055-9ba800ec8522668b@postgresql.org  

commit   : 4efcf47053eaf8dd88de2b1a89478df43d37d5c0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 16:05:50 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 16:05:50 -0400    

Commit acb7e4eb6b1c added a new implementation for PQsendQuery so that  
it works in pipeline mode (by using extended query protocol), but it  
behaves differently from the 'Q' message (in simple query protocol) used  
by regular implementation: the new one doesn't close the unnamed portal.  
Change the new code to have identical behavior to the old.  
  
Reported-by: Yura Sokolov <y.sokolov@postgrespro.ru>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql  

commit   : 1632ea43682fcea8836ea245771ae85b9e1bcd38    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 15:48:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 15:48:26 -0400    

Per 96540f80f833; the awkward API introduced by c6550776394e is no  
longer needed.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210408020913.zzprrlvqyvlt5cyy@alap3.anarazel.de  

commit   : b676ac443b6a83558d4701b2dd9491c0b37e17c4    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 11 Jun 2021 20:19:48 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 11 Jun 2021 20:19:48 +0200    

Commit b663a41363 introduced bulk inserts for FDW, but the handling of  
tuple slots turned out to be problematic for two reasons. Firstly, the  
slots were re-created for each individual batch. Secondly, all slots  
referenced the same tuple descriptor - with reasonably small batches  
this is not an issue, but with large batches this triggers O(N^2)  
behavior in the resource owner code.  
  
These two issues work against each other - to reduce the number of times  
a slot has to be created/dropped, larger batches are needed. However,  
the larger the batch, the more expensive the resource owner gets. For  
practical batch sizes (100 - 1000) this would not be a big problem, as  
the benefits (latency savings) greatly exceed the resource owner costs.  
But for extremely large batches it might be much worse, possibly even  
losing with non-batching mode.  
  
Fixed by initializing tuple slots only once (and reusing them across  
batches) and by using a new tuple descriptor copy for each slot.  
  
Discussion: https://postgr.es/m/ebbbcc7d-4286-8c28-0272-61b4753af761%40enterprisedb.com  

commit   : 96540f80f8334a3f0f4a13f0d42e4565d8fa9eb7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 12:16:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 12:16:14 -0400    

The code added to mark replication slots invalid in commit c6550776394e  
had the race condition that a slot can be dropped or advanced  
concurrently with checkpointer trying to invalidate it.  Rewrite the  
code to close those races.  
  
The changes to ReplicationSlotAcquire's API added with c6550776394e are  
not necessary anymore.  To avoid an ABI break in released branches, this  
commit leaves that unchanged; it'll be changed in a master-only commit  
separately.  
  
Backpatch to 13, where this code first appeared.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Andres Freund <andres@anarazel.de>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210408001037.wfmk6jud36auhfqm@alap3.anarazel.de  

commit   : d08237b5b494f96e72220bcef36a14a642969f16    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Jun 2021 15:46:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Jun 2021 15:46:18 +0900    

The list of options provided by the tab completion was outdated for the  
following commands:  
- ALTER SUBSCRIPTION  
- CREATE SUBSCRIPTION  
- ALTER PUBLICATION  
- CREATE PUBLICATION  
  
Author: Vignesh C  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALDaNm18oHDFu6SFCHE=ZbiO153Fx7E-L1MG0YyScbaDV--U+A@mail.gmail.com  

commit   : 13a1ca160dcfc316c9f4005891a312f5a84c5ca2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:14 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:14 -0700    

Resolve the disagreement with nodes/*funcs.c field order in favor of the  
latter, which is better-aligned with the IndexStmt field order.  This  
field is new in v14.  
  
Discussion: https://postgr.es/m/20210611045546.GA573364@rfd.leadboat.com  

commit   : d0e750c0acaf31f60667b1635311bcef5ab38bbe    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:13 -0700    

We have a dozen PQset*() functions.  PQresultSetInstanceData() and this  
were the libpq setter functions having a different word order.  Adopt  
the majority word order.  
  
Reviewed by Alvaro Herrera and Robert Haas, though this choice of name  
was not unanimous.  
  
Discussion: https://postgr.es/m/20210605060555.GA216695@rfd.leadboat.com  

commit   : 04539e73faaaaa1c06c1407671910dceaffdfcd4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 11 Jun 2021 13:38:04 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 11 Jun 2021 13:38:04 +1200    

We've accumulated quite a mix of instances of "an SQL" and "a SQL" in the  
documents.  It would be good to be a bit more consistent with these.  
  
The most recent version of the SQL standard I looked at seems to prefer  
"an SQL".  That seems like a good lead to follow, so here we change all  
instances of "a SQL" to become "an SQL".  Most instances correctly use  
"an SQL" already, so it also makes sense to use the dominant variation in  
order to minimise churn.  
  
Additionally, there were some other abbreviations that needed to be  
adjusted. FSM, SSPI, SRF and a few others.  Also fix some pronounceable,  
abbreviations to use "a" instead of "an".  For example, "a SASL" instead  
of "an SASL".  
  
Here I've only adjusted the documents and error messages.  Many others  
still exist in source code comments.  Translator hint comments seem to be  
the biggest culprit.  It currently does not seem worth the churn to change  
these.  
  
Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com  

commit   : e56bce5d43789cce95d099554ae9593ada92b3b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 17:11:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 17:11:36 -0400    

Commit 2453ea142 redefined pg_proc.proargtypes to include the types of  
OUT parameters, for procedures only.  While that had some advantages  
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty  
disastrous from a number of other perspectives.  Notably, since the  
primary key of pg_proc is name + proargtypes, this made it possible to  
have multiple procedures with identical names + input arguments and  
differing output argument types.  That would make it impossible to call  
any one of the procedures by writing just NULL (or "?", or any other  
data-type-free notation) for the output argument(s).  The change also  
seems likely to cause grave confusion for client applications that  
examine pg_proc and expect the traditional definition of proargtypes.  
  
Hence, revert the definition of proargtypes to what it was, and  
undo a number of complications that had been added to support that.  
  
To support the SQL-spec behavior of DROP PROCEDURE, when there are  
no argmode markers in the command's parameter list, we perform the  
lookup both ways (that is, matching against both proargtypes and  
proallargtypes), succeeding if we get just one unique match.  
In principle this could result in ambiguous-function failures  
that would not happen when using only one of the two rules.  
However, overloading of procedure names is thought to be a pretty  
rare usage, so this shouldn't cause many problems in practice.  
Postgres-specific code such as pg_dump can defend against any  
possibility of such failures by being careful to specify argmodes  
for all procedure arguments.  
  
This also fixes a few other bugs in the area of CALL statements  
with named parameters, and improves the documentation a little.  
  
catversion bump forced because the representation of procedures  
with OUT arguments changes.  
  
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us  

commit   : 3a09d75b4f6cabc8331e228b6988dbfcd9afdfbe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 12:27:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 12:27:27 -0400    

It turns out that worker.c's code path for TRUNCATE was also  
careless about establishing a snapshot while executing user-defined  
code, allowing the checks added by commit 84f5c2908 to fail when  
a trigger is fired in that context.  
  
We could just wrap Push/PopActiveSnapshot around the truncate call,  
but it seems better to establish a policy of holding a snapshot  
throughout execution of a replication step.  To help with that and  
possible future requirements, replace the previous ensure_transaction  
calls with pairs of begin/end_replication_step calls.  
  
Per report from Mark Dilger.  Back-patch to v11, like the previous  
changes.  
  
Discussion: https://postgr.es/m/B4A3AF82-79ED-4F4C-A4E5-CD2622098972@enterprisedb.com  

commit   : bb4aed46a5aeb00d2f1d8b8160feed339f4eaf12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 11:15:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 11:15:13 -0400    

Previously, we left the EPQ sub-executor alone until ExecEndLockRows.  
This caused any buffer pins or other resources that it might hold to  
remain held until ExecutorEnd, which in some code paths means that  
they are held till the Portal is closed.  That can cause user-visible  
problems, such as blocking VACUUM; and it's unlike the behavior of  
ordinary table-scanning nodes, which will have released all buffer  
pins by the time they return an EOF indication.  
  
We can make LockRows work more like other plan nodes by calling  
EvalPlanQualEnd just before returning NULL.  We still need to call it  
in ExecEndLockRows in case the node was not run to completion, but in  
the normal case the second call does nothing and costs little.  
  
Per report from Yura Sokolov.  In principle this is a longstanding  
bug, but in view of the lack of other complaints and the low severity  
of the consequences, I chose not to back-patch.  
  
Discussion: https://postgr.es/m/4aa370cb91ecf2f9885d98b80ad1109c@postgrespro.ru  

commit   : 9bb5eecce645dd72853e3ed262bef7bf11cae566    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 10:45:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 10:45:31 -0400    

Buildfarm member hamerkop has been reporting that two cases in  
connect/test5.pgc show different error messages than the test expects,  
because since commit ffa2e4670 libpq's connection failure messages  
are exposing the fact that a GSS-encrypted connection was attempted  
and failed.  That's pretty interesting information in itself, and  
I certainly don't wish to shoot the messenger, but we need to do  
something to stabilize the ECPG results.  
  
For the second of these two failure cases, we can add the  
gssencmode=disable option to prevent the discrepancy.  However,  
that solution is problematic for the first failure, because the only  
unique thing about that case is that it's testing a completely-omitted  
connection target; there's noplace to add the option without defeating  
the point of the test case.  After some thrashing around with  
alternative fixes that turned out to have undesirable side-effects,  
the most workable answer is just to give up and remove that test case.  
Perhaps we can revert this later, if we figure out why the GSS code  
is misbehaving in hamerkop's environment.  
  
Thanks to Michael Paquier for exploration of alternatives.  
  
Discussion: https://postgr.es/m/YLRZH6CWs9N6Pusy@paquier.xyz  

commit   : b29fa951ec519bdde153465e2caa6c0b7b3bcfc3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Jun 2021 16:21:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Jun 2021 16:21:48 +0200    

One of these functions is new in PostgreSQL 14; might as well start it  
out right.  

commit   : 4dcb1d087aebc6fc2477ce4458ea82f548e2c1ee    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:08:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:08:30 -0400    

Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible  
for the WAL segment that the cascading standby needs to be removed  
too quickly. Hopefully this will prevent that.  
  
Kyotaro Horiguchi  
  
Discussion: http://postgr.es/m/20210610.101240.1270925505780628275.horikyota.ntt@gmail.com  

commit   : 55ba5973d9144a552661cf1fa4cbd228a3799212    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 10 Jun 2021 20:13:44 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 10 Jun 2021 20:13:44 +1200    

Discussion: https://postgr.es/m/CAApHDvrbyJNOPBws4RUhXghZ7+TBjtdO-rznTsqZECuowNorXg@mail.gmail.com  

commit   : caba8f0d43fb679c6f9643456080408a6bc370e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:17:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:17:00 -0400    

This only happens if (1) the new standby has no WAL available locally,  
(2) the new standby is starting from the old timeline, (3) the promotion  
happened in the WAL segment from which the new standby is starting,  
(4) the timeline history file for the new timeline is available from  
the archive but the WAL files for are not (i.e. this is a race),  
(5) the WAL files for the new timeline are available via streaming,  
and (6) recovery_target_timeline='latest'.  
  
Commit ee994272ca50f70b53074f0febaec97e28f83c4e introduced this  
logic and was an improvement over the previous code, but it mishandled  
this case. If recovery_target_timeline='latest' and restore_command is  
set, validateRecoveryParameters() can change recoveryTargetTLI to be  
different from receiveTLI. If streaming is then tried afterward,  
expectedTLEs gets initialized with the history of the wrong timeline.  
It's supposed to be a list of entries explaining how to get to the  
target timeline, but in this case it ends up with a list of entries  
explaining how to get to the new standby's original timeline, which  
isn't right.  
  
Dilip Kumar and Robert Haas, reviewed by Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/CAFiTN-sE-jr=LB8jQuxeqikd-Ux+jHiXyh4YDiZMPedgQKup0g@mail.gmail.com  

commit   : 845cad4d51cb12a34ea012dfe58af5ef490384fc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:24:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:24:52 +0900    

The set of subcommands supported by \dAp, \do and \dy was described  
incorrectly in psql's --help.  The documentation was already consistent  
with the code.  
  
Reported-by: inoas, from IRC  
Author: Matthijs van der Vleuten  
Reviewed-by: Neil Chen  
Discussion: https://postgr.es/m/6a984e24-2171-4039-9050-92d55e7b23fe@www.fastmail.com  
Backpatch-through: 9.6  

commit   : be90098907475f3cfff7dc6d590641b9c2dae081    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 18:40:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 18:40:06 -0400    

Further thought about bug #17050 suggests that it's a good idea  
to use CURSOR_OPT_NO_SCROLL for the implicit cursor opened by  
a plpgsql FOR-over-query loop.  This ensures that, if somebody  
commits inside the loop, PersistHoldablePortal won't try to  
rewind and re-read the cursor.  While we'd have selected NO_SCROLL  
anyway if FOR UPDATE/SHARE appears in the query, there are other  
hazards with volatile functions; and in any case, it's silly to  
expend effort storing rows that we know for certain won't be needed.  
  
(While here, improve the comment in exec_run_select, which was a bit  
confused about the rationale for when we can use parallel mode.  
Cursor operations aren't a hazard for nameless portals.)  
  
This wasn't an issue until v11, which introduced the possibility  
of persisting such cursors.  Hence, back-patch to v11.  
  
Per bug #17050 from Алексей Булгаков.  
  
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org  

commit   : ba2c6d6cec000f0aeaeda4d56a23a335f6164860    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 17:50:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 17:50:15 -0400    

PersistHoldablePortal has long assumed that it should store the  
entire output of the query-to-be-persisted, which requires rewinding  
and re-reading the output.  This is problematic if the query is not  
stable: we might get different row contents, or even a different  
number of rows, which'd confuse the cursor state mightily.  
  
In the case where the cursor is NO SCROLL, this is very easy to  
solve: just store the remaining query output, without any rewinding,  
and tweak the portal's cursor state to match.  Aside from removing  
the semantic problem, this could be significantly more efficient  
than storing the whole output.  
  
If the cursor is scrollable, there's not much we can do, but it  
was already the case that scrolling a volatile query's result was  
pretty unsafe.  We can just document more clearly that getting  
correct results from that is not guaranteed.  
  
There are already prohibitions in place on using SCROLL with  
FOR UPDATE/SHARE, which is one way for a SELECT query to have  
non-stable results.  We could imagine prohibiting SCROLL when  
the query contains volatile functions, but that would be  
expensive to enforce.  Moreover, it could break applications  
that work just fine, if they have functions that are in fact  
stable but the user neglected to mark them so.  So settle for  
documenting the hazard.  
  
While this problem has existed in some guise for a long time,  
it got a lot worse in v11, which introduced the possibility  
of persisting plpgsql cursors (perhaps implicit ones) even  
when they violate the rules for what can be marked WITH HOLD.  
Hence, I've chosen to back-patch to v11 but not further.  
  
Per bug #17050 from Алексей Булгаков.  
  
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org  

commit   : 444302ed56273e4c4006a9be319e60fa12a90346    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Jun 2021 16:47:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Jun 2021 16:47:14 -0400    

Protocol v2 was last used in PG 7.3, not 7.2.  
  
Reported-by: Tatsuo Ishii  
  
Discussion: https://postgr.es/m/20210608.091329.906837606658882674.t-ishii@sraoss.co.jp  

commit   : cb92703384e2bb3fa0a690e5dbb95ad333c2b44c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 20:22:18 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 20:22:18 +0200    

The FE/BE protocol identifies parameters with an Int16 index, which  
limits the maximum number of parameters per query to 65535. With  
batching added to postges_fdw this limit is much easier to hit, as  
the whole batch is essentially a single query, making this error much  
easier to hit.  
  
The failures are a bit unpredictable, because it also depends on the  
number of columns in the query. So instead of just failing, this patch  
tweaks the batch_size to not exceed the maximum number of parameters.  
  
Reported-by: Hou Zhijie <houzj.fnst@cn.fujitsu.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://postgr.es/m/OS0PR01MB571603973C0AC2874AD6BF2594299%40OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : d1f0aa7696917213485c03b076b573497a535076    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 19:24:27 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 19:24:27 +0200    

Commit 8e03eb92e9 reverted a bit too much code, reintroducing one of the  
issues fixed by 39b66a91bd - a page might have been left partially empty  
after relcache invalidation.  
  
Reported-By: Tom Lane  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/822752.1623032114@sss.pgh.pa.us  
Discussion: https://postgr.es/m/CAD21AoA%3D%3Df2VSw3c-Cp_y%3DWLKHMKc1D6s7g3YWsCOvgaYPpJcg%40mail.gmail.com  

commit   : bfeede9fa464ab707eb5ac5704742bf78bd7ac9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 11:59:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 11:59:34 -0400    

gram.y should discard NULL pointers (empty statements) when  
assembling a routine_body_stmt_list, as it does for other  
sorts of statement lists.  
  
Julien Rouhaud and Tom Lane, per report from Noah Misch.  
  
Discussion: https://postgr.es/m/20210606044418.GA297923@rfd.leadboat.com  

commit   : 37e1cce4ddf0be362e3093cee55493aee41bc423    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Jun 2021 15:37:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Jun 2021 15:37:54 +0200    

Fix handling of NULL host name (possibly by using hostaddr).  It  
previously crashed.  Also, we should look at connhost, not pghost, to  
handle multi-host specifications.  
  
Also remove an unnecessary SSL_CTX_free().  
  
Reported-by: Jacob Champion <pchampion@vmware.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/504c276ab6eee000bb23d571ea9b0ced4250774e.camel@vmware.com  

commit   : eab81953682d5087295afb911c93f36cb1533bd9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 8 Jun 2021 13:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 8 Jun 2021 13:45:00 +0900    

Add a note about asynchronous execution by postgres_fdw when applied to  
Append nodes that contain synchronous subplan(s) as well.  Follow-up for  
commit 27e1f1456.  
  
Andrey Lepikhov and Etsuro Fujita  
  
Discussion: https://postgr.es/m/58fa2aa5-07f5-80b5-59a1-fec8a349fee7%40postgrespro.ru  

commit   : 4e47b02834827fa700627290fae02f89a450368c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jun 2021 08:53:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jun 2021 08:53:12 +0900    

The use of this function is limited to superusers and the code includes  
a hardcoded check for that.  However, the code would look for the PGPROC  
entry to signal for the memory dump before checking if the user is a  
superuser or not, which does not make sense if we know that an error  
will be returned.  Note that the code would let one know if a process  
was a PostgreSQL process or not even for non-authorized users, which is  
not the case now, but this avoids taking ProcArrayLock that will most  
likely finish by being unnecessary.  
  
Thanks to Julien Rouhaud and Tom Lane for the discussion.  
  
Discussion: https://postgr.es/m/YLxw1uVGIAP5uMPl@paquier.xyz  

commit   : 3bb309be7533e153d86390642e8a2d054bbe82c8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Jun 2021 21:32:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Jun 2021 21:32:53 +0200    

We have outNode() coverage for all path nodes, but this one was  
missed when it was added.  

commit   : d16ebfbff74b30c83a4669a1df318cacfa7e52ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:52:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:52:42 -0400    

If autovacuum comes along just after we fill table test_seg with  
some data, it will update the stats to the point where we prefer  
a plain indexscan over a bitmap scan, breaking the expected  
output (as well as the point of the test case).  To fix, just  
force a bitmap scan to be chosen here.  
  
This has evidently been wrong since commit de1d042f5.  It's not  
clear why we just recently saw any buildfarm failures due to it;  
but prairiedog has failed twice on this test in the past week.  
Hence, backpatch to v11 where this test case came in.  

commit   : 42f94f56bf9559f0a3cf5f3ffde50655834694ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    

An incorrectly-encoded multibyte character near the end of a string  
could cause various processing loops to run past the string's  
terminating NUL, with results ranging from no detectable issue to  
a program crash, depending on what happens to be in the following  
memory.  
  
This isn't an issue in the server, because we take care to verify  
the encoding of strings before doing any interesting processing  
on them.  However, that lack of care leaked into client-side code  
which shouldn't assume that anyone has validated the encoding of  
its input.  
  
Although this is certainly a bug worth fixing, the PG security team  
elected not to regard it as a security issue, primarily because  
any untrusted text should be sanitized by PQescapeLiteral or  
the like before being incorporated into a SQL or psql command.  
(If an app fails to do so, the same technique can be used to  
cause SQL injection, with probably much more dire consequences  
than a mere client-program crash.)  Those functions were already  
made proof against this class of problem, cf CVE-2006-2313.  
  
To fix, invent PQmblenBounded() which is like PQmblen() except it  
won't return more than the number of bytes remaining in the string.  
In HEAD we can make this a new libpq function, as PQmblen() is.  
It seems imprudent to change libpq's API in stable branches though,  
so in the back branches define PQmblenBounded as a macro in the files  
that need it.  (Note that just changing PQmblen's behavior would not  
be a good idea; notably, it would completely break the escaping  
functions' defense against this exact problem.  So we just want a  
version for those callers that don't have any better way of handling  
this issue.)  
  
Per private report from houjingyi.  Back-patch to all supported branches.  

commit   : 68a6d8a87006ba727d9662ec84c7a3d9de402df0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jun 2021 18:12:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jun 2021 18:12:29 +0900    

When run on a server using default_toast_compression set to LZ4, this  
test would fail because of a consistency issue with the order of the  
tuples treated.  LZ4 causes one tuple to be stored inline instead of  
getting externalized.  As the goal of this test is to check after data  
stored externally, stick to pglz as the compression algorithm used, so  
as all data of this test is stored the way it should.  
  
Analyzed-by: Dilip Kumar  
Discussion: https://postgr.es/m/YLrDWxJgM8WWMoCg@paquier.xyz  

commit   : be57f21650d36449ec34a67b2d9af71126a663b3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 7 Jun 2021 09:32:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 7 Jun 2021 09:32:06 +0530    

Commit 19890a064e added the option to enable two_phase commits via  
pg_create_logical_replication_slot but didn't extend the support of same  
in replication protocol. However, by mistake, it added the two_phase  
variable in CreateReplicationSlotCmd which is required only when we extend  
the replication protocol.  
  
Reported-by: Jeff Davis  
Author: Ajin Cherian  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/64b9f783c6e125f18f88fbc0c0234e34e71d8639.camel@j-davis.com  

commit   : f3baaf28a6da588987b94a05a725894805c3eae9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 7 Jun 2021 12:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 7 Jun 2021 12:45:00 +0900    

In cases where run-time pruning isn't required, the synchronous and  
asynchronous subplans for an async-aware Append node determined using  
classify_matching_subplans() should be re-used when rescanning the node,  
but the previous code re-determined them using that function repeatedly  
each time when rescanning the node, leading to incorrect results in a  
normal build and an Assert failure in an Assert-enabled build as that  
function doesn't assume that it's called repeatedly in such cases.  Fix  
the code as mentioned above.  
  
My oversight in commit 27e1f1456.  
  
While at it, initialize async-related pointers/variables to NULL/zero  
explicitly in ExecInitAppend() and ExecReScanAppend(), just to be sure.  
(The variables would have been set to zero before we get to the latter  
function, but let's do so.)  
  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAPmGK16Q4B2_KY%2BJH7rb7wQbw54AUprp7TMekGTd2T1B62yysQ%40mail.gmail.com  

commit   : a65e9f3f1405b786673feec131879843432bf9a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Jun 2021 15:46:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Jun 2021 15:46:58 -0400    

Other equalfuncs.c checks on CoercionForm fields use  
COMPARE_COERCIONFORM_FIELD (which makes them no-ops),  
but commit 40c24bfef neglected to make _equalFuncCall  
do likewise.  Fix that.  
  
This is only strictly correct if FuncCall.funcformat has  
no semantic effect, instead just determining ruleutils.c  
display formatting.  40c24bfef added a couple of checks  
in parse analysis that could break that rule; but on closer  
inspection, they're redundant, so just take them out again.  
  
Per report from Noah Misch.  
  
Discussion: https://postgr.es/m/20210606063331.GC297923@rfd.leadboat.com  

commit   : d57ecebd128cdf2f4844a2ea4d35ff28d7d69be8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 6 Jun 2021 20:52:58 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 6 Jun 2021 20:52:58 +0200    

Commit a4d75c86bf added a new flag, tracking if the statement was  
processed by transformStatsStmt(), but failed to add this flag to  
nodes/*funcs.c.  
  
Catversion bump, due to adding a flag to copy/equal/out functions.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com  

commit   : a2dee328bbe5b1979bbc6a784deb86a336c9cd74    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 6 Jun 2021 00:08:21 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 6 Jun 2021 00:08:21 -0700    

catversion bump due to readfuncs.c field order change.  

commit   : 5c25fd650a774cc4f16ac9c635830d9bc5797f61    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:08:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:08:40 +0200    

Just say that objects that reside in schemas can be schema-qualified.  
Don't list all possible such objects.  The existing lists weren't  
complete anyway.  
  
Discussion: https://www.postgresql.org/message-id/flat/b2ec2234-67fe-d861-5cea-f526cd18c086%40enterprisedb.com  

commit   : 01ddd2f7e411ba434473faebf00f5b5af84c0f64    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:01:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:01:29 +0200    

Use "reside in" rather than "belong to" for objects in a schema.  
Previous use was a mix of the two.  
  
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/202106021932.idmbjjaqk7ke@alvherre.pgsql  

commit   : e6159885b78e9b91b2adc3161c5f827d081f2b13    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:57:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:57:31 +0200    

commit   : 4a682d85a1408e48ac529295c329ba2c17a44724    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    

Starting with Python 3.10, the stacktrace looks differently:  
  -  PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in <module>  
  -    s.__exit__(None, None, None)  
  +  PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module>  
  +    with plpy.subtransaction() as s:  
Using try/except specifically makes the error look always the same.  
  
(See https://github.com/python/cpython/pull/25719 for the discussion  
of this change in Python.)  
  
Author: Honza Horak <hhorak@redhat.com>  
Discussion: https://www.postgresql.org/message-id/flat/853083.1620749597%40sss.pgh.pa.us  
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1959080  

commit   : f61db909dfb94f3411f8719916601a11a905b95e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Jun 2021 20:07:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Jun 2021 20:07:08 -0400    

Commit 86dc90056 expects that FDWs can cope with whole-row Vars for  
their tables, even if the Vars are marked with vartype RECORDOID.  
Previously, whole-row Vars generated by the planner had vartype equal  
to the relevant table's rowtype OID.  (The point behind this change is  
to enable sharing of resjunk columns across inheritance child tables.)  
  
It turns out that postgres_fdw fails to cope with this, though through  
bad fortune none of its test cases exposed that.  Things mostly work,  
but when we try to read back a value of such a Var, the expected  
rowtype is not available to record_in().  Fortunately, it's not  
difficult to hack up the tupdesc that controls this process to  
substitute the foreign table's rowtype for RECORDOID.  Thus we can  
solve the runtime problem while still sharing the resjunk column  
with other tables.  
  
Per report from Alexander Pyhalov.  
  
Discussion: https://postgr.es/m/7817fb9ebd6661cdf9b67dec6e129a78@postgrespro.ru  

commit   : 8f3c06c5d56fc0fa414bcf548860ac50a8fe5982    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 23:39:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 23:39:40 +1200    

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/7838B8EE-CFD6-48D7-AE2D-520D69FD84BD@yesql.se  

commit   : 8bdb36aab287f564eac534878bc0e1d873a4e3db    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 22:42:17 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 22:42:17 +1200    

This tidies up some questionable coding which made use of  
DatumGetPointer() for Datums being passed into functions where the  
parameter is expected to be a cstring.  We saw no compiler warnings with  
the old code as the Pointer type used in DatumGetPointer() happens to  
be a char * rather than a void *.  However, that's no excuse and we should  
be using the correct macro for the job.  
  
Here we also make use of OutputFunctionCall() rather than using  
FunctionCall1() directly to call the type's output function.  
OutputFunctionCall() is the standard way to do this.  It casts the  
returned value to a cstring for us.  
  
In passing get rid of a duplicate call to strlen().  Most compilers will  
likely optimize away the 2nd call, but there may be some that won't.  In  
any case, this just aligns the code to some other nearby code that already  
does this.  
  
Discussion: https://postgr.es/m/CAApHDvq1D=ehZ8hey8Hz67N+_Zth0GHO5wiVCfv1YcGPMXJq0A@mail.gmail.com  

commit   : e4539386decae1c435767a69507cc7cbb11ac3ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 21:07:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 21:07:12 -0400    

The siglen parameter is provided by gist__intbig_ops not  
gist__int_ops.  
  
Simon Norris  
  
Discussion: https://postgr.es/m/11BF2AA9-17AE-432A-AFE1-584FB9FB079D@hillcrestgeo.ca  

commit   : 1e809db86b160e697a56bf47358f7733475840d3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:46:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:46:15 +0900    

This was missing in the section dedicated to the supported environment  
variables of libpq.  Oversight in f5465fa.  
  
Reviewed-by: Daniel Gustafsson, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/YLhI0mLoRkY3u4Wj@paquier.xyz  

commit   : 77e9d1b4884262fa09cd8d141c7eadad3affde8b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:33:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:33:14 +0900    

The link was pointing to the minimum protocol version.  Incorrect as of  
ff8ca5f.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/F893F184-C645-4C21-A2BA-583441B7288F@yesql.se  
Backpatch-through: 13  

commit   : 7fc26d11e370afe237631265714221364d7e7910    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 12:19:50 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 12:19:50 +1200    

A few patches committed after ca3b37487 mistakenly forgot to make the  
copyright year 2021.  Fix these.  
  
Discussion: https://postgr.es/m/CAApHDvqyLmd9P2oBQYJ=DbrV8QwyPRdmXtCTFYPE08h+ip0UJw@mail.gmail.com  

commit   : 11e9caff82bc7326e2bc9782937cb03875050cc4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    

The Msys shell mangles certain patterns in its command line, so avoid  
handing arbitrary SQL to psql on the command line and instead use  
IPC::Run's redirection facility for stdin. This pattern is already  
mostly whats used, but query_poll_until() was not doing the right thing.  
  
Problem discovered on the buildfarm when a new TAP test failed on msys.  

commit   : 3590680b85a8e51ef8df550e5a10dedd0d2dfd88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 14:54:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 14:54:06 -0400    

The documented intent is for all columns except subconninfo to be  
publicly readable.  However, this has been overlooked twice.  
subsynccommit has never been readable since it was introduced,  
nor has the oid column (which is important for joining).  
  
Given the lack of previous complaints, it's not clear that it's  
worth doing anything about this in the back branches.  But there's  
still time to fix it inexpensively for v14.  
  
Per report from Israel Barth (via Euler Taveira).  
  
Patch by Euler Taveira, possibly-vain comment updates by me.  
  
Discussion: https://postgr.es/m/b8f7c17c-0041-46b6-acfe-2d1f5a985ab4@www.fastmail.com  

commit   : 187682c3217375c9b70417bf3235790f639e8e7e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:28:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:28:24 +0900    

The internal SQL queries used by REFRESH MATERIALIZED VIEW CONCURRENTLY  
include some aliases for its diff and temporary relations with  
rather-generic names: diff, newdata, newdata2 and mv.  Depending on the  
queries used for the materialized view, using CONCURRENTLY could lead to  
some internal failures if the matview query and those internal aliases  
conflict.  
  
Those names have been chosen in 841c29c8.  This commit switches instead  
to a naming pattern which is less likely going to cause conflicts, based  
on an idea from Thomas Munro, by appending _$ to those aliases.  This is  
not perfect as those new names could still conflict, but at least it has  
the advantage to keep the code readable and simple while reducing the  
likelihood of conflicts to be close to zero.  
  
Reported-by: Mathis Rudolf  
Author: Bharath Rupireddy  
Reviewed-by: Bernd Helmle, Thomas Munro, Michael Paquier  
Discussion: https://postgr.es/m/109c267a-10d2-3c53-b60e-720fcf44d9e8@credativ.de  
Backpatch-through: 9.6  

commit   : cb3cffe694b6041c1de47b12b225e05f664c7285    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 3 Jun 2021 06:55:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 3 Jun 2021 06:55:04 +0200    

The previous arrangement was just one big list, and the internal order  
was not all consistent either.  Now arrange the options by group and  
sort them, the way it's already done in the --help output and one  
other reference pages.  Also fix some ordering in the --help output.  

commit   : f736e188ce70bda34f04c9f381b7c5141dc20dce    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 3 Jun 2021 16:38:03 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 3 Jun 2021 16:38:03 +1200    

Fix a few places that were using appendStringInfo() when they should have  
been using appendStringInfoString().  Also some cases of  
appendPQExpBuffer() that would have been better suited to use  
appendPQExpBufferChar(), and finally, some places that used  
appendPQExpBuffer() when appendPQExpBufferStr() would have suited better.  
  
There are no bugs are being fixed here.  The aim is just to make the code  
use the most optimal function for the job.  
  
All the code being changed here is new to PG14.  It makes sense to fix  
these before we branch for PG15.  There are a few other places that we  
could fix, but those cases are older code so fixing those seems less  
worthwhile as it may cause unnecessary back-patching pain in the future.  
  
Author: Hou Zhijie  
Discussion: https://postgr.es/m/OS0PR01MB5716732158B1C4142C6FE375943D9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 8279f68a1b13d58a0c9869a60081009d8995e4df    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:50:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:50:56 +0900    

Various environment variables were not getting reset in the TAP tests,  
which would cause failures depending on the tests or the environment  
variables involved.  For example, PGSSL{MAX,MIN}PROTOCOLVERSION could  
cause failures in the SSL tests.  Even worse, a junk value of  
PGCLIENTENCODING makes a server startup fail.  The list of variables  
reset is adjusted in each stable branch depending on what is supported.  
  
While on it, simplify a bit the code per a suggestion from Andrew  
Dunstan, using a list of variables instead of doing single deletions.  
  
Reviewed-by: Andrew Dunstan, Daniel Gustafsson  
Discussion: https://postgr.es/m/YLbjjRpucIeZ78VQ@paquier.xyz  
Backpatch-through: 9.6  

commit   : 2955c2be79b35fa369c83fa3b5f44661cb88afa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 18:50:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 18:50:15 -0400    

Commit 3db826bd5 disallowed this case, but it turns out that some  
people are depending on it.  Since the core grammar has allowed  
it since 3dc37cd8d, it seems like this code should fall in line.  
  
Per bug #17045 from Robert Sosinski.  
  
Discussion: https://postgr.es/m/17045-6a4a9f0d1513f72b@postgresql.org  

commit   : 8e03eb92e9ad54e2f1ed8b5a73617601f6262f81    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 3 Jun 2021 00:06:42 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 3 Jun 2021 00:06:42 +0200    

Reverts most of commit 39b66a91bd, which was found to cause significant  
regression for REFRESH MATERIALIZED VIEW. This means only rows inserted  
by heap_multi_insert will benefit from the optimization, implemented in  
commit 7db0cd2145.  
  
Reported-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoA%3D%3Df2VSw3c-Cp_y%3DWLKHMKc1D6s7g3YWsCOvgaYPpJcg%40mail.gmail.com  

commit   : 889592344c48d3965567f331b4ea89dfe6447bce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 14:38:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 14:38:14 -0400    

Commit 428b260f8 broke planning of cases where row marks are needed  
(SELECT FOR UPDATE, etc) and one of the query's tables is a foreign  
table that has regular table(s) as inheritance children.  We got the  
reverse case right, but apparently were thinking that foreign tables  
couldn't be inheritance parents.  Not so; so we need to be able to  
add a CTID junk column while adding a new child, not only a wholerow  
junk column.  
  
Back-patch to v12 where the faulty code came in.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqEmo3FV1LAQ4TVyS2h1WM=kMkZUmbNuZSCnfHvMcUcPeA@mail.gmail.com  

commit   : 79c50ca57828e9f8375766b36cce1e2960eebf87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 11:52:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 11:52:35 -0400    

The reference here to different physical column numbers in inherited  
UPDATE/DELETE plans is obsolete as of 86dc90056; remove it.  Also  
rework the text about inheritance cases to make it clearer.  

commit   : 9e3b3ff2664dd0b349d2a6d6f047128cb3489cf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 10:44:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 10:44:16 -0400    

Commit c7aba7c14 missed adding SUBSCRIPT here,  
and commit 6df7a9698 missed adding MULTIRANGE_TYPE_NAME.  
  
Haiying Tang and Tom Lane  
  
Discussion: https://postgr.es/m/OS0PR01MB6113F9EDA46FA53BAA5445BDFB3D9@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : df466d30c6caa02e2215595fd83ca70be3199cec    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:20:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:20:15 +0900    

The regression test 013_crash_restart.pl included "use Time::HiRes qw(usleep)",  
but the usleep was not used there.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/63ad1368-18e2-8900-8443-524bdfb1bef5@oss.nttdata.com  

commit   : 6bbc5c5e96b08f6b8c7d28d10ed8dfe6c49dca30    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:19:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:19:39 +0900    

Previously there was no regression test for recovery pause feature.  
This commit adds the test that checks  
  
- recovery can be paused or resumed expectedly  
- pg_get_wal_replay_pause_state() reports the correct pause state  
- the paused state ends and promotion continues if a promotion  
   is triggered while recovery is paused  
  
Suggested-by: Michael Paquier  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Dilip Kumar  
Discussion: https://postgr.es/m/YKNirzqM1HYyk5h4@paquier.xyz  

commit   : 42344ad0ed465ea988d8310d2f413d65329f55a8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:15 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:15 -0700    

commit   : 49527a32ca97761d78efef732a4ac76a2fc086b2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:14 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:14 -0700    

This avoids a warning under MinGW versions having gettimeofday(), per  
buildfarm member walleye.  

commit   : 1103033aedc10295eb689a4b7158f21ef4c14a11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    

This case should be disallowed, just as FOR UPDATE with a plain  
GROUP BY is disallowed; FOR UPDATE only makes sense when each row  
of the query result can be identified with a single table row.  
However, we missed teaching CheckSelectLocking() to check  
groupingSets as well as groupClause, so that it would allow  
degenerate grouping sets.  That resulted in a bad plan and  
a null-pointer dereference in the executor.  
  
Looking around for other instances of the same bug, the only one  
I found was in examine_simple_variable().  That'd just lead to  
silly estimates, but it should be fixed too.  
  
Per private report from Yaoguang Chen.  
Back-patch to all supported branches.  

commit   : eb89cb43a0d0e401e71b8e2345b5f5bc8b2755a1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jun 2021 14:14:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jun 2021 14:14:02 +0530    

Release memory allocated when creating the tuple-conversion map and its  
component TupleDescs when its owning sync entry is invalidated.  
TupleDescs must also be freed when no map is deemed necessary, to begin  
with.  
  
Reported-by: Andres Freund  
Author: Amit Langote  
Reviewed-by: Takamichi Osumi, Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/MEYP282MB166933B1AB02B4FE56E82453B64D9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : a40646e30d85e51a76fb620822d4d921b6802157    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 1 Jun 2021 11:22:22 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 1 Jun 2021 11:22:22 +1200    

Commit 44bf3d50 incorrectly used an errno-style interface when supplying  
missing pthread functionality (i.e. on macOS), but it should check for  
and return error numbers directly.  

commit   : 7c544ecdad814ccda709cfb6aa7d62840c3a7486    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 31 May 2021 18:32:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 31 May 2021 18:32:41 +0200    

The RADIUS-related checks in parse_hba_line() did not respect elevel  
and did not fill in *err_msg.  Also, verify_option_list_length()  
pasted together error messages in an untranslatable way.  To fix the  
latter, remove the function and do the error checking inline.  It's a  
bit more verbose but only minimally longer, and it makes fixing the  
first two issues straightforward.  
  
Reviewed-by: Magnus Hagander <magnus@hagander.net>  
Discussion: https://www.postgresql.org/message-id/flat/8381e425-8c23-99b3-15ec-3115001db1b2%40enterprisedb.com  

commit   : 6ee41a301e70fc8e4ad383bad22d695f66ccb0ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 May 2021 12:03:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 May 2021 12:03:00 -0400    

create_projection_plan contains a hidden assumption (here made  
explicit by an Assert) that a projection-capable Path will yield a  
projection-capable Plan.  Unfortunately, that assumption is violated  
only a few lines away, by create_projection_plan itself.  This means  
that two stacked ProjectionPaths can yield an outcome where we try to  
jam the upper path's tlist into a non-projection-capable child node,  
resulting in an invalid plan.  
  
There isn't any good reason to have stacked ProjectionPaths; indeed the  
whole concept is faulty, since the set of Vars/Aggs/etc needed by the  
upper one wouldn't necessarily be available in the output of the lower  
one, nor could the lower one create such values if they weren't  
available from its input.  Hence, we can fix this by adjusting  
create_projection_path to strip any top-level ProjectionPath from the  
subpath it's given.  (This amounts to saying "oh, we changed our  
minds about what we need to project here".)  
  
The test case added here only fails in v13 and HEAD; before that, we  
don't attempt to shove the Sort into the parallel part of the plan,  
for reasons that aren't entirely clear to me.  However, all the  
directly-related code looks generally the same as far back as v11,  
where the hazard was introduced (by d7c19e62a).  So I've got no faith  
that the same type of bug doesn't exist in v11 and v12, given the  
right test case.  Hence, back-patch the code changes, but not the  
irrelevant test case, into those branches.  
  
Per report from Bas Poot.  
  
Discussion: https://postgr.es/m/534fca83789c4a378c7de379e9067d4f@politie.nl  

commit   : d03eeab886baa1be73f8fc2938fb842d25a71fe8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 31 May 2021 00:29:58 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 31 May 2021 00:29:58 -0700    

Per buildfarm member hornet.  Also, update Pod documentation showing the  
lower value.  Back-patch to v10, where the test first appeared.  

commit   : 12cc956664f159e97be71e33f15ec5f42e46b24e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 31 May 2021 11:35:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 31 May 2021 11:35:00 +0900    

Braces were referred in some error messages as only brackets (not curly  
brackets or curly braces), which can be confusing as other types of  
brackets could be used.  
  
While on it, add one test to check after the case of junk characters  
detected after a right brace.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20210514.153153.1814935914483287479.horikyota.ntt@gmail.com  

commit   : ba356a397de565c014384aa01a945aab7d50928c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 May 2021 14:27:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 May 2021 14:27:37 -0400    

Clarify libpq.sgml's description of service file locations and  
semantics.  Avoid use of backtick'ed pg_config calls to describe  
paths; that doesn't work on Windows, and even on Unix it's an  
idiom that not all readers may be instantly familiar with.  
  
Don't overspecify the locations of include files, instead writing  
only as much as you'd use in #include directives.  The previous text  
in these places was incorrect for some installations, depending on  
where "postgresql" is in the install path.  
  
Our convention for referencing the user's home directory seems  
to be "~", so change the one place that spelled it "$HOME".  
  
install-windows.sgml follows the platform convention of spelling  
file paths with "\", so change the one place that used "/".  
  
Haiying Tang and Tom Lane  
  
Discussion: https://postgr.es/m/162149020918.26174.7150424047314144297@wrigleys.postgresql.org  

commit   : b1d6538903504904db44679355ac109aeda01737    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 29 May 2021 14:48:15 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 29 May 2021 14:48:15 +1200    

Parallel query processes that called BlessTupleDesc() for identical  
tuple descriptors at the same moment could crash.  There was code to  
handle that rare case, but it dereferenced a bogus DSA pointer.  Repair.  
  
Back-patch to 11, where commit cc5f8136 added support for sharing tuple  
descriptors in parallel queries.  
  
Reported-by: Eric Thinnes <e.thinnes@gmx.de>  
Discussion: https://postgr.es/m/99aaa2eb-e194-bf07-c29a-1a76b4f2bcf9%40gmx.de  

commit   : d69fcb9caef1ac1f38241645d4fb9f7e0ce02a70    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:35:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:35:11 -0400    

commit   : fb424ae85f6b1e32e545f13902d3ba3429be44df    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:26:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:26:30 -0400    

This is a long standing omission, discovered when trying to write code  
that relied on it.  
  
Backpatch to all live branches.  

commit   : 9afdea982420f9672b88e5c17d1ee8eec64105fc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 27 May 2021 17:09:16 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 27 May 2021 17:09:16 -0700    

Oversight in commit 5100010e.  

commit   : a4390abecf0f5152cff864e82b67e5f6c8489698    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 15:55:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 15:55:08 -0400    

Commit ab596105b increased FirstBootstrapObjectId from 12000 to 13000,  
but we've had some push-back about that.  It's worrisome to reduce the  
daylight between there and FirstNormalObjectId, because the number of  
OIDs consumed during initdb for collation objects is hard to predict.  
  
We can improve the situation by abandoning the assumption that these  
OIDs must be globally unique.  It should be sufficient for them to be  
unique per-catalog.  (Any code that's unhappy about that is broken  
anyway, since no more than per-catalog uniqueness can be guaranteed  
once the OID counter wraps around.)  With that change, the largest OID  
assigned during genbki.pl (starting from a base of 10000) is a bit  
under 11000.  This allows reverting FirstBootstrapObjectId to 12000  
with reasonable confidence that that will be sufficient for many years  
to come.  
  
We are not, at this time, abandoning the expectation that  
hand-assigned OIDs (below 10000) are globally unique.  Someday that'll  
likely be necessary, but the need seems years away still.  
  
This is late for v14, but it seems worth doing it now so that  
downstream software doesn't have to deal with the consequences of  
a change in FirstBootstrapObjectId.  In any case, we already  
bought into forcing an initdb for beta2, so another catversion  
bump won't hurt.  
  
Discussion: https://postgr.es/m/1665197.1622065382@sss.pgh.pa.us  

commit   : e6241d8e030fbd2746b3ea3f44e728224298f35b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 13:24:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 13:24:24 -0400    

Redefine '\0' (InvalidCompressionMethod) as meaning "if we need to  
compress, use the current setting of default_toast_compression".  
This allows '\0' to be a suitable default choice regardless of  
datatype, greatly simplifying code paths that initialize tupledescs  
and the like.  It seems like a more user-friendly approach as well,  
because now the default compression choice doesn't migrate into table  
definitions, meaning that changing default_toast_compression is  
usually sufficient to flip an installation's behavior; one needn't  
tediously issue per-column ALTER SET COMPRESSION commands.  
  
Along the way, fix a few minor bugs and documentation issues  
with the per-column-compression feature.  Adopt more robust  
APIs for SetIndexStorageProperties and GetAttributeCompression.  
  
Bump catversion because typical contents of attcompression will now  
be different.  We could get away without doing that, but it seems  
better to ensure v14 installations all agree on this.  (We already  
forced initdb for beta2, anyway.)  
  
Discussion: https://postgr.es/m/626613.1621787110@sss.pgh.pa.us  

commit   : a717e5c771610cf8607f2423ab3ab6b5d30f44ea    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 16:40:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 16:40:52 +0200    

The path needs to be set to refer to the build directory, not the  
current directory, because that's actually the source directory at  
that point.  
  
fix for 6abc8c2596dbfcb24f9b4d954a1465b8015118c3  

commit   : 6abc8c2596dbfcb24f9b4d954a1465b8015118c3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 13:58:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 13:58:13 +0200    

Apply in libpq_pipeline test makefile, so that the test file is not  
installed into tmp_install.  
  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/cb9d16a6-760f-cd44-28d6-b091d5fb6ca7%40enterprisedb.com  

commit   : 025110663448a8c877f4b591495f2e5d187d8936    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 20:11:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 20:11:00 +0900    

The deliverables of upstream Kerberos on Windows are installed with  
paths that do not match our MSVC scripts.  First, the include folder was  
named "inc/" in our scripts, but the upstream MSIs use "include/".  
Second, the build would fail with 64-bit environments as the libraries  
are named differently.  
  
This commit adjusts the MSVC scripts to be compatible with the latest  
installations of upstream, and I have checked that the compilation was  
able to work with the 32-bit and 64-bit installations.  
  
Special thanks to Kondo Yuta for the help in investigating the situation  
in hamerkop, which had an incorrect configuration for the GSS  
compilation.  
  
Reported-by: Brian Ye  
Discussion: https://postgr.es/m/162128202219.27274.12616756784952017465@wrigleys.postgresql.org  
Backpatch-through: 9.6  

commit   : 388e75ad33489b77cfb9a8590a91e9287d8fb960    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 09:52:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 09:52:12 +0200    

The error message was checking that the structures returned from the  
parser matched expectations.  That's something we usually use  
assertions for, not a full user-facing error message.  So replace that  
with an assertion (hidden inside lfirst_node()).  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/452e9df8-ec89-e01b-b64a-8cc6ce830458%40enterprisedb.com  

commit   : 2941138e60fc711bd221b3264807f36cc079dfbb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:57:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:57:28 +0900    

The following parameters have been imprecise, or incorrect, about their  
description (PGC_POSTMASTER or PGC_SIGHUP):  
- autovacuum_work_mem (docs, as of 9.6~)  
- huge_page_size (docs, as of 14~)  
- max_logical_replication_workers (docs, as of 10~)  
- max_sync_workers_per_subscription (docs, as of 10~)  
- min_dynamic_shared_memory (docs, as of 14~)  
- recovery_init_sync_method (postgresql.conf.sample, as of 14~)  
- remove_temp_files_after_crash (docs, as of 14~)  
- restart_after_crash (docs, as of 9.6~)  
- ssl_min_protocol_version (docs, as of 12~)  
- ssl_max_protocol_version (docs, as of 12~)  
  
This commit adjusts the description of all these parameters to be more  
consistent with the practice used for the others.  
  
Revewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/YK2ltuLpe+FbRXzA@paquier.xyz  
Backpatch-through: 9.6  

commit   : 6f4bdf81529fdaf6744875b0be99ecb9bfb3b7e0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 May 2021 07:59:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 May 2021 07:59:43 +0530    

While decoding the multi-insert WAL we can't clean the toast untill we get  
the last insert of that WAL record. Now if we stream the changes before we  
get the last change, the memory for toast chunks won't be released and we  
expect the txn to have streamed all changes after streaming.  This  
restriction is mainly to ensure the correctness of streamed transactions  
and it doesn't seem worth uplifting such a restriction just to allow this  
case because anyway we will stream the transaction once such an insert is  
complete.  
  
Previously we were using two different flags (one for toast tuples and  
another for speculative inserts) to indicate partial changes. Now instead  
we replaced both of them with a single flag to indicate partial changes.  
  
Reported-by: Pavan Deolasee  
Author: Dilip Kumar  
Reviewed-by: Pavan Deolasee, Amit Kapila  
Discussion: https://postgr.es/m/CABOikdN-_858zojYN-2tNcHiVTw-nhxPwoQS4quExeweQfG1Ug@mail.gmail.com  

commit   : 190fa5a00a8f9ecee8eef2c8e26136b772b94e19    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 May 2021 19:53:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 May 2021 19:53:03 +0900    

Author: Hou Zhijie  
Discussion: https://postgr.es/m/OS0PR01MB571612191738540B27A8DE5894249@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : eb43bdbf5104c183412aac0fccf8e515e60d9212    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 19:32:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 19:32:22 -0400    

Same as 5e0b1aeb2dfe, for the companion test file.  
  
This one seems lower probability (only two failures in a month of runs);  
I was hardly able to reproduce a failure without a patch, so the fact  
that I was also unable to reproduce one with it doesn't say anything.  
We'll have to wait for further buildfarm results to see if we need any  
further adjustments.  
  
Discussion: https://postgr.es/m/20210524090712.GA3771394@rfd.leadboat.com  

commit   : e30e3fdea873e4e9517c490232ea1d3bcef6c643    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 May 2021 12:55:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 May 2021 12:55:52 -0400    

Commit e717a9a18 introduced a code path that bypassed the call of  
get_expr_result_type, which is not good because we need its rettupdesc  
result to pass to check_sql_fn_retval.  We'd failed to notice right  
away because the code path in which check_sql_fn_retval uses that  
argument is fairly hard to reach in this context.  It's not impossible  
though, and in any case inline_function would have no business  
assuming that check_sql_fn_retval doesn't need that value.  
  
To fix, move get_expr_result_type out of the if-block, which in  
turn requires moving the construction of the dummy FuncExpr  
out of it.  
  
Per report from Ranier Vilela.  (I'm bemused by the lack of any  
compiler complaints...)  
  
Discussion: https://postgr.es/m/CAEudQAqBqQpQ3HruWAGU_7WaMJ7tntpk0T8k_dVtNB46DqdBgw@mail.gmail.com  

commit   : 5e0b1aeb2dfed4f1eb7ac5154c1573885a70db41    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 12:53:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 12:53:29 -0400    

This recently added test has shown to be too sensitive to timing when  
sending a cancel to a session waiting for a lock.  
  
We fix this by running a no-op query in the blocked session immediately  
after the cancel; this avoids the session that sent the cancel sending  
another query immediately before the cancel has been reported.  
Idea by Noah Misch.  
  
With that fix, we sometimes see that the cancel error report is shown  
only relative to the step that is cancelled, instead of together with  
the step that sends the cancel.  To increase the probability that both  
steps are shown togeter, add a 0.1s sleep to the cancel.  In normal  
conditions this appears sufficient to silence most failures, but we'll  
see that the slower buildfarm members say about it.  
  
Reported-by: Takamichi Osumi <osumi.takamichi@fujitsu.com>  
Discussion: https://postgr.es/m/OSBPR01MB4888C4ABA361C7E81094AC66ED269@OSBPR01MB4888.jpnprd01.prod.outlook.com  

commit   : 8673a37c85fef00dd5b9c04197538142bec10542    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 May 2021 11:49:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 May 2021 11:49:54 +0200    

commit   : fb0f5f0172edf9f63c8f70ea9c1ec043b61c770e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 14:27:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 14:27:18 +0900    

VACUUM FULL and CLUSTER can be used to enforce the use of the existing  
compression method of a toastable column if a value currently stored is  
compressed with a method that does not match the column's defined  
method.  The code in charge of decompressing and recompressing toast  
values at rewrite left around the detoasted values, causing an  
accumulation of memory allocated in TopTransactionContext.  
  
When processing large relations, this could cause the system to run out  
of memory.  The detoasted values are not needed once their tuple is  
rewritten, and this commit ensures that the necessary cleanup happens.  
  
Issue introduced by bbe0a81d.  The comments of the area are reordered a  
bit while on it.  
  
Reported-by: Andres Freund  
Analyzed-by: Andres Freund  
Author: Michael Paquier  
Reviewed-by: Dilip Kumar  
Discussion: https://postgr.es/m/20210521211929.pcehg6f23icwstdb@alap3.anarazel.de  

commit   : 0c6b92d9c6fb74255467573fde54f65139b26603    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 10:51:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 10:51:45 +0530    

Add the information of pg_stat_replication_slots view along with other  
system catalogs related to logical decoding.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : 0734b0e983443882ec509ab4501c30ba9b706f5f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 09:26:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 09:26:53 +0530    

The error messages, docs, and one of the options were using  
'parallel degree' to indicate parallelism used by vacuum command. We  
normally use 'parallel workers' at other places so change it for parallel  
vacuum accordingly.  
  
Author: Bharath Rupireddy  
Reviewed-by: Dilip Kumar, Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CALj2ACWz=PYrrFXVsEKb9J1aiX4raA+UBe02hdRp_zqDkrWUiw@mail.gmail.com  

commit   : 01e6f1a842f406170e5f717305e4a6cf0e84b3ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 10:10:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 10:10:09 +0900    

SSL renegotiation is already disabled as of 48d23c72, however this does  
not prevent the server to comply with a client willing to use  
renegotiation.  In the last couple of years, renegotiation had its set  
of security issues and flaws (like the recent CVE-2021-3449), and it  
could be possible to crash the backend with a client attempting  
renegotiation.  
  
This commit takes one extra step by disabling renegotiation in the  
backend in the same way as SSL compression (f9264d15) or tickets  
(97d3a0b0).  OpenSSL 1.1.0h has added an option named  
SSL_OP_NO_RENEGOTIATION able to achieve that.  In older versions  
there is an option called SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS that  
was undocumented, and could be set within the SSL object created when  
the TLS connection opens, but I have decided not to use it, as it feels  
trickier to rely on, and it is not official.  Note that this option is  
not usable in OpenSSL < 1.1.0h as the internal contents of the *SSL  
object are hidden to applications.  
  
SSL renegotiation concerns protocols up to TLSv1.2.  
  
Per original report from Robert Haas, with a patch based on a suggestion  
by Andres Freund.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/YKZBXx7RhU74FlTE@paquier.xyz  
Backpatch-through: 9.6  

commit   : cba5c70b956810c61b3778f7041f92fbb8065acb    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 25 May 2021 12:50:22 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 25 May 2021 12:50:22 +1200    

Result Cache, added in 9eacee2e6 neglected to properly adjust the plan  
references in setrefs.c.  This could lead to the following error during  
EXPLAIN:  
  
ERROR:  cannot decompile join alias var in plan tree  
  
Fix that.  
  
Bug: 17030  
Reported-by: Hans Buschmann  
Discussion: https://postgr.es/m/17030-5844aecae42fe223@postgresql.org  

commit   : c242baa4a831ac2e7dcaec85feb410aefa3a996e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 May 2021 17:14:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 May 2021 17:14:02 -0700    

The wraparound failsafe mechanism added by commit 1e55e7d1 handled the  
one-pass strategy case (i.e. the "table has no indexes" case) by adding  
a dedicated failsafe check.  This made up for the fact that the usual  
one-pass checks inside lazy_vacuum_all_indexes() cannot ever be reached  
during a one-pass strategy VACUUM.  
  
This approach failed to account for two-pass VACUUMs that opt out of  
index vacuuming up-front.  The INDEX_CLEANUP off case in the only case  
that works like that.  
  
Fix this by performing a failsafe check every 4GB during the first scan  
of the heap, regardless of the details of the VACUUM.  This eliminates  
the special case, and will make the failsafe trigger more reliably.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Andres Freund <andres@anarazel.de>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/20210424002921.pb3t7h6frupdqnkp@alap3.anarazel.de  

commit   : 713a431c781fbfe1a22fae4991836077f0f4c513    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 May 2021 18:03:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 May 2021 18:03:47 -0400    

pg_statistic_ext_data.stxdexpr was listed under the wrong catalog,  
as was pg_stats_ext.exprs.  Also there was a bogus entry for  
pg_statistic_ext_data.stxexprs.  Apparently a merge failure in  
commit a4d75c86b.  
  
Guillaume Lelarge and Tom Lane  
  
Discussion: https://postgr.es/m/CAECtzeUHw+w64eUFVeV_2FJviAw6oZ0wNLkmU843ZH4hAQfiWg@mail.gmail.com  

commit   : 99c5852e20a0987eca1c38ba0c09329d4076b6a0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 24 May 2021 12:37:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 24 May 2021 12:37:11 +1200    

Code added in 9e215378d to disable building of Result Cache paths when  
not all join conditions are part of the parameterization of a unique  
join failed to first check if the inner path's param_info was set before  
checking the param_info's ppi_clauses.  
  
Add a check for NULL values here and just bail on trying to build the  
path if param_info is NULL. lateral_vars are not considered when  
deciding if the join is unique, so we're not missing out on doing the  
optimization when there are lateral_vars and no param_info.  
  
Reported-by: Coverity, via Tom Lane  
Discussion: https://postgr.es/m/457998.1621779290@sss.pgh.pa.us  

commit   : f5024d8d7b04de2f5f4742ab433cc38160354861    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 12:12:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 12:12:09 -0400    

Now that attcompression is just a char, there's a lot of wasted  
padding space after it.  Move it into the group of char-wide  
columns to save a net of 4 bytes per pg_attribute entry.  While  
we're at it, swap the order of attstorage and attalign to make for  
a more logical grouping of these columns.  
  
Also re-order actions in related code to match the new field ordering.  
  
This patch also fixes one outright bug: equalTupleDescs() failed to  
compare attcompression.  That could, for example, cause relcache  
reload to fail to adopt a new value following a change.  
  
Michael Paquier and Tom Lane, per a gripe from Andres Freund.  
  
Discussion: https://postgr.es/m/20210517204803.iyk5wwvwgtjcmc5w@alap3.anarazel.de  

commit   : bc2a389efb3b52d259cefd53c16cfa00742116f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 10:50:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 10:50:21 -0400    

Emit a LOG message when the postmaster stops because of a failure in  
the startup process.  There already is a similar message if we exit  
for that reason during PM_STARTUP phase, so it seems inconsistent  
that there was none if the startup process fails later on.  
  
Also emit a LOG message when the postmaster stops after a crash  
because restart_after_crash is disabled.  This seems potentially  
helpful in case DBAs (or developers) forget that that's set.  
Also, it was the only remaining place where the postmaster would  
do an abnormal exit without any comment as to why.  
  
In passing, remove an unreachable call of ExitPostmaster(0).  
  
Discussion: https://postgr.es/m/194914.1621641288@sss.pgh.pa.us  

commit   : 8f73ed6b659464274eb9cc8358588b569960d0be    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 22:25:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 22:25:05 -0400    

commit   : b39630fd41f25b414d0ea9b30804f4105f2a0aff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 21:24:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 21:24:48 -0400    

If we redirected a replicated tuple operation into a partition child  
table, and then tried to fire AFTER triggers for that event, the  
relation cache entry for the child table was already closed.  This has  
no visible ill effects as long as the entry is still there and still  
valid, but an unluckily-timed cache flush could result in a crash or  
other misbehavior.  
  
To fix, postpone the ExecCleanupTupleRouting call (which is what  
closes the child table) until after we've fired triggers.  This  
requires a bit of refactoring so that the cleanup function can  
have access to the necessary state.  
  
In HEAD, I took the opportunity to simplify some of worker.c's  
function APIs based on use of the new ApplyExecutionData struct.  
However, it doesn't seem safe/practical to back-patch that aspect,  
at least not without a lot of analysis of possible interactions  
with a04daa97a.  
  
In passing, add an Assert to afterTriggerInvokeEvents to catch  
such cases.  This seems worthwhile because we've grown a number  
of fairly unstructured ways of calling AfterTriggerEndQuery.  
  
Back-patch to v13, where worker.c grew the ability to deal with  
partitioned target tables.  
  
Discussion: https://postgr.es/m/3382681.1621381328@sss.pgh.pa.us  

commit   : 7ce7d07e1c5fb33ee56bda235ae3d53f162f3bc0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 20:17:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 20:17:58 -0400    

Reported-by: Stephen Frost  
  
Discussion: https://postgr.es/m/20210522232945.GO20766@tamriel.snowman.net  

commit   : 8dcae7f0a3d6aba1afad1599ab18d259c417b4ee    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 19:24:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 19:24:23 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-WzmgSnDX9WVoxRZxuKeCy2MzLO9Dmo4+go0RzNW0VBdhmw@mail.gmail.com  

commit   : 30168be8f75b95183abccf48f0da7a64a0cfbd9f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 10:25:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 10:25:36 -0400    

In the wake of 84f5c2908, it's no longer necessary for plpgsql to  
handle SET/RESET specially.  The point of that was just to avoid  
taking a new transaction snapshot prematurely, which the regular code  
path through _SPI_execute_plan() now does just fine (in fact better,  
since it now does the right thing for LOCK too).  Hence, rip out a  
few lines of code, going back to the old way of treating SET/RESET  
as a generic SQL command.  This essentially reverts all but the  
test cases from b981275b6.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : 9e215378d7fbb7d4615be917917c52f246cc6c61    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 22 May 2021 16:22:27 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 22 May 2021 16:22:27 +1200    

When the planner considered using a Result Cache node to cache results  
from the inner side of a Nested Loop Join, it failed to consider that the  
inner path's parameterization may not be the entire join condition.  If  
the join was marked as inner_unique then we may accidentally put the cache  
in singlerow mode.  This meant that entries would be marked as complete  
after caching the first row.  That was wrong as if only part of the join  
condition was parameterized then the uniqueness of the unique join was not  
guaranteed at the Result Cache's level.  The uniqueness is only guaranteed  
after Nested Loop applies the join filter.  If subsequent rows were found,  
this would lead to:  
  
ERROR: cache entry already complete  
  
This could have been fixed by only putting the cache in singlerow mode if  
the entire join condition was parameterized.  However, Nested Loop will  
only read its inner side so far as the first matching row when the join is  
unique, so that might mean we never get an opportunity to mark cache  
entries as complete.  Since non-complete cache entries are useless for  
subsequent lookups, we just don't bother considering a Result Cache path  
in this case.  
  
In passing, remove the XXX comment that claimed the above ERROR might be  
better suited to be an Assert.  After there being an actual case which  
triggered it, it seems better to keep it an ERROR.  
  
Reported-by: David Christensen  
Discussion: https://postgr.es/m/CAOxo6X+dy-V58iEPFgst8ahPKEU+38NZzUuc+a7wDBZd4TrHMQ@mail.gmail.com  

commit   : 0cdaa05b40e9f28e5d6d58ccd06fe19f3cd920c9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 20:51:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 20:51:53 -0400    

commit   : 55370f8db96c8416940ad0b05be7a00a9f059a9f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 16:16:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 16:16:56 -0400    

commit   : 4b10074453d182b5fc11a5667bab2ef8532ff3a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:12:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:12:08 -0400    

This was previously allowed, but I think that was just an oversight.  
It's a clear violation of the rule that a generated column cannot  
depend on itself or other generated columns.  Moreover, because the  
code was relying on the assumption that no such cross-references  
exist, it was pretty easy to crash ALTER TABLE and perhaps other  
places.  Even if you managed not to crash, you got quite unstable,  
implementation-dependent results.  
  
Per report from Vitaly Ustinov.  
Back-patch to v12 where GENERATED came in.  
  
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com  

commit   : 2b0ee126bbf01cbfd657bd53c94f9284ba903ca2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:02:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:02:06 -0400    

We consider this supported (though I've got my doubts that it's a  
good idea, because tableoid is not immutable).  However, several  
code paths failed to fill the field in soon enough, causing such  
a GENERATED expression to see zero or the wrong value.  This  
occurred when ALTER TABLE adds a new GENERATED column to a table  
with existing rows, and during regular INSERT or UPDATE on a  
foreign table with GENERATED columns.  
  
Noted during investigation of a report from Vitaly Ustinov.  
Back-patch to v12 where GENERATED came in.  
  
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com  

commit   : 84f5c2908dad81e8622b0406beea580e40bb03ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 14:03:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 14:03:53 -0400    

COMMIT/ROLLBACK necessarily destroys all snapshots within the session.  
The original implementation of intra-procedure transactions just  
cavalierly did that, ignoring the fact that this left us executing in  
a rather different environment than normal.  In particular, it turns  
out that handling of toasted datums depends rather critically on there  
being an outer ActiveSnapshot: otherwise, when SPI or the core  
executor pop whatever snapshot they used and return, it's unsafe to  
dereference any toasted datums that may appear in the query result.  
It's possible to demonstrate "no known snapshots" and "missing chunk  
number N for toast value" errors as a result of this oversight.  
  
Historically this outer snapshot has been held by the Portal code,  
and that seems like a good plan to preserve.  So add infrastructure  
to pquery.c to allow re-establishing the Portal-owned snapshot if it's  
not there anymore, and add enough bookkeeping support that we can tell  
whether it is or not.  
  
We can't, however, just re-establish the Portal snapshot as part of  
COMMIT/ROLLBACK.  As in normal transaction start, acquiring the first  
snapshot should wait until after SET and LOCK commands.  Hence, teach  
spi.c about doing this at the right time.  (Note that this patch  
doesn't fix the problem for any PLs that try to run intra-procedure  
transactions without using SPI to execute SQL commands.)  
  
This makes SPI's no_snapshots parameter rather a misnomer, so in HEAD,  
rename that to allow_nonatomic.  
  
replication/logical/worker.c also needs some fixes, because it wasn't  
careful to hold a snapshot open around AFTER trigger execution.  
That code doesn't use a Portal, which I suspect someday we're gonna  
have to fix.  But for now, just rearrange the order of operations.  
This includes back-patching the recent addition of finish_estate()  
to centralize the cleanup logic there.  
  
This also back-patches commit 2ecfeda3e into v13, to improve the  
test coverage for worker.c (it was that test that exposed that  
worker.c's snapshot management is wrong).  
  
Per bug #15990 from Andreas Wicht.  Back-patch to v11 where  
intra-procedure COMMIT was added.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : 124966c1a35b950210e12048e64533963960febd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 May 2021 17:10:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 May 2021 17:10:09 +0200    

commit   : 6d0eb38557155855539cd007f04736dc3b2ba16f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 May 2021 07:54:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 May 2021 07:54:27 +0530    

While applying the truncate change, the logical apply worker acquires  
RowExclusiveLock on the relation being truncated. This allowed truncate on  
the relation at a time by two apply workers which lead to a deadlock. The  
reason was that one of the workers after updating the pg_class tuple tries  
to acquire SHARE lock on the relation and started to wait for the second  
worker which has acquired RowExclusiveLock on the relation. And when the  
second worker tries to update the pg_class tuple, it starts to wait for  
the first worker which leads to a deadlock. Fix it by acquiring  
AccessExclusiveLock on the relation before applying the truncate change as  
we do for normal truncate operation.  
  
Author: Peter Smith, test case by Haiying Tang  
Reviewed-by: Dilip Kumar, Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAHut+PsNm43p0jM+idTvWwiGZPcP0hGrHMPK9TOAkc+a4UpUqw@mail.gmail.com  

commit   : f21fadafaf0fb5ea4c9622d915972651273d62ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 18:32:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 18:32:37 -0400    

exec_for_query() normally tries to prefetch a few rows at a time  
from the query being iterated over, so as to reduce executor  
entry/exit overhead.  Unfortunately this is unsafe if we have  
COMMIT or ROLLBACK within the loop, because there might be  
TOAST references in the data that we prefetched but haven't  
yet examined.  Immediately after the COMMIT/ROLLBACK, we have  
no snapshots in the session, meaning that VACUUM is at liberty  
to remove recently-deleted TOAST rows.  
  
This was originally reported as a case triggering the "no known  
snapshots" error in init_toast_snapshot(), but even if you miss  
hitting that, you can get "missing toast chunk", as illustrated  
by the added isolation test case.  
  
To fix, just disable prefetching in non-atomic contexts.  Maybe  
there will be performance complaints prompting us to work harder  
later, but it's not clear at the moment that this really costs  
much, and I doubt we'd want to back-patch any complicated fix.  
  
In passing, adjust that error message in init_toast_snapshot()  
to be a little clearer about the likely cause of the problem.  
  
Patch by me, based on earlier investigation by Konstantin Knizhnik.  
  
Per bug #15990 from Andreas Wicht.  Back-patch to v11 where  
intra-procedure COMMIT was added.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : 4f586fe244a296d7c781de3f06c54755f2ae222b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 20 May 2021 15:50:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 20 May 2021 15:50:46 -0400    

commit   : bdbb2ce7d51e93ca2ec68e25e2fafb271b34e72d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 15:11:17 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 15:11:17 -0400    

A lamentable oversight on my part meant that when PostgresVersion.pm was  
added in commit 4c4eaf3d19 provision to install it was not added to the  
Makefile, so it was not installed along with the other perl modules.  

commit   : 6d59a218c38adf5b993200a804713df4982a0c75    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 13:03:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 13:03:08 -0400    

"typename" is a C++ keyword, so pg_upgrade.h fails to compile in C++.  
Fortunately, there seems no likely reason for somebody to need to  
do that.  Nonetheless, it's project policy that all .h files should  
pass cpluspluscheck, so rename the argument to fix that.  
  
Oversight in 57c081de0; back-patch as that was.  (The policy requiring  
pg_upgrade.h to pass cpluspluscheck only goes back to v12, but it  
seems best to keep this code looking the same in all branches.)  

commit   : 8bdd6f563aa2456de602e78991e6a9f61b8ec86d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 08:03:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 08:03:15 -0400    

Older versions of perl on Windows don't like the list form of pipe open,  
and perlcritic doesn't like the string form of open, so we avoid both  
with a simpler formulation using qx{}.  
  
Per complaint from Amit Kapila.  

commit   : 413c1ef98e0c9c708c4a9a13a838a55b65b16a80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 May 2021 14:04:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 May 2021 14:04:01 -0400    

Recently we refactored things so that pg_regress makes the  
"testtablespace" subdirectory used by the core regression tests,  
instead of doing that in the makefiles.  That had the undesirable  
side effect of making such a subdirectory in every directory that  
has "input" or "output" test files.  Since these subdirectories  
remain empty, git doesn't complain about them, but nonetheless  
they're clutter.  
  
To fix, invent an explicit --make-testtablespace-dir switch,  
so that pg_regress only makes the subdirectory when explicitly  
told to.  
  
Discussion: https://postgr.es/m/2854388.1621284789@sss.pgh.pa.us  

commit   : 4f7d1c30966cc02fd5eba2f0d51d1f53be07d457    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:22:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:22:21 -0400    

Fix PG 14 relnotes to use <link> instead of <xref>.  This was discussed  
in commit message 59fa7eb603.  

commit   : 1e7d53bd019e9d86ef1013308715622a2e400d3b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:01:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:01:28 -0400    

commit   : 0f516d039d8023163e82fa51104052306068dd69    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 19 May 2021 12:50:58 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 19 May 2021 12:50:58 +0100    

One of the tests for the pgbench permute() function added by  
6b258e3d68 fails on some 32-bit platforms, due to variations in the  
floating point computations in getrand(). The remaining tests give  
sufficient coverage, so just remove the failing test.  
  
Reported by Christoph Berg. Analysis by Thomas Munro and Tom Lane.  
Based on patch by Fabien Coelho.  
  
Discussion: https://postgr.es/m/YKQnUoYV63GRJBDD@msg.df7cb.de  

commit   : 167bd4804995afd654bd97ca9486acbece24377e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 13:48:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 13:48:19 +0900    

If a promotion is triggered while recovery is paused, the paused state ends  
and promotion continues. But previously in that case  
pg_get_wal_replay_pause_state() returned 'paused' wrongly while a promotion  
was ongoing.  
  
This commit changes a standby promotion so that it marks the recovery  
pause state as 'not paused' when it's triggered, to fix the issue.  
  
Author: Fujii Masao  
Reviewed-by: Dilip Kumar, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/f706876c-4894-0ba5-6f4d-79803eeea21b@oss.nttdata.com  

commit   : 0a442a408b40d2c6710de7e5397cb2e769d8c630    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 19 May 2021 08:54:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 19 May 2021 08:54:46 +0530    

We were not waiting for a publisher to catch up with the subscriber after  
creating a subscription. Now, it can happen that apply worker starts  
replication even after we have disabled the subscription in the test. This  
will make the test expect that there is no active slot whereas there  
exists one. Fix this symptom by allowing the publisher to wait for  
catching up with the subscription.  
  
It is not a good idea to ensure if the slot is still active by checking  
for walsender existence as we release the slot after we clean up the  
walsender related memory. Fix that by checking the slot status in  
pg_replication_slots.  
  
Also, it is better to avoid repeated enabling/disabling of the  
subscription.  
  
Finally, we make autovacuum off for this test to avoid any empty  
transaction appearing in the test while consuming changes.  
  
Reported-by: as per buildfarm  
Author: Vignesh C  
Reviewed-by: Amit Kapila, Michael Paquier  
Discussion: https://postgr.es/m/CAA4eK1+uW1UGDHDz-HWMHMen76mKP7NJebOTZN4uwbyMjaYVww@mail.gmail.com  

commit   : 6a5bde7d4f96ef153578eaeb624ae12e48b46e85    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 23:21:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 23:21:47 -0400    

commit   : d8735b8b4651f5ed50afc472e236a8e6120f07f2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 11:38:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 11:38:34 +0900    

1) Previously there were both pgstat_send_wal() and pgstat_report_wal()  
   in order to send WAL activity to the stats collector. With the former being  
   used by wal writer, the latter by most other processes. They were a bit  
   redundant and so this commit merges them into pgstat_send_wal() to  
   simplify the code.  
  
2) Previously WAL global statistics counters were calculated and then  
   compared with zero-filled buffer in order to determine whether any WAL  
   activity has happened since the last submission. These calculation and  
   comparison were not cheap. This was regularly exercised even in read-only  
   workloads. This commit fixes the issue by making some WAL activity  
   counters directly be checked to determine if there's WAL activity stats  
   to send.  
  
3) Previously pgstat_report_stat() did not check if there's WAL activity  
   stats to send as part of the "Don't expend a clock check if nothing to do"  
   check at the top. It's probably rare to have pending WAL stats without  
   also passing one of the other conditions, but for safely this commit  
   changes pgstat_report_stats() so that it checks also some WAL activity  
   counters at the top.  
  
This commit also adds the comments about the design of WAL stats.  
  
Reported-by: Andres Freund  
Author: Masahiro Ikeda  
Reviewed-by: Kyotaro Horiguchi, Atsushi Torikoshi, Andres Freund, Fujii Masao  
Discussion: https://postgr.es/m/20210324232224.vrfiij2rxxwqqjjb@alap3.anarazel.de  

commit   : 694da1983e9569b2a2f96cd786ead6b8dba31f1d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 May 2021 09:38:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 May 2021 09:38:48 +0900    

This is an oversight from bbe0a81d, where the equivalent option exists  
in pg_dump.  This is useful to be able to reset the compression methods  
cluster-wide when restoring the data based on default_toast_compression.  
  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/YKHC+qCJvzCRVCpY@paquier.xyz  

commit   : 2e7c17837064297f25c427d58154dce8d4287302    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 15:17:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 15:17:44 -0400    

commit   : 2ded19fa3a4dafbae80245710fa371d5163bdad4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:54:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:54:56 +1200    

README.barrier didn't seem to get the memo when atomics were added. Fix  
that.  
  
Author: Tatsuo Ishii, David Rowley  
Discussion: https://postgr.es/m/20210516.211133.2159010194908437625.t-ishii%40sraoss.co.jp  
Backpatch-through: 9.6, oldest supported release  

commit   : e4f9737fac77a5cb03a84d1f4038d300ffd28afd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 May 2021 16:11:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 May 2021 16:11:18 -0400    

commit   : cff8436f19e1c0c278f1ee96d450507fbd43f9ef    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 17 May 2021 21:54:36 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 17 May 2021 21:54:36 +0200    

We used to distribute a binary version of flex for windows on our  
download site, but it hasn't been working for many years. The "old  
documentation" referenced was also for versions that have been EOL for  
many years. So, remove it.  
  
Discussion: https://postgr.es/m/CABUevEwXLJpVpab62f7AFXNWQ5=U0kvErCLq4VEsikidLyzSQg@mail.gmail.com  

commit   : fe2fb9ebcae8445fdb3915ecf8402a3a887effc2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 May 2021 14:05:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 May 2021 14:05:05 -0400    

commit   : 6292b83074243db94df89271842bda0877cbc4ce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 May 2021 14:30:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 May 2021 14:30:27 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 9bbd9c3714d0c76daaa806588b1fbf744aa60496  

commit   : f9e6d00df029144fd8f4ec70c52b5a1d2444f895    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 17 May 2021 10:59:54 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 17 May 2021 10:59:54 +0200    

Incorrect wording got applied in 7531fcb1fcf.  
  
Reported-By: Fujii Masao  
Discussion: https://postgr.es/m/e5512912-eac9-b163-df2b-e2601ce06d27@oss.nttdata.com  

commit   : 15fcd33e0694428d0567a6796891b759bc91e6f9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 17 May 2021 17:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 17 May 2021 17:30:00 +0900    

Add a note of caution on the performance of asynchronous execution by  
postgres_fdw.  Follow-up for commit 27e1f1456.  
  
Stephen Frost, a little bit expanded by me.  
  
Discussion: https://postgr.es/m/20210506171224.GV20766%40tamriel.snowman.net  

commit   : 07af57dbad589bbef9d7178d9b1cb354412e823f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 16 May 2021 23:34:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 16 May 2021 23:34:50 -0400    

commit   : f39b21e6a25c7269f50a709aa874e321e6f84b20    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 15 May 2021 17:30:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 15 May 2021 17:30:45 -0400    

commit   : 6cb5346cb15d56e6ba8288b891c7098f0aecdadc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 15 May 2021 17:26:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 15 May 2021 17:26:26 -0400    

Also remove ALTER TYPE ...SUBSCRIPT, and update for all current commits.  

commit   : 354f32d01dedc2c86a05be298a62cdae9710d203    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 15 May 2021 15:17:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 15 May 2021 15:17:15 -0400    

Per buildfarm  

commit   : cafde58b337e007cb6a719f5ab4dd6459d932a39    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 15 May 2021 14:13:09 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 15 May 2021 14:13:09 -0400    

Allowing only on/off meant that all either all existing configuration  
guides would become obsolete if we disabled it by default, or that we  
would have to accept a performance loss in the default config if we  
enabled it by default.  By allowing 'auto' as a middle ground, the  
performance cost is only paid by those who enable pg_stat_statements and  
similar modules.  
  
I only edited the release notes to comment-out a paragraph that is now  
factually wrong; further edits are probably needed to describe the  
related change in more detail.  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20210513002623.eugftm4nk2lvvks3@nol  

commit   : 30d8bad494ad1f604295033e4f4de4b8f258fe74    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 May 2021 12:21:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 May 2021 12:21:06 -0400    

ForgetBackgroundWorker lacked any memory barrier at all, while  
BackgroundWorkerStateChange had one but unaccountably did  
additional manipulation of the slot after the barrier.  AFAICS,  
the rule must be that the barrier is immediately before setting  
or clearing slot->in_use.  
  
It looks like back in 9.6 when ForgetBackgroundWorker was first  
written, there might have been some case for not needing a  
barrier there, but I'm not very convinced of that --- the fact  
that the load of bgw_notify_pid is in the caller doesn't seem  
to guarantee no memory ordering problem.  So patch 9.6 too.  
  
It's likely that this doesn't fix any observable bug on Intel  
hardware, but machines with weaker memory ordering rules could  
have problems here.  
  
Discussion: https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us  

commit   : 8f72bbac3e4b1d1be9598e8edb9353fa5dc48138    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 14 May 2021 15:08:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 14 May 2021 15:08:02 -0700    

Add a defensive "can't happen" error to code that handles nbtree posting  
list splits (promote an existing assertion).  This avoids a segfault in  
the event of an insertion of a newitem that is somehow identical to an  
existing non-pivot tuple in the index.  An nbtree index should never  
have two index tuples with identical TIDs.  
  
This scenario is not particular unlikely in the event of any kind of  
corruption that leaves the index in an inconsistent state relative to  
the heap relation that is indexed.  There are two known reports of  
preventable hard crashes.  Doing nothing seems unacceptable given the  
general expectation that nbtree will cope reasonably well with corrupt  
data.  
  
Discussion: https://postgr.es/m/CAH2-Wz=Jr_d-dOYEEmwz0-ifojVNWho01eAqewfQXgKfoe114w@mail.gmail.com  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : c3c35a733c77b298d3cf7e7de2eeb4aea540a631    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 15:07:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 15:07:34 -0400    

Formerly we just relied on operator classes that assert longValuesOK  
to eventually shorten the leaf value enough to fit on an index page.  
That fails since the introduction of INCLUDE-column support (commit  
09c1c6ab4), because the INCLUDE columns might alone take up more  
than a page, meaning no amount of leaf-datum compaction will get  
the job done.  At least with spgtextproc.c, that leads to an infinite  
loop, since spgtextproc.c won't throw an error for not being able  
to shorten the leaf datum anymore.  
  
To fix without breaking cases that would otherwise work, add logic  
to spgdoinsert() to verify that the leaf tuple size is decreasing  
after each "choose" step.  Some opclasses might not decrease the  
size on every single cycle, and in any case, alignment roundoff  
of the tuple size could obscure small gains.  Therefore, allow  
up to 10 cycles without additional savings before throwing an  
error.  (Perhaps this number will need adjustment, but it seems  
quite generous right now.)  
  
As long as we've developed this logic, let's back-patch it.  
The back branches don't have INCLUDE columns to worry about, but  
this seems like a good defense against possible bugs in operator  
classes.  We already know that an infinite loop here is pretty  
unpleasant, so having a defense seems to outweigh the risk of  
breaking things.  (Note that spgtextproc.c is actually the only  
known opclass with longValuesOK support, so that this is all moot  
for known non-core opclasses anyway.)  
  
Per report from Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com  

commit   : eb7a6b9229432dcb791f4bf0c44fe97bab661134    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 13:26:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 13:26:55 -0400    

Knowing that a buggy opclass could cause an infinite insertion loop,  
spgdoinsert() intended to allow its loop to be interrupted by query  
cancel.  However, that never actually worked, because in iterations  
after the first, we'd be holding buffer lock(s) which would cause  
InterruptHoldoffCount to be positive, preventing servicing of the  
interrupt.  
  
To fix, check if an interrupt is pending, and if so fall out of  
the insertion loop and service the interrupt after we've released  
the buffers.  If it was indeed a query cancel, that's the end of  
the matter.  If it was a non-canceling interrupt reason, make use  
of the existing provision to retry the whole insertion.  (This isn't  
as wasteful as it might seem, since any upper-level index tuples we  
already created should be usable in the next attempt.)  
  
While there's no known instance of such a bug in existing release  
branches, it still seems like a good idea to back-patch this to  
all supported branches, since the behavior is fairly nasty if a  
loop does happen --- not only is it uncancelable, but it will  
quickly consume memory to the point of an OOM failure.  In any  
case, this code is certainly not working as intended.  
  
Per report from Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com  

commit   : e47f93f981ccb70b4c4c5a0966e5fa0400e11a7e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 12:54:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 12:54:26 -0400    

Split up CHECK_FOR_INTERRUPTS() to provide an additional macro  
INTERRUPTS_PENDING_CONDITION(), which just tests whether an  
interrupt is pending without attempting to service it.  This is  
useful in situations where the caller knows that interrupts are  
blocked, and would like to find out if it's worth the trouble  
to unblock them.  
  
Also add INTERRUPTS_CAN_BE_PROCESSED(), which indicates whether  
CHECK_FOR_INTERRUPTS() can be relied on to clear the pending interrupt.  
  
This commit doesn't actually add any uses of the new macros,  
but a follow-on bug fix will do so.  Back-patch to all supported  
branches to provide infrastructure for that fix.  
  
Alvaro Herrera and Tom Lane  
  
Discussion: https://postgr.es/m/20210513155351.GA7848@alvherre.pgsql  

commit   : 1b5617eb844cd2470a334c1d2eec66cf9b39c41a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 May 2021 13:10:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 May 2021 13:10:52 -0400    

This explains the new behavior introduced by 0827e8af70f4 as well as  
preexisting.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210423180152.GA17270@telsasoft.com  

commit   : 5eb1b27d20670b378508391fab01a6871a86a8e9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 14 May 2021 13:01:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 14 May 2021 13:01:03 -0400    

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

commit   : 09ae329957b739dfbaf722eb5624d0a71fdff3b4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 14 May 2021 10:21:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 14 May 2021 10:21:28 +0200    

commit   : 521d08a21a2b1ba7038ccc815b8bccc3c9be1351    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 May 2021 21:16:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 May 2021 21:16:34 -0400    

commit   : 6cb93beddd33d00e0ce2ee55edfa32cd2a935394    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 14 May 2021 12:26:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 14 May 2021 12:26:11 +1200    

This seems to be leftover from ea15e1867 and from when we used to evaluate  
SRFs at each node.  
  
Since there is an unconditional "return" at the end of the loop body, only  
1 loop is ever possible, so we can just change this into an if condition.  
  
There is no actual bug being fixed here so no back-patch. It seems fine to  
just fix this anomaly in master only.  
  
Author: Greg Nancarrow  
Discussion: https://postgr.es/m/CAJcOf-d7T1q0az-D8evWXnsuBZjigT04WkV5hCAOEJQZRWy28w@mail.gmail.com  

commit   : fbe9b80610fe17ed27ee318bdc5ba06ed86b1a71    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 13 May 2021 16:07:17 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 13 May 2021 16:07:17 -0700    

The percentage of blocks from the table value reported by autovacuum log  
output (following commit 5100010ee4d) should never exceed 100% because  
it describes the state of the table back when lazy_vacuum() was called.  
The value could nevertheless exceed 100% in the event of heap relation  
truncation.  We failed to compensate for how truncation affects  
rel_pages.  
  
Fix the faulty accounting by using the original rel_pages value instead  
of the current/final rel_pages value.  
  
Reported-By: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20210423204306.5osfpkt2ggaedyvy@alap3.anarazel.de  

commit   : b2d0c7c96711843c6e47fce71335d43127f81647    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 May 2021 11:45:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 May 2021 11:45:43 -0400    

commit   : 9b7286c2b394381c937559a98f35df64a92ffbac    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 13 May 2021 16:10:21 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 13 May 2021 16:10:21 +0300    

Make sample like_regex match string values of the root object instead of the  
whole document.  The corrected example seems to represent a more relevant  
use case.  
  
Backpatch to 12, when jsonpath was introduced.  
  
Discussion: https://postgr.es/m/13440f8b-4c1f-5875-c8e3-f3f65606af2f%40xs4all.nl  
Author: Erik Rijkers  
Reviewed-by: Michael Paquier, Alexander Korotkov  
Backpatch-through: 12  

commit   : a784859f4480ceaa05a00ca35311071ca33483d1    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 13 May 2021 20:00:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 13 May 2021 20:00:00 +0900    

Commits 27e1f1456 and 86dc90056, which were independently discussed,  
cause a crash when executing an inherited foreign UPDATE/DELETE query  
with asynchronous execution enabled, where children of an Append node  
that is the direct/indirect child of the ModifyTable node are rewritten  
so as to modify foreign tables directly by postgresPlanDirectModify();  
as in that case the direct modifications are executed asynchronously,  
which is not currently supported by asynchronous execution.  Fix by  
disabling asynchronous execution of the direct modifications in that  
function.  
  
Author: Etsuro Fujita  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/CAPmGK158e9sJOfuWxfn%2B0ynrspXQU3JhNjSCbaoeSzMvnga%2Bbw%40mail.gmail.com  

commit   : 5a73a9e3b5b24cf2dd90ab4a7ae3724b2c12a0cc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 13 May 2021 08:09:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 13 May 2021 08:09:53 +0200    

commit   : fc69509131c33c298e39dd25d542374e86aa3295    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 13 May 2021 10:14:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 13 May 2021 10:14:07 +0530    

Some of the tests were not considering that the slot's spill stats could be  
received by the stats collector after we have reset the stats. Remove  
those tests and don't check total bytes decoded and sent to output plugin  
in the spilled stats test as we can send the spilled stats to the stats  
collector before actually sending the changes to output plugin.  
  
Reported-by: Tom Lane as per buildfarm  
Author: Vignesh C, Sawada Masahiko  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : b35f827b68dc1e761e17f621fbf17c3ecd073cb0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 May 2021 23:34:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 May 2021 23:34:35 -0400    

commit   : 1906cc07d90a8e58fd381dba43c1085e9231f236    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 13 May 2021 09:48:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 13 May 2021 09:48:28 +0900    

When specified directly as DML queries, INSERT was not getting always  
completed to "INSERT INTO", same for DELETE with "DELETE FROM".  This  
makes the completion behavior more consistent for both commands, saving  
a few keystrokes.  
  
Commands on policies, triggers, grant/revoke, etc. require only DELETE  
as completion keyword.  
  
Author: Haiying Tang  
Reviewed-by: Dilip Kumar, Julien Rouhaud  
Discussion: https://postgr.es/m/OS0PR01MB61135AE2B07CCD1AB8C6A0F6FB549@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : db16c656478b815627a03bb0a31833391a733eb0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 May 2021 19:13:54 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 May 2021 19:13:54 -0400    

The worker.c global wrconn is only meant to be used by logical apply/  
tablesync workers, but there are other variables with the same name. To  
reduce future confusion rename the global from "wrconn" to  
"LogRepWorkerWalRcvConn".  
  
While this is just cosmetic, it seems better to backpatch it all the way  
back to 10 where this code appeared, to avoid future backpatching  
issues.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CAHut+Pu7Jv9L2BOEx_Z0UtJxfDevQSAUW2mJqWU+CtmDrEZVAg@mail.gmail.com  

commit   : 7dde98728a2ef6d48ef397ee783dd130fdb34e6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 18:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 18:41:39 -0400    

Previously, any error reported by the backend while reading  
system_constraints.sql would report the entire file, not just the  
particular command it was working on.  (Ask me how I know.)  Likewise,  
there were chunks of system_functions.sql that would be read as one  
command, which would be annoying if anything failed there.  
  
The issue for system_constraints.sql is an oversight in commit  
dfb75e478.  I didn't try to trace down where the poor formatting  
in system_functions.sql started, but it's certainly contrary to  
the advice at the head of that file.  

commit   : 1f9b0e6938054515b8c9df545437c3d347eed683    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 17:41:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 17:41:07 -0400    

Commit ab596105b neglected to make the docs match the code.  

commit   : 14472442861ca95cc9158518acdedf740c4bff55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 13:36:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 13:36:06 -0400    

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

commit   : def5b065ff22a16a80084587613599fe15627213    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 13:14:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 May 2021 13:14:10 -0400    

Also "make reformat-dat-files".  
  
The only change worthy of note is that pgindent messed up the formatting  
of launcher.c's struct LogicalRepWorkerId, which led me to notice that  
that struct wasn't used at all anymore, so I just took it out.  

commit   : e6ccd1ce1644d1b40b7981f8bc172394de524f99    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 May 2021 14:54:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 May 2021 14:54:02 +0900    

The section of the code in charge of returning all the relations  
associated to a subscription only need one ScanKey, but allocated two of  
them.  This code was introduced as a copy-paste from a different area on  
the same file by 7c4f524, making the result confusing to follow.  
  
Author: Peter Smith  
Reviewed-by: Tom Lane, Julien Rouhaud, Bharath Rupireddy  
Discussion: https://postgr.es/m/CAHut+PsLKe+rN3FjchoJsd76rx2aMsFTB7CTFxRgUP05p=kcpQ@mail.gmail.com  

commit   : ec6e70c79fffe9292402ee602d3742a8c7d31bd2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 12 May 2021 07:20:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 12 May 2021 07:20:10 +0200    

commit   : a363bc6da96b14d27e1cae1bae97242eb6ade5e6    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 12 May 2021 14:00:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 12 May 2021 14:00:00 +0900    

EXPLAIN ANALYZE for an async-capable ForeignScan node associated with  
postgres_fdw is done just by using instrumentation for ExecProcNode()  
called from the node's callbacks, causing the following problems:  
  
1) If the remote table to scan is empty, the node is incorrectly  
   considered as "never executed" by the command even if the node is  
   executed, as ExecProcNode() isn't called from the node's callbacks at  
   all in that case.  
2) The command fails to collect timings for things other than  
   ExecProcNode() done in the node, such as creating a cursor for the  
   node's remote query.  
  
To fix these problems, add instrumentation for async-capable nodes, and  
modify postgres_fdw accordingly.  
  
My oversight in commit 27e1f1456.  
  
While at it, update a comment for the AsyncRequest struct in execnodes.h  
and the documentation for the ForeignAsyncRequest API in fdwhandler.sgml  
to match the code in ExecAsyncAppendResponse() in nodeAppend.c, and fix  
typos in comments in nodeAppend.c.  
  
Per report from Andrey Lepikhov, though I didn't use his patch.  
  
Reviewed-by: Andrey Lepikhov  
Discussion: https://postgr.es/m/2eb662bb-105d-fc20-7412-2f027cc3ca72%40postgrespro.ru  

commit   : e135743ef07ea59088d09c459f41ee2eaabe95c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 20:59:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 20:59:45 -0400    

Several queries in the privileges regression test cause the planner  
to apply the plpgsql function "leak()" to every element of the  
histogram for atest12.b.  Since commit 0c882e52a increased the size  
of that histogram to 10000 entries, the test invokes that function  
over 100000 times, which takes an absolutely unreasonable amount of  
time in clobber-cache-always mode.  
  
However, there's no real reason why that has to be a plpgsql  
function: for the purposes of this test, all that matters is that  
it not be marked leakproof.  So we can replace the plpgsql  
implementation with a direct call of int4lt, which has the same  
behavior and is orders of magnitude faster.  This is expected to  
cut several hours off the buildfarm cycle time for CCA animals.  
It has some positive impact in normal builds too, though that's  
probably lost in the noise.  
  
Back-patch to v13 where 0c882e52a came in.  
  
Discussion: https://postgr.es/m/575884.1620626638@sss.pgh.pa.us  

commit   : d780d7c0882fe9a385102b292907baaceb505ed0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 12 May 2021 09:56:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 12 May 2021 09:56:34 +0900    

Previously long was used as the data type for some counters in BufferUsage  
and WalUsage. But long is only four byte, e.g., on Windows, and it's entirely  
possible to wrap a four byte counter. For example, emitting more than  
four billion WAL records in one transaction isn't actually particularly rare.  
  
To avoid the overflows of those counters, this commit changes the data type  
of them from long to int64.  
  
Suggested-by: Andres Freund  
Author: Masahiro Ikeda  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20201221211650.k7b53tcnadrciqjo@alap3.anarazel.de  
Discussion: https://postgr.es/m/af0964ac-7080-1984-dc23-513754987716@oss.nttdata.com  

commit   : 0bf62931cae0db1294937eb9190b183494af4cf8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 11 May 2021 20:02:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 11 May 2021 20:02:02 -0400    

Use a static prolog file instead of generating the prolog from the  
existing perl script. Also, support generation of the file in a vpath  
build.  
  
Discussion: https://postgr.es/m/700620.1620662868@sss.pgh.pa.us  

commit   : 0b85fa93e4575183aa5a71ebe3c6bae8d97704ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 19:17:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 19:17:07 -0400    

I copied the existing spelling of "--max_connections", but  
that's just wrong :-(.  Evidently setting $ENV{MAX_CONNECTIONS}  
has never actually worked in this script.  Given the lack of  
complaints, it's probably not worth back-patching a fix.  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/899209.1620759506@sss.pgh.pa.us  

commit   : 1df3555acc78dedc3ca25eb5e83649b3da1f298f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 17:52:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 17:52:04 -0400    

Having to maintain two lists of regression test scripts has proven  
annoyingly error-prone.  We can achieve the effect of the  
serial_schedule by running the parallel_schedule with  
"--max_connections=1"; so do that and remove serial_schedule.  
  
This causes cosmetic differences in the progress output, but it  
doesn't seem worth restructuring pg_regress to avoid that.  
  
Discussion: https://postgr.es/m/899209.1620759506@sss.pgh.pa.us  

commit   : 5b2d09beaffa915edd6e74fcf030b13844d3326f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 May 2021 17:40:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 May 2021 17:40:44 -0400    

commit   : 6303a5730914dfe6ef2709b28b225553315c573c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 14:28:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 14:28:11 -0400    

opr_sanity's binary_coercible() function has always been meant  
to match the parser's notion of binary coercibility, but it also  
has always been a rather poor approximation of the parser's  
real rules (as embodied in IsBinaryCoercible()).  That hasn't  
bit us so far, but it's predictable that it will eventually.  
  
It also now emerges that implementing this check in plpgsql  
performs absolutely horribly in clobber-cache-always testing.  
(Perhaps we could do something about that, but I suspect it just  
means that plpgsql is exploiting catalog caching to the hilt.)  
  
Hence, let's replace binary_coercible() with a C shim that directly  
invokes IsBinaryCoercible(), eliminating both the semantic hazard  
and the performance issue.  
  
Most of regress.c's C functions are declared in create_function_1,  
but we can't simply move that to before opr_sanity/type_sanity  
since those tests would complain about the resulting shell types.  
I chose to split it into create_function_0 and create_function_1.  
Since create_function_0 now runs as part of a parallel group while  
create_function_1 doesn't, reduce the latter to create just those  
functions that opr_sanity and type_sanity would whine about.  
  
To make room for create_function_0 in the second parallel group  
of tests, move tstypes to the third parallel group.  
  
In passing, clean up some ordering deviations between  
parallel_schedule and serial_schedule.  
  
Discussion: https://postgr.es/m/292305.1620503097@sss.pgh.pa.us  

commit   : 6d177e2813a2b4415539e2861b595583cc1a8f71    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 11 May 2021 09:06:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 11 May 2021 09:06:49 +0200    

commit   : ff51679220ce31091bfdbc96d2e90fc02ac6f329    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 10 May 2021 23:56:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 10 May 2021 23:56:32 -0400    

commit   : 1692d0c3a3fc7716d7d00e0d657248cb98bf4df8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 11 May 2021 15:55:33 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 11 May 2021 15:55:33 +1200    

The note is no longer true as of 86dc90056, so remove it.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqFxQn7Hz1wT+wYgnf_9SK0c4BwOOwFFT8jcSZwJrd8HEA@mail.gmail.com  

commit   : 9ca40dcd4d0cad43d95a9a253fafaa9a9ba7de24    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 11 May 2021 10:43:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 11 May 2021 10:43:05 +0900    

Since its introduction in bbe0a81, compression of table data supports  
LZ4, but nothing had been done within the MSVC scripts to allow users to  
build the code with this library.  
  
This commit closes the gap by extending the MSVC scripts to be able to  
build optionally with LZ4.  Getting libraries that can be used for  
compilation and execution is possible as LZ4 can be compiled down to  
MSVC 2010 using its source tarball.  MinGW may require extra efforts to  
be able to work, and I have been able to test this only with MSVC, still  
this is better than nothing to give users a way to test the feature on  
Windows.  
  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/YJPdNeF68XpwDDki@paquier.xyz  

commit   : 049e1e2edb06854d7cd9460c22516efaa165fbf8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 11:02:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 11:02:29 -0400    

It's unusual to have any resjunk columns in an ON CONFLICT ... UPDATE  
list, but it can happen when MULTIEXPR_SUBLINK SubPlans are present.  
If it happens, the ON CONFLICT UPDATE code path would end up storing  
tuples that include the values of the extra resjunk columns.  That's  
fairly harmless in the short run, but if new columns are added to  
the table then the values would become accessible, possibly leading  
to malfunctions if they don't match the datatypes of the new columns.  
  
This had escaped notice through a confluence of missing sanity checks,  
including  
  
* There's no cross-check that a tuple presented to heap_insert or  
heap_update matches the table rowtype.  While it's difficult to  
check that fully at reasonable cost, we can easily add assertions  
that there aren't too many columns.  
  
* The output-column-assignment cases in execExprInterp.c lacked  
any sanity checks on the output column numbers, which seems like  
an oversight considering there are plenty of assertion checks on  
input column numbers.  Add assertions there too.  
  
* We failed to apply nodeModifyTable's ExecCheckPlanOutput() to  
the ON CONFLICT UPDATE tlist.  That wouldn't have caught this  
specific error, since that function is chartered to ignore resjunk  
columns; but it sure seems like a bad omission now that we've seen  
this bug.  
  
In HEAD, the right way to fix this is to make the processing of  
ON CONFLICT UPDATE tlists work the same as regular UPDATE tlists  
now do, that is don't add "SET x = x" entries, and use  
ExecBuildUpdateProjection to evaluate the tlist and combine it with  
old values of the not-set columns.  This adds a little complication  
to ExecBuildUpdateProjection, but allows removal of a comparable  
amount of now-dead code from the planner.  
  
In the back branches, the most expedient solution seems to be to  
(a) use an output slot for the ON CONFLICT UPDATE projection that  
actually matches the target table, and then (b) invent a variant of  
ExecBuildProjectionInfo that can be told to not store values resulting  
from resjunk columns, so it doesn't try to store into nonexistent  
columns of the output slot.  (We can't simply ignore the resjunk columns  
altogether; they have to be evaluated for MULTIEXPR_SUBLINK to work.)  
This works back to v10.  In 9.6, projections work much differently and  
we can't cheaply give them such an option.  The 9.6 version of this  
patch works by inserting a JunkFilter when it's necessary to get rid  
of resjunk columns.  
  
In addition, v11 and up have the reverse problem when trying to  
perform ON CONFLICT UPDATE on a partitioned table.  Through a  
further oversight, adjust_partition_tlist() discarded resjunk columns  
when re-ordering the ON CONFLICT UPDATE tlist to match a partition.  
This accidentally prevented the storing-bogus-tuples problem, but  
at the cost that MULTIEXPR_SUBLINK cases didn't work, typically  
crashing if more than one row has to be updated.  Fix by preserving  
resjunk columns in that routine.  (I failed to resist the temptation  
to add more assertions there too, and to do some minor code  
beautification.)  
  
Per report from Andres Freund.  Back-patch to all supported branches.  
  
Security: CVE-2021-32028  

commit   : f02b9085ad2f6fefd9c5cdf85579cb9f0ff0f0ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 10:44:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 10:44:38 -0400    

While we were (mostly) careful about ensuring that the dimensions of  
arrays aren't large enough to cause integer overflow, the lower bound  
values were generally not checked.  This allows situations where  
lower_bound + dimension overflows an integer.  It seems that that's  
harmless so far as array reading is concerned, except that array  
elements with subscripts notionally exceeding INT_MAX are inaccessible.  
However, it confuses various array-assignment logic, resulting in a  
potential for memory stomps.  
  
Fix by adding checks that array lower bounds aren't large enough to  
cause lower_bound + dimension to overflow.  (Note: this results in  
disallowing cases where the last subscript position would be exactly  
INT_MAX.  In principle we could probably allow that, but there's a lot  
of code that computes lower_bound + dimension and would need adjustment.  
It seems doubtful that it's worth the trouble/risk to allow it.)  
  
Somewhat independently of that, array_set_element() was careless  
about possible overflow when checking the subscript of a fixed-length  
array, creating a different route to memory stomps.  Fix that too.  
  
Security: CVE-2021-32027  

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