PostgreSQL 13.0 (upcoming) commit log

commit   : 199cec9779504c08aaa8159c6308283156547409    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2020 14:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2020 14:45:00 +0900    

Commit 13838740f fixed some issues with step generation in partition  
pruning, but there was yet another one: get_steps_using_prefix() assumes  
that clauses in the passed-in prefix list are sorted in ascending order  
of their partition key numbers, but the caller failed to ensure this for  
range partitioning, which led to an assertion failure in debug builds.  
Adjust the caller function to arrange the clauses in the prefix list in  
the required order for range partitioning.  
  
Back-patch to v11, like the previous commit.  
  
Patch by me, reviewed by Amit Langote.  
  
Discussion: https://postgr.es/m/CAPmGK16jkXiFG0YqMbU66wte-oJTfW6D1HaNvQf%3D%2B5o9%3Dm55wQ%40mail.gmail.com  

commit   : 3a3be80641c01e675d0ed484f15df8ec536d0a06    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 16:23:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 16:23:52 -0700    

Oversight in commit d114cc53871.  

commit   : c254d8d7b20bf629420b407a5451c3b32d1a7b0b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 15:25:49 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 15:25:49 -0700    

This will be helpful if it ever proves necessary to revoke an opclass's  
support for deduplication.  
  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : d5e96520ffca8eeeefc11f8fc82af610f68e63a8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 7 Aug 2020 10:22:18 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 7 Aug 2020 10:22:18 +1200    

9bdb300de modified the EXPLAIN output for Hash Aggregate to show details  
from parallel workers. However, it neglected to consider that a given  
parallel worker may not have assisted with the given Hash Aggregate. This  
can occur when workers fail to start or during Parallel Append with  
enable_partitionwise_join enabled when only a single worker is working on  
a non-parallel aware sub-plan. It could also happen if a worker simply  
wasn't fast enough to get any work done before other processes went and  
finished all the work.  
  
The bogus output came from the fact that ExplainOpenWorker() skipped  
showing any details for non-initialized workers but show_hashagg_info()  
did show details from the worker.  This meant that the worker properties  
that were shown were not properly attributed to the worker that they  
belong to.  
  
In passing, we also now don't show Hash Aggregate properties for the  
leader process when it did not contribute any work to the Hash Aggregate.  
This can occur either during Parallel Append when only a parallel worker  
worked on a given sub plan or with parallel_leader_participation set to  
off.  This aims to make the behavior of Hash Aggregate's EXPLAIN output  
more similar to Sort's.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20200805012105.GZ28072%40telsasoft.com  
Backpatch-through: 13, where the original breakage was introduced  

commit   : bab150045bd9766869f471ede88734ea0989261c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Aug 2020 14:13:03 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Aug 2020 14:13:03 -0400    

This seems more correct, because other before_shmem_exit calls may  
expect the infrastructure that is needed to run queries and access the  
database to be working, and also because this cleanup has nothing to  
do with shared memory.  
  
There are no known user-visible consequences to this, though, apart  
from what was previous fixed by commit  
303640199d0436c5e7acdf50b837a027b5726594 and back-patched as commit  
bcbc27251d35336a6442761f59638138a772b839 and commit  
f7013683d9bb663a6a917421b1374306a32f165b, so for now, no back-patch.  
  
Bharath Rupireddy  
  
Discussion: http://postgr.es/m/CALj2ACWk7j4F2v2fxxYfrroOF=AdFNPr1WsV+AGtHAFQOqm_pw@mail.gmail.com  

commit   : a6775352476ac92d6b3eb3ae2dfd2775e3622afe    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Aug 2020 17:12:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Aug 2020 17:12:10 -0400    

Reported-by: Vyacheslav Shablistyy  
  
Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 7a980dfc6c15add6ec3309932cf3061bb6745f65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Aug 2020 15:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Aug 2020 15:38:55 -0400    

Since we no longer require AccessExclusiveLock to add a partition,  
the executor may see that a partitioned table has more partitions  
than the planner saw.  ExecCreatePartitionPruneState's code for  
matching up the partition lists in such cases was faulty, and would  
misbehave if the planner had successfully pruned any partitions from  
the query.  (Thus, trouble would occur only if a partition addition  
happens concurrently with a query that uses both static and dynamic  
partition pruning.)  This led to an Assert failure in debug builds,  
and probably to crashes or query misbehavior in production builds.  
  
To repair the bug, just explicitly skip zeroes in the plan's  
relid_map[] list.  I also made some cosmetic changes to make the code  
more readable (IMO anyway).  Also, convert the cross-checking Assert  
to a regular test-and-elog, since it's now apparent that this logic  
is more fragile than one would like.  
  
Currently, there's no way to repeatably exercise this code, except  
with manual use of a debugger to stop the backend between planning  
and execution.  Hence, no test case in this patch.  We oughta do  
something about that testability gap, but that's for another day.  
  
Amit Langote and Tom Lane, per report from Justin Pryzby.  Oversight  
in commit 898e5e329; backpatch to v12 where that appeared.  
  
Discussion: https://postgr.es/m/20200802181131.GA27754@telsasoft.com  

commit   : f47b5e139579a77c1f7c63400f01ea39d515e8c8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 5 Aug 2020 02:15:34 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 5 Aug 2020 02:15:34 +0300    

Currently, page unlink leaves remaining items "as is", but replay of  
corresponding WAL-record re-initializes page leaving it with no items.  
For the sake of consistency, this commit makes primary delete all the items  
during page unlink as well.  
  
Thanks to this change, we now don't mask contents of deleted btree page for  
WAL consistency checking.  
  
Discussion: https://postgr.es/m/CAPpHfdt_OTyQpXaPJcWzV2N-LNeNJseNB-K_A66qG%3DL518VTFw%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  

commit   : 0f76294260b92849c4958fb706ecd5b5cd73e40e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2020 15:20:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2020 15:20:31 -0400    

A couple of test cases had connect_timeout=14, a value that seems  
to have been plucked from a hat.  While it's more than sufficient  
for normal cases, slow/overloaded buildfarm machines can get a timeout  
failure here, as per recent report from "sungazer".  Increase to 180  
seconds, which is in line with our typical timeouts elsewhere in  
the regression tests.  
  
Back-patch to 9.6; the code looks different in 9.5, and this doesn't  
seem to be quite worth the effort to adapt to that.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2020-08-04%2007%3A12%3A22  

commit   : dd877998d498c511352bd3640fd57f041c90ea62    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Aug 2020 14:36:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Aug 2020 14:36:01 +0900    

The test would fail in an environment including a certificate file in  
~/.postgresql/.  bdd6e9b fixed a similar failure, and d6e612f introduced  
the same problem again with a new test.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200804.120033.31225582282178001.horikyota.ntt@gmail.com  
Backpatch-through: 13  

commit   : 9a9db08ae46209edcc5ecb120328a2bf92fd6069    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 3 Aug 2020 15:54:38 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 3 Aug 2020 15:54:38 -0700    

It was possible for the logic used by backward scans (which must reason  
about concurrent page splits/deletions in its own peculiar way) to  
become confused when running on a replica.  Concurrent replay of a WAL  
record that describes the second phase of page deletion could cause  
_bt_walk_left() to get confused.  btree_xlog_unlink_page() simply failed  
to adhere to the same locking protocol that we use on the primary, which  
is obviously wrong once you consider these two disparate functions  
together.  This bug is present in all stable branches.  
  
More concretely, the problem was that nothing stopped _bt_walk_left()  
from observing inconsistencies between the deletion's target page and  
its original sibling pages when running on a replica.  This is true even  
though the second phase of page deletion is supposed to work as a single  
atomic action.  Queries running on replicas raised "could not find left  
sibling of block %u in index %s" can't-happen errors when they went back  
to their scan's "original" page and observed that the page has not been  
marked deleted (even though it really was concurrently deleted).  
  
There is no evidence that this actually happened in the real world.  The  
issue came to light during unrelated feature development work.  Note  
that _bt_walk_left() is the only code that cares about the difference  
between a half-dead page and a fully deleted page that isn't also  
exclusively used by nbtree VACUUM (unless you include contrib/amcheck  
code).  It seems very likely that backward scans are the only thing that  
could become confused by the inconsistency.  Even amcheck's complex  
bt_right_page_check_scankey() dance was unaffected.  
  
To fix, teach btree_xlog_unlink_page() to lock the left sibling, target,  
and right sibling pages in that order before releasing any locks (just  
like _bt_unlink_halfdead_page()).  This is the simplest possible  
approach.  There doesn't seem to be any opportunity to be more clever  
about lock acquisition in the REDO routine, and it hardly seems worth  
the trouble in any case.  
  
This fix might enable contrib/amcheck verification of leaf page sibling  
links with only an AccessShareLock on the relation.  An amcheck patch  
from Andrey Borodin was rejected back in January because it clashed with  
btree_xlog_unlink_page()'s lax approach to locking pages.  It now seems  
likely that the real problem was with btree_xlog_unlink_page(), not the  
patch.  
  
This is a low severity, low likelihood bug, so no backpatch.  
  
Author: Michail Nikolaev  
Diagnosed-By: Michail Nikolaev  
Discussion: https://postgr.es/m/CANtu0ohkR-evAWbpzJu54V8eCOtqjJyYp3PQ_SGoBTRGXWhWRw@mail.gmail.com  

commit   : a451b7d44249b8655db8d40476ace9f84d76ab88    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 3 Aug 2020 13:04:42 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 3 Aug 2020 13:04:42 -0700    

Add a documenting assertion that's similar to the nearby assertion added  
by commit cd8c73a3.  This conveys that the entire call to _bt_pagedel()  
does no work if it isn't possible to get a descent stack for the initial  
scanblkno page.  

commit   : 9e496768b8a7303ea07888ea1baae8e2a57dda7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 14:02:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 14:02:35 -0400    

A moment's examination of these queries is sufficient to see that  
they do not produce duplicate rows, unless perhaps there's  
catalog corruption.  Using DISTINCT anyway is inefficient and  
confusing; moreover it sets a poor example for anyone who  
refers to psql -E output to see how to query the catalogs.  

commit   : eeb01e3122bb0acb6f8575d352e8e63101662ae7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 13:11:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 13:11:16 -0400    

We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but  
that commit forgot to fix the documentation about timetz.  
  
Per bug #16571 from osdba.  
  
Discussion: https://postgr.es/m/16571-eb7501598de78c8a@postgresql.org  

commit   : 5f28b21eb3c5c2fb72c24608bc686acd7c9b113c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 09:46:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 09:46:12 -0400    

This ought to work much like C's "#elif defined(name)"; but the code  
implemented it in a way equivalent to endif followed by ifdef, so that  
it didn't matter whether any previous branch of the IF construct had  
succeeded.  Fix that; add some test cases covering elif and nested IFs;  
and improve the documentation, which also seemed a bit confused.  
  
AFAICS the code has been like this since the feature was added in 1999  
(commit b57b0e044).  So while it's surely wrong, there might be code  
out there relying on the current behavior.  Hence, don't back-patch  
into stable branches.  It seems all right to fix it in v13 though.  
  
Per report from Ashutosh Sharma.  Reviewed by Ashutosh Sharma and  
Michael Meskes.  
  
Discussion: https://postgr.es/m/CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com  

commit   : b8fdee7d0ca8bd2165d46fb1468f75571b706a01    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Aug 2020 13:38:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Aug 2020 13:38:48 +0900    

This is useful for monitoring purposes with log parsing.  Similarly to  
pg_stat_activity, the leader's PID is shown only for active parallel  
workers, minimizing the log footprint for the leaders as the equivalent  
shared memory field is set as long as a backend is alive.  
  
Author: Justin Pryzby  
Reviewed-by: Álvaro Herrera, Michael Paquier, Julien Rouhaud, Tom Lane  
Discussion: https://postgr.es/m/20200315111831.GA21492@telsasoft.com  

commit   : f44b9b625bedd8e0bca67b3b42ba10ce482fa31b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 3 Aug 2020 12:39:15 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 3 Aug 2020 12:39:15 +1200    

Instead of writing a query to psql's stdin, use -c.  This avoids a  
failure where psql exits before we write, seen a few times on the build  
farm.  Thanks to Tom Lane for the suggestion.  
  
Back-patch to 11, where the LDAP tests arrived.  
  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/CA%2BhUKGLFmW%2BHQYPeKiwSp5sdFFHtFViCpw4Mh6yAgEx74r5-Cw%40mail.gmail.com  

commit   : 63e9aa6879cc5b87c77bab9afea3740748a4f00b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 3 Aug 2020 12:17:41 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 3 Aug 2020 12:17:41 +1200    

Post-commit review for commit 84c0e4b9.  
  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAApHDvptBx_%2BUPAzY0uXzopbvPVGKPeZ6Hoy8rnPcWz20Cr0Bw%40mail.gmail.com  

commit   : 533020d05045046a3481fdd92777de7bb2e30ab3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2020 17:00:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2020 17:00:26 -0400    

The type-name pattern in \dAc and \dAf was matched only to the actual  
pg_type.typname string, which is fairly user-unfriendly in cases where  
that is not what's shown to the user by format_type (compare "_int4"  
and "integer[]").  Make this code match what \dT does, i.e. match the  
pattern against either typname or format_type() output.  Also fix its  
broken handling of schema-name restrictions.  (IOW, make these  
processSQLNamePattern calls match \dT's.)  While here, adjust  
whitespace to make the query a little prettier in -E output, too.  
  
Also improve some inaccuracies and shaky grammar in the related  
documentation.  
  
Noted while working on a patch for intarray's opclasses; I wondered  
why I couldn't get a match to "integer*" for the input type name.  

commit   : 6ee3b5fb990ea11992b0db960d79b1fbe7b5e8e5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 2 Aug 2020 14:24:46 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 2 Aug 2020 14:24:46 +1200    

Windows 64bit has 4-byte long values which is not suitable for tracking  
disk space usage in the incremental sort code. Let's just make all these  
fields int64s.  
  
Author: James Coleman  
Discussion: https://postgr.es/m/CAApHDvpky%2BUhof8mryPf5i%3D6e6fib2dxHqBrhp0Qhu0NeBhLJw%40mail.gmail.com  
Backpatch-through: 13, where the incremental sort code was added  

commit   : cd5e82256de5895595cdd99ecb03aea15b346f71    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 1 Aug 2020 15:31:01 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 1 Aug 2020 15:31:01 -0700    

We have edge-case bugs when assigning values in the last few dozen pages  
before the wrap limit.  We may introduce similar bugs in the future.  At  
default BLCKSZ, this makes such bugs unreachable outside of single-user  
mode.  Also, when VACUUM began to consume mxacts, multiStopLimit did not  
change to compensate.  
  
pg_upgrade may fail on a cluster that was already printing "must be  
vacuumed" warnings.  Follow the warning's instructions to clear the  
warning, then run pg_upgrade again.  One can still, peacefully consume  
98% of XIDs or mxacts, so DBAs need not change routine VACUUM settings.  
  
Discussion: https://postgr.es/m/20200621083513.GA3074645@rfd.leadboat.com  

commit   : 9f9682783bea74bf8d93cac4f7dd65fa677f5dc7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Aug 2020 17:12:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Aug 2020 17:12:47 -0400    

This allows AM-specific knowledge to be applied during creation of  
pg_amop and pg_amproc entries.  Specifically, the AM knows better than  
core code which entries to consider as required or optional.  Giving  
the latter entries the appropriate sort of dependency allows them to  
be dropped without taking out the whole opclass or opfamily; which  
is something we'd like to have to correct obsolescent entries in  
extensions.  
  
This callback also opens the door to performing AM-specific validity  
checks during opclass creation, rather than hoping than an opclass  
developer will remember to test with "amvalidate".  For the most part  
I've not actually added any such checks yet; that can happen in a  
follow-on patch.  (Note that we shouldn't remove any tests from  
"amvalidate", as those are still needed to cross-check manually  
constructed entries in the initdb data.  So adding tests to  
"amadjustmembers" will be somewhat duplicative, but it seems like  
a good idea anyway.)  
  
Patch by me, reviewed by Alexander Korotkov, Hamid Akhtar, and  
Anastasia Lubennikova.  
  
Discussion: https://postgr.es/m/4578.1565195302@sss.pgh.pa.us  

commit   : e2b37d9e7cabc90633c4bd822e1bcfdd1bda44c4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 1 Aug 2020 23:39:36 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 1 Aug 2020 23:39:36 +1200    

This avoids lseek() system calls at every SLRU I/O, as was  
done for relation files in commit c24dcd0c.  
  
Reviewed-by: Ashwin Agrawal <aagrawal@pivotal.io>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKG%2Biqke4uTRFj8D8uEUUgj%2BRokPSp%2BCWM6YYzaaamG9Wvg%40mail.gmail.com  
Discussion: https://postgr.es/m/CA%2BhUKGJ%2BoHhnvqjn3%3DHro7xu-YDR8FPr0FL6LF35kHRX%3D_bUzg%40mail.gmail.com  

commit   : 022350b8495a8a7ff0ff8dd6791572e91e7cd6fe    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Aug 2020 11:49:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Aug 2020 11:49:13 +0900    

When doing multiple insertions in pg_shdepend for the copy of  
dependencies from a template database in CREATE DATABASE, the same  
number of slots would have been created and used all the time.  As the  
number of items to insert is not known in advance, this makes most of  
the slots created for nothing.  This improves the slot handling so as  
slot creation only happens when needed, minimizing the overhead of the  
operation.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200731024148.GB3317@paquier.xyz  

commit   : 84c0e4b9bce794da914fe9c062753bf21369745f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 1 Aug 2020 12:16:15 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 1 Aug 2020 12:16:15 +1200    

When reading the code it's not obvious when one should prefer dynahash  
over simplehash and vice-versa, so, for programmer-friendliness, add  
comments to inform that decision.  
  
Show sample simplehash method signatures.  
  
Author: James Coleman <jtc331@gmail.com>  
Discussion: https://postgr.es/m/CAAaqYe_dOF39gAJ8rL-a3YO3Qo96MHMRQ2whFjK5ZcU6YvMQSA%40mail.gmail.com  

commit   : c79aed4f793086300abfc188def94b5c0bd0b45d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 31 Jul 2020 15:34:28 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 31 Jul 2020 15:34:28 -0700    

Commit eba77534 fixed an amcheck false positive bug involving  
inconsistencies in TOAST input state between table and index.  A test  
case was added that verified that such an inconsistency didn't result in  
a spurious corruption related error.  
  
Test coverage from the test was accidentally lost by commit 501e41dd,  
which propagated ALTER TABLE ...  SET STORAGE attstorage state to  
indexes.  This broke the test because the test specifically relied on  
attstorage not being propagated.  This artificially forced there to be  
index tuples whose datums were equivalent to the datums in the heap  
without the datums actually being bitwise equal.  
  
Fix this by updating pg_attribute directly instead.  Commit 501e41dd  
made similar changes to a test_decoding TOAST-related test case which  
made the same assumption, but overlooked the amcheck test case.  
  
Backpatch: 11-, just like commit eba77534 (and commit 501e41dd).  

commit   : 3d2376d55c6f2d364a6a1a95cc350c531f6d9423    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 17:11:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 17:11:28 -0400    

If a base type supports typmods, its array type does too, with the  
same interpretation.  Hence changes in pg_type.typmodin/typmodout  
must be propagated to the array type.  
  
While here, improve AlterTypeRecurse to not recurse to domains if  
there is nothing we'd need to change.  
  
Oversight in fe30e7ebf.  Back-patch to v13 where that came in.  

commit   : 78e73e87548a1e0b71b6f2425f76ea6e9c85b2eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 11:43:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 11:43:12 -0400    

The new hlCover() algorithm that I introduced in commit c9b0c678d  
turns out to potentially take O(N^2) or worse time on long documents,  
if there are many occurrences of individual query words but few or no  
substrings that actually satisfy the query.  (One way to hit this  
behavior is with a "common_word & rare_word" type of query.)  This  
seems unavoidable given the original goal of checking every substring  
of the document, so we have to back off that idea.  Fortunately, it  
seems unlikely that anyone would really want headlines spanning all of  
a long document, so we can avoid the worse-than-linear behavior by  
imposing a maximum length of substring that we'll consider.  
  
For now, just hard-wire that maximum length as a multiple of max_words  
times max_fragments.  Perhaps at some point somebody will argue for  
exposing it as a ts_headline parameter, but I'm hesitant to make such  
a feature addition in a back-patched bug fix.  
  
I also noted that the hlFirstIndex() function I'd added in that  
commit was unnecessarily stupid: it really only needs to check whether  
a HeadlineWordEntry's item pointer is null or not.  This wouldn't make  
all that much difference in typical cases with queries having just  
a few terms, but a cycle shaved is a cycle earned.  
  
In addition, add a CHECK_FOR_INTERRUPTS call in TS_execute_recurse.  
This ensures that hlCover's loop is cancellable if it manages to take  
a long time, and it may protect some other TS_execute callers as well.  
  
Back-patch to 9.6 as the previous commit was.  I also chose to add the  
CHECK_FOR_INTERRUPTS call to 9.5.  The old hlCover() algorithm seems  
to avoid the O(N^2) behavior, at least on the test case I tried, but  
nonetheless it's not very quick on a long document.  
  
Per report from Stephen Frost.  
  
Discussion: https://postgr.es/m/20200724160535.GW12375@tamriel.snowman.net  

commit   : 7be04496a9f763fc4d4c1d06ce9ccc250e52df31    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jul 2020 19:08:09 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jul 2020 19:08:09 +1200    

Per build farm.  
  
Discussion: https://postgr.es/m/20200731062626.GD3317%40paquier.xyz  

commit   : 84b1c63ad41872792d47e523363fce1f0e230022    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jul 2020 17:27:09 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jul 2020 17:27:09 +1200    

Create an optional region in the main shared memory segment that can be  
used to acquire and release "fast" DSM segments, and can benefit from  
huge pages allocated at cluster startup time, if configured.  Fall back  
to the existing mechanisms when that space is full.  The size is  
controlled by a new GUC min_dynamic_shared_memory, defaulting to 0.  
  
Main region DSM segments initially contain whatever garbage the memory  
held last time they were used, rather than zeroes.  That change revealed  
that DSA areas failed to initialize themselves correctly in memory that  
wasn't zeroed first, so fix that problem.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLAE2QBv-WgGp%2BD9P_J-%3Dyne3zof9nfMaqq1h3EGHFXYQ%40mail.gmail.com  

commit   : 7b1110d2fd3da3d7536530d14952d4f4d9c25438    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jul 2020 14:17:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jul 2020 14:17:29 +0900    

local_blks_dirtied tracks the number of local blocks dirtied, not shared  
ones.  
  
Author: Kirk Jamison  
Discussion: https://postgr.es/m/OSBPR01MB2341760686DC056DE89D2AB9EF710@OSBPR01MB2341.jpnprd01.prod.outlook.com  

commit   : c5315f4f44843c20ada876fdb0d0828795dfbdf5    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jul 2020 14:15:18 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 31 Jul 2020 14:15:18 +1200    

Avoid repeatedly calling lseek(SEEK_END) during recovery by caching  
the size of each fork.  For now, we can't use the same technique in  
other processes, because we lack a shared invalidation mechanism.  
  
Do this by generalizing the pre-existing caching used by FSM and VM  
to support all forks.  
  
Discussion: https://postgr.es/m/CAEepm%3D3SSw-Ty1DFcK%3D1rU-K6GSzYzfdD4d%2BZwapdN7dTa6%3DnQ%40mail.gmail.com  

commit   : e3931d01f3afef14703827eda1dad0a3fb3b5d07    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jul 2020 10:54:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jul 2020 10:54:26 +0900    

For pg_attribute, this allows to insert at once a full set of attributes  
for a relation (roughly 15% of WAL reduction in extreme cases).  For  
pg_shdepend, this reduces the work done when creating new shared  
dependencies from a database template.  The number of slots used for the  
insertion is capped at 64kB of data inserted for both, depending on the  
number of items to insert and the length of the rows involved.  
  
More can be done for other catalogs, like pg_depend.  This part requires  
a different approach as the number of slots to use depends also on the  
number of entries discarded as pinned dependencies.  This is also  
related to the rework or dependency handling for ALTER TABLE and CREATE  
TABLE, mainly.  
  
Author: Daniel Gustafsson  
Reviewed-by: Andres Freund, Michael Paquier  
Discussion: https://postgr.es/m/20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de  

commit   : cab2556f3ab289b81a9c6a75e669b6ec78356ffc    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 31 Jul 2020 07:18:41 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 31 Jul 2020 07:18:41 +0900    

In "High Availability, Load Balancing, and Replication" chapter,  
certain descriptions of Pgpool-II were not correct at this point.  It  
does not need conflict resolution. Also "Multiple-Server Parallel  
Query Execution" is not supported anymore.  
  
Discussion: https://postgr.es/m/20200726.230128.53842489850344110.t-ishii%40sraoss.co.jp  
Author: Tatsuo Ishii  
Reviewed-by: Bruce Momjian  
Backpatch-through: 9.5  

commit   : fd734f387d8780d9989d750942d026167de8cf3c    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 30 Jul 2020 08:44:58 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 30 Jul 2020 08:44:58 -0700    

Using pg_leftmost_one_post32() yields substantial performance benefits.  
  
Backpatching to version 13 because HLL is used for HashAgg  
improvements in 9878b643, which was also backpatched to 13.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzkGvDKVDo+0YvfvZ+1CE=iCi88DCOGFF3i1hTGGaxcKPw@mail.gmail.com  
Backpatch-through: 13  

commit   : f1af75c5f2516ec5b20cfe4b3a474071a318ae1e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 16:57:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 16:57:37 +0900    

The relkinds that support indexing are the same as the ones supporting  
VACUUM, so the code gets refactored a bit with the completion query used  
for CLUSTER, but there is no change for CLUSTER in this commit.  
  
Author: Justin Pryzby  
Reviewed-by: Fujii Masao, Michael Paquier, Masahiko Sawada  
Discussion: https://postgr.es/m/20200728170408.GI20393@telsasoft.com  

commit   : 903134fcc0ccd188803fdbc2b7c06b898749153a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 15:48:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 15:48:44 +0900    

Partitioned indexes are also registered in pg_inherits, but the  
description of this catalog did not reflect that.  
  
Author: Dagfinn Ilmari Mannsåker  
Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org  
Backpatch-through: 11  

commit   : e7591fd3cae6c64236ef29d3c87e69b96608a19b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 30 Jul 2020 17:25:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 30 Jul 2020 17:25:48 +1200    

This avoids avoids some epoll/kqueue system calls for every wait.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com  

commit   : e2d394df5df28ab5ee4bfac6b13837e99e24045d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 30 Jul 2020 17:23:32 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 30 Jul 2020 17:23:32 +1200    

Previously, condition_variable.c created a long lived WaitEventSet to  
avoid extra system calls.  WaitLatch() now uses something similar  
internally, so there is no point in wasting an extra kernel descriptor.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com  

commit   : 3347c982bab0dd56d5b6cb784521233ba2bbac27    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 30 Jul 2020 17:08:11 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 30 Jul 2020 17:08:11 +1200    

Create LatchWaitSet at backend startup time, and use it to implement  
WaitLatch().  This avoids repeated epoll/kqueue setup and teardown  
system calls.  
  
Reorder SubPostmasterMain() slightly so that we restore the postmaster  
pipe and Windows signal emulation before we reach InitPostmasterChild(),  
to make this work in EXEC_BACKEND builds.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com  

commit   : d6c08e29e7bc8bc3bf49764192c4a9c71fc0b097    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Jul 2020 14:14:58 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Jul 2020 14:14:58 -0700    

Add a GUC that acts as a multiplier on work_mem.  It gets applied when  
sizing executor node hash tables that were previously size constrained  
using work_mem alone.  
  
The new GUC can be used to preferentially give hash-based nodes more  
memory than the generic work_mem limit.  It is intended to enable admin  
tuning of the executor's memory usage.  Overall system throughput and  
system responsiveness can be improved by giving hash-based executor  
nodes more memory (especially over sort-based alternatives, which are  
often much less sensitive to being memory constrained).  
  
The default value for hash_mem_multiplier is 1.0, which is also the  
minimum valid value.  This means that hash-based nodes continue to apply  
work_mem in the traditional way by default.  
  
hash_mem_multiplier is generally useful.  However, it is being added now  
due to concerns about hash aggregate performance stability for users  
that upgrade to Postgres 13 (which added disk-based hash aggregation in  
commit 1f39bce0).  While the old hash aggregate behavior risked  
out-of-memory errors, it is nevertheless likely that many users actually  
benefited.  Hash agg's previous indifference to work_mem during query  
execution was not just faster; it also accidentally made aggregation  
resilient to grouping estimate problems (at least in cases where this  
didn't create destabilizing memory pressure).  
  
hash_mem_multiplier can provide a certain kind of continuity with the  
behavior of Postgres 12 hash aggregates in cases where the planner  
incorrectly estimates that all groups (plus related allocations) will  
fit in work_mem/hash_mem.  This seems necessary because hash-based  
aggregation is usually much slower when only a small fraction of all  
groups can fit.  Even when it isn't possible to totally avoid hash  
aggregates that spill, giving hash aggregation more memory will reliably  
improve performance (the same cannot be said for external sort  
operations, which appear to be almost unaffected by memory availability  
provided it's at least possible to get a single merge pass).  
  
The PostgreSQL 13 release notes should advise users that increasing  
hash_mem_multiplier can help with performance regressions associated  
with hash aggregation.  That can be taken care of by a later commit.  
  
Author: Peter Geoghegan  
Reviewed-By: Álvaro Herrera, Jeff Davis  
Discussion: https://postgr.es/m/20200625203629.7m6yvut7eqblgmfo@alap3.anarazel.de  
Discussion: https://postgr.es/m/CAH2-WzmD%2Bi1pG6rc1%2BCjc4V6EaFJ_qSuKCCHVnH%3DoruqD-zqow%40mail.gmail.com  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : 6023b7ea717ca04cf1bd53709d9c862db07eaefb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Jul 2020 23:21:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Jul 2020 23:21:55 +0900    

This commit makes pg_stat_statements track the total number  
of rows retrieved or affected by CREATE TABLE AS, SELECT INTO,  
CREATE MATERIALIZED VIEW and FETCH commands.  
  
Suggested-by: Pascal Legrand  
Author: Fujii Masao  
Reviewed-by: Asif Rehman  
Discussion: https://postgr.es/m/1584293755198-0.post@n3.nabble.com  

commit   : b5310e4ff6b7b0b14a5ee2443839fbf3553623ea    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Jul 2020 21:24:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Jul 2020 21:24:26 +0900    

When fast promotion was supported in 9.3, non-fast promotion became  
undocumented feature and it's basically not available for ordinary users.  
However we decided not to remove non-fast promotion at that moment,  
to leave it for a release or two for debugging purpose or as an emergency  
method because fast promotion might have some issues, and then to  
remove it later. Now, several versions were released since that decision  
and there is no longer reason to keep supporting non-fast promotion.  
Therefore this commit removes non-fast promotion.  
  
Author: Fujii Masao  
Reviewed-by: Hamid Akhtar, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/76066434-648f-f567-437b-54853b43398f@oss.nttdata.com  

commit   : 9878b643f37b1e4167f64a9941244bfabed60623    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 28 Jul 2020 23:15:47 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 28 Jul 2020 23:15:47 -0700    

Use HyperLogLog to estimate the group cardinality in a spilled  
partition. This estimate is used to choose the number of partitions if  
we recurse.  
  
The previous behavior was to use the number of tuples in a spilled  
partition as the estimate for the number of groups, which lead to  
overpartitioning. That could cause the number of batches to be much  
higher than expected (with each batch being very small), which made it  
harder to interpret EXPLAIN ANALYZE results.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/a856635f9284bc36f7a77d02f47bbb6aaf7b59b3.camel@j-davis.com  
Backpatch-through: 13  

commit   : f2130e77da51f35d37fd15a343bc1c4a4527e0fd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Jul 2020 14:44:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Jul 2020 14:44:32 +0900    

Oid is unsigned, so %u needs to be used and not %d.  The code path  
involved here is not normally reachable, so no backpatch is done.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200728015523.GA27308@telsasoft.com  

commit   : cb04ad498551dcdb91a834c2e8730cdf0b77e70a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 29 Jul 2020 16:46:58 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 29 Jul 2020 16:46:58 +1200    

Since the tableam.c code needs to make use of the syncscan.c routines  
itself, and since other block-oriented AMs might also want to use it one  
day, it didn't make sense for it to live under src/backend/access/heap.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKGLCnG%3DNEAByg6bk%2BCT9JZD97Y%3DAxKhh27Su9FeGWOKvDg%40mail.gmail.com  

commit   : c49c74d19241b1fc8da6c215ebb40fd6b71c1bff    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 17:59:16 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 17:59:16 -0700    

Missed by my commit 564ce621.  
  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : b1d79127ed875f04720d2c4677a75f43528bfe08    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 17:14:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 17:14:07 -0700    

Oversight in commit 1f39bce0, which added disk-based hash aggregation.  
  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : f36e82072c8866ba2eca08d88d1a5c3e0c3d1eb4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 16:59:01 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 16:59:01 -0700    

The planner is in fact willing to use hash aggregation when work_mem is  
not set high enough for everything to fit in memory.  This has been the  
case since commit 1f39bce0, which added disk-based hash aggregation.  
  
There are a few remaining cases in which hash aggregation is avoided as  
a matter of policy when the planner surmises that spilling will be  
necessary.  For example, callers of choose_hashed_setop() still  
conservatively avoid hash aggregation when spilling is anticipated.  
That doesn't seem like a good enough reason to mention hash aggregation  
in this context.  
  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : 0e3e1c4e1cea68073132fe817fb3a98cb5c1b805    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 29 Jul 2020 11:42:21 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 29 Jul 2020 11:42:21 +1200    

There were various unnecessary differences between Hash Agg's EXPLAIN  
ANALYZE output and Hash Join's.  Here we modify the Hash Agg output so  
that it's better aligned to Hash Join's.  
  
The following changes have been made:  
1. Start batches counter at 1 instead of 0.  
2. Always display the "Batches" property, even when we didn't spill to  
   disk.  
3. Use the text "Batches" instead of "HashAgg Batches" for text format.  
4. Use the text "Memory Usage" instead of "Peak Memory Usage" for text  
   format.  
5. Include "Batches" before "Memory Usage" in both text and non-text  
   formats.  
  
In passing also modify the "Planned Partitions" property so that we show  
it regardless of if the value is 0 or not for non-text EXPLAIN formats.  
This was pointed out by Justin Pryzby and probably should have been part  
of 40efbf870.  
  
Reviewed-by: Justin Pryzby, Jeff Davis  
Discussion: https://postgr.es/m/CAApHDvrshRnA6C0VFnu7Fb9TVvgGo80PUMm5+2DiaS1gEkPvtw@mail.gmail.com  
Backpatch-through: 13, where HashAgg batching was introduced  

commit   : d7c8576ebe3949a644c700a9f54d88e7e373a647    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 28 Jul 2020 22:52:03 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 28 Jul 2020 22:52:03 +1200    

Per complaint from Scott Ribe. Based on wording suggestion from Tom Lane.  
  
Discussion: https://postgr.es/m/1956E806-1468-4417-9A9D-235AE1D5FE1A@elevated-dev.com  
Backpatch-through: 11, where pg_jit_available() was added  

commit   : 45fdc9738b36d1068d3ad8fdb06436d6fd14436b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 28 Jul 2020 08:06:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 28 Jul 2020 08:06:44 +0530    

This adds seven methods to the output plugin API, adding support for  
streaming changes of large in-progress transactions.  
  
* stream_start  
* stream_stop  
* stream_abort  
* stream_commit  
* stream_change  
* stream_message  
* stream_truncate  
  
Most of this is a simple extension of the existing methods, with  
the semantic difference that the transaction (or subtransaction)  
is incomplete and may be aborted later (which is something the  
regular API does not really need to deal with).  
  
This also extends the 'test_decoding' plugin, implementing these  
new stream methods.  
  
The stream_start/start_stop are used to demarcate a chunk of changes  
streamed for a particular toplevel transaction.  
  
This commit simply adds these new APIs and the upcoming patch to "allow  
the streaming mode in ReorderBuffer" will use these APIs.  
  
Author: Tomas Vondra, Dilip Kumar, Amit Kapila  
Reviewed-by: Amit Kapila  
Tested-by: Neha Sharma and Mahendra Singh Thalor  
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com  

commit   : 13838740f61fc455aa4196d257efc0b761daba1f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 28 Jul 2020 11:00:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 28 Jul 2020 11:00:00 +0900    

In the case of range partitioning, get_steps_using_prefix() assumes that  
the passed-in prefix list contains at least one clause for each of the  
partition keys earlier than one specified in the passed-in  
step_lastkeyno, but the caller (ie, gen_prune_steps_from_opexps())  
didn't take it into account, which led to a server crash or incorrect  
results when the list contained no clauses for such partition keys, as  
reported in bug #16500 and #16501 from Kobayashi Hisanori.  Update the  
caller to call that function only when the list created there contains  
at least one clause for each of the earlier partition keys in the case  
of range partitioning.  
  
While at it, fix some other issues:  
  
* The list to pass to get_steps_using_prefix() is allowed to contain  
  multiple clauses for the same partition key, as described in the  
  comment for that function, but that function actually assumed that the  
  list contained just a single clause for each of middle partition keys,  
  which led to an assertion failure when the list contained multiple  
  clauses for such partition keys.  Update that function to match the  
  comment.  
* In the case of hash partitioning, partition keys are allowed to be  
  NULL, in which case the list to pass to get_steps_using_prefix()  
  contains no clauses for NULL partition keys, but that function treats  
  that case as like the case of range partitioning, which led to the  
  assertion failure.  Update the assertion test to take into account  
  NULL partition keys in the case of hash partitioning.  
* Fix a typo in a comment in get_steps_using_prefix_recurse().  
* gen_partprune_steps() failed to detect self-contradiction from  
  strict-qual clauses and an IS NULL clause for the same partition key  
  in some cases, producing incorrect partition-pruning steps, which led  
  to incorrect results of partition pruning, but didn't cause any  
  user-visible problems fortunately, as the self-contradiction is  
  detected later in the query planning.  Update that function to detect  
  the self-contradiction.  
  
Per bug #16500 and #16501 from Kobayashi Hisanori.  Patch by me, initial  
diagnosis for the reported issue and review by Dmitry Dolgov.  
Back-patch to v11, where partition pruning was introduced.  
  
Discussion: https://postgr.es/m/16500-d1613f2a78e1e090%40postgresql.org  
Discussion: https://postgr.es/m/16501-5234a9a0394f6754%40postgresql.org  

commit   : bcbf9446a2983b6452c19cc50050456be262f7c5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 27 Jul 2020 17:53:19 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 27 Jul 2020 17:53:19 -0700    

Note: This GUC was originally named enable_hashagg_disk when it appeared  
in commit 1f39bce0, which added disk-based hash aggregation.  It was  
subsequently renamed in commit 92c58fd9.  
  
Author: Peter Geoghegan  
Reviewed-By: Jeff Davis, Álvaro Herrera  
Discussion: https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel%40j-davis.com  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : a3ab7a707d9eda4b2162273348cba52252c0f0c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 15:58:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 15:58:32 +0900    

A compressed stream may end with an empty packet.  In this case  
decompression finishes before reading the empty packet and the  
remaining stream packet causes a failure in reading the following  
data.  This commit makes sure to consume such extra data, avoiding a  
failure when decompression the data.  This corner case was reproducible  
easily with a data length of 16kB, and existed since e94dd6a.  A cheap  
regression test is added to cover this case based on a random,  
incompressible string.  
  
The first attempt of this patch has allowed to find an older failure  
within the compression logic of pgcrypto, fixed by b9b6105.  This  
involved SLES 15 with z390 where a custom flavor of libz gets used.  
Bonus thanks to Mark Wong for providing access to the specific  
environment.  
  
Reported-by: Frank Gagnepain  
Author: Kyotaro Horiguchi, Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/16476-692ef7b84e5fb893@postgresql.org  
Backpatch-through: 9.5  

commit   : e971357961f2bf5bddebb3f68ba8b55954709486    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 10:28:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 10:28:06 +0900    

Some code paths dedicated to bytea used the structure for varchar.  This  
did not lead to any actual bugs, as bytea and varchar have the same  
definition, but it could become a trap if one of these definitions  
changes for a new feature or a bug fix.  
  
Issue introduced by 050710b.  
  
Author: Shenhao Wang  
Reviewed-by: Vignesh C, Michael Paquier  
Discussion: https://postgr.es/m/07ac7dee1efc44f99d7f53a074420177@G08CNEXMBPEKD06.g08.fujitsu.local  
Backpatch-through: 12  

commit   : 200f6100a9f9fc71273aeb6aceac4430f3437195    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 26 Jul 2020 14:55:52 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 26 Jul 2020 14:55:52 -0700    

Refactor hash lookups in nodeAgg.c to improve performance.  
  
Author: Andres Freund and Jeff Davis  
Discussion: https://postgr.es/m/20200612213715.op4ye4q7gktqvpuo%40alap3.anarazel.de  
Backpatch-through: 13  

commit   : 56788d2156fc32bd5737e7ac716d70e6a269b7bc    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 26 Jul 2020 21:02:45 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 26 Jul 2020 21:02:45 +1200    

Previously we would allocate blocks to parallel workers during a parallel  
sequential scan 1 block at a time.  Since other workers were likely to  
request a block before a worker returns for another block number to work  
on, this could lead to non-sequential I/O patterns in each worker which  
could cause the operating system's readahead to perform poorly or not at  
all.  
  
Here we change things so that we allocate consecutive "chunks" of blocks  
to workers and have them work on those until they're done, at which time  
we allocate another chunk for the worker.  The size of these chunks is  
based on the size of the relation.  
  
Initial patch here was by Thomas Munro which showed some good improvements  
just having a fixed chunk size of 64 blocks with a simple ramp-down near  
the end of the scan. The revisions of the patch to make the chunk size  
based on the relation size and the adjusted ramp-down in powers of two was  
done by me, along with quite extensive benchmarking to determine the  
optimal chunk sizes.  
  
For the most part, benchmarks have shown significant performance  
improvements for large parallel sequential scans on Linux, FreeBSD and  
Windows using SSDs.  It's less clear how this affects the performance of  
cloud providers.  Tests done so far are unable to obtain stable enough  
performance to provide meaningful benchmark results.  It is possible that  
this could cause some performance regressions on more obscure filesystems,  
so we may need to later provide users with some ability to get something  
closer to the old behavior.  For now, let's leave that until we see that  
it's really required.  
  
Author: Thomas Munro, David Rowley  
Reviewed-by: Ranier Vilela, Soumyadeep Chakraborty, Robert Haas  
Reviewed-by: Amit Kapila, Kirk Jamison  
Discussion: https://postgr.es/m/CA+hUKGJ_EErDv41YycXcbMbCBkztA34+z1ts9VQH+ACRuvpxig@mail.gmail.com  

commit   : 11a68e4b53ffccf336a2faf5fa380acda28e880b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Jul 2020 16:32:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Jul 2020 16:32:11 +0900    

The initial implementation of leader_pid in pg_stat_activity added by  
b025f32 took the approach to strictly print what a PGPROC entry  
includes.  In short, if a backend has been involved in parallel query at  
least once, leader_pid would remain set as long as the backend is alive.  
For a parallel group leader, this means that the field would always be  
set after it participated at least once in parallel query, and after  
more discussions this could be confusing if using for example a  
connection pooler.  
  
This commit changes the data printed so as leader_pid becomes always  
NULL for a parallel group leader, showing up a non-NULL value only for  
the parallel workers, and actually as long as a parallel query is  
running as workers are shut down once the query has completed.  
  
This does not change the definition of any catalog, so no catalog bump  
is needed.  Per discussion with Justin Pryzby, Álvaro Herrera, Julien  
Rouhaud and me.  
  
Discussion: https://postgr.es/m/20200721035145.GB17300@paquier.xyz  
Backpatch-through: 13  

commit   : 15e441972276e95639f8c3d9f5f66c2318fe9348    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jul 2020 14:50:59 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jul 2020 14:50:59 -0700    

The loop to generate seed data will exit on RAND_status(), so we don't  
need to handle the case of RAND_poll() failing separately.  Failures  
here are rare, so this a code cleanup, essentially.  
  
Daniel Gustafsson, reviewed by David Steele and Michael Paquier.  
  
Discussion: https://postgr.es/m/9B038FA5-23E8-40D0-B932-D515E1D8F66A@yesql.se  

commit   : ce4939ff70890fa658a4095b9fe457f8432b2575    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jul 2020 14:50:59 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jul 2020 14:50:59 -0700    

OpenSSL deprecated RAND_cleanup(), and OpenSSL 1.1.0 made it into a  
no-op.  Replace it with RAND_poll(), per an OpenSSL community  
recommendation.  While this has no user-visible consequences under  
OpenSSL defaults, it might help under non-default settings.  
  
Daniel Gustafsson, reviewed by David Steele and Michael Paquier.  
  
Discussion: https://postgr.es/m/9B038FA5-23E8-40D0-B932-D515E1D8F66A@yesql.se  

commit   : 0a0727ccfc5f4e2926623abe877bdc0b5bfd682e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2020 16:34:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2020 16:34:35 -0400    

At least on Linux and macOS, fread() turns out to have far higher  
per-call overhead than one could wish.  Reading 64KB of data at a time  
and then parceling it out with our own memcpy logic makes binary COPY  
from a file significantly faster --- around 30% in simple testing for  
cases with narrow text columns (on Linux ... even more on macOS).  
  
In binary COPY from frontend, there's no per-call fread(), and this  
patch introduces an extra layer of memcpy'ing, but it still manages  
to eke out a small win.  Apparently, the control-logic overhead in  
CopyGetData() is enough to be worth avoiding for small fetches.  
  
Bharath Rupireddy and Amit Langote, reviewed by Vignesh C,  
cosmetic tweaks by me  
  
Discussion: https://postgr.es/m/CALj2ACU5Bz06HWLwqSzNMN=Gupoj6Rcn_QVC+k070V4em9wu=A@mail.gmail.com  

commit   : 8a37951eebffd9bf528cb06d46127fb721d0e452    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2020 12:54:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2020 12:54:58 -0400    

Making these leakproof seems helpful since (for example) if you have a  
function f(int8) that is leakproof, you don't want it to effectively  
become non-leakproof when you apply it to an int4 or int2 column.  
But that's what happens today, since the implicit up-coercion will  
not be leakproof.  
  
Most of the coercion functions that visibly can't throw errors are  
functions that convert numeric datatypes to other, wider ones.  
Notable is that float4_numeric and float8_numeric can be marked  
leakproof; before commit a57d312a7 they could not have been.  
I also marked the functions that coerce strings to "name" as leakproof;  
that's okay today because they truncate silently, but if we ever  
reconsidered that behavior then they could no longer be leakproof.  
  
I desisted from marking rtrim1() as leakproof; it appears so right now,  
but the code seems a little too complex and perhaps subject to change,  
since it's shared with other SQL functions.  
  
Discussion: https://postgr.es/m/459322.1595607431@sss.pgh.pa.us  

commit   : 2a2494229a709b880a6db82d8b267017fccf671f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 Jul 2020 10:20:39 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 Jul 2020 10:20:39 +0530    

Commit 85c9d347 addressed a similar problem for Gather and Gather  
Merge nodes but forgot to account for nodes above parallel nodes.  This  
still works for nodes above Gather node because we shut down the workers  
for Gather node as soon as there are no more tuples.  We can do a similar  
thing for Gather Merge as well but it seems better to account for stats  
during nodes shutdown after completing the execution.  
  
Reported-by: Stéphane Lorek, Jehan-Guillaume de Rorthais  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Reviewed-by: Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/20200718160206.584532a2@firost  

commit   : 79d6d1a277ee1cdda90f9a66d7970ac3885822de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Jul 2020 15:43:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Jul 2020 15:43:56 -0400    

It's fairly silly that ignoring NOT subexpressions is TS_execute's  
default behavior.  It's wrong on its face and it encourages errors  
of omission.  Moreover, the only two remaining callers that aren't  
specifying CALC_NOT are in ts_headline calculations, and it's very  
arguable that those are bugs: if you've specified "!foo" in your  
query, why would you want to get a headline that includes "foo"?  
  
Hence, rip that out and change the default behavior to be to calculate  
NOT accurately.  As a concession to the slim chance that there is still  
somebody somewhere who needs the incorrect behavior, provide a new  
SKIP_NOT flag to explicitly request that.  
  
Back-patch into v13, mainly because it seems better to change this  
at the same time as the previous commit's rejiggering of TS_execute  
related APIs.  Any outside callers affected by this change are  
probably also affected by that one.  
  
Discussion: https://postgr.es/m/CALT9ZEE-aLotzBg-pOp2GFTesGWVYzXA3=mZKzRDa_OKnLF7Mg@mail.gmail.com  

commit   : 2f2007fbb255be178aca586780967f43885203a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Jul 2020 15:26:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Jul 2020 15:26:51 -0400    

Text search sometimes failed to find valid matches, for instance  
'!crew:A'::tsquery might fail to locate 'crew:1B'::tsvector during  
an index search.  The root of the issue is that TS_execute's callback  
functions were not changed to use ternary (yes/no/maybe) reporting  
when we made the search logic itself do so.  It's somewhat annoying  
to break that API, but on the other hand we now see that any code  
using plain boolean logic is almost certainly broken since the  
addition of phrase search.  There seem to be very few outside callers  
of this code anyway, so we'll just break them intentionally to get  
them to adapt.  
  
This allows removal of tsginidx.c's private re-implementation of  
TS_execute, since that's now entirely duplicative.  It's also no  
longer necessary to avoid use of CALC_NOT in tsgistidx.c, since  
the underlying callbacks can now do something reasonable.  
  
Back-patch into v13.  We can't change this in stable branches,  
but it seems not quite too late to fix it in v13.  
  
Tom Lane and Pavel Borisov  
  
Discussion: https://postgr.es/m/CALT9ZEE-aLotzBg-pOp2GFTesGWVYzXA3=mZKzRDa_OKnLF7Mg@mail.gmail.com  

commit   : 25244b8972a34b838c4033fe9efc1d31cba9d0e3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Jul 2020 10:34:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Jul 2020 10:34:16 +0200    

The new name has been preferred by Autoconf for a long time.  Future  
versions of Autoconf will warn about the old name.  
  
Discussion: https://www.postgresql.org/message-id/flat/e796c185-5ece-8569-248f-dd3799701be1%402ndquadrant.com  

commit   : b9b610577d7f70d959968c3697557011699b3a54    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jul 2020 17:19:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jul 2020 17:19:37 -0400    

contrib/pgcrypto mishandled the case where deflate() does not consume  
all of the offered input on the first try.  It reset the next_in pointer  
to the start of the input instead of leaving it alone, causing the wrong  
data to be fed to the next deflate() call.  
  
This has been broken since pgcrypto was committed.  The reason for the  
lack of complaints seems to be that it's fairly hard to get stock zlib  
to not consume all the input, so long as the output buffer is big enough  
(which it normally would be in pgcrypto's usage; AFAICT the input is  
always going to be packetized into packets no larger than ZIP_OUT_BUF).  
However, IBM's zlibNX implementation for AIX evidently will do it  
in some cases.  
  
I did not add a test case for this, because I couldn't find one that  
would fail with stock zlib.  When we put back the test case for  
bug #16476, that will cover the zlibNX situation well enough.  
  
While here, write deflate()'s second argument as Z_NO_FLUSH per its  
API spec, instead of hard-wiring the value zero.  
  
Per buildfarm results and subsequent investigation.  
  
Discussion: https://postgr.es/m/16476-692ef7b84e5fb893@postgresql.org  

commit   : 5733fa0fe4a73efa46801aa4189f7da17dd2b4bf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 23 Jul 2020 17:13:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 23 Jul 2020 17:13:00 +0200    

TLS 1.3 uses a different way of specifying ciphers and a different  
OpenSSL API.  PostgreSQL currently does not support setting those  
ciphers.  For now, just document this.  In the future, support for  
this might be added somehow.  
  
Reviewed-by: Jonathan S. Katz <jkatz@postgresql.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : 42dee8b8e362bae05de2234a4fc7a3aa9dacdf6f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 Jul 2020 21:10:49 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 Jul 2020 21:10:49 +1200    

Remove extra space.  Back-patch to all releases, like commit 7897e3bb.  
  
Author: Lu, Chenyang <lucy.fnst@cn.fujitsu.com>  
Discussion: https://postgr.es/m/795d03c6129844d3803e7eea48f5af0d%40G08CNEXMBPEKD04.g08.fujitsu.local  

commit   : c55040ccd017962b7b8d3fbcdc184aa90c722a21    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 23 Jul 2020 08:19:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 23 Jul 2020 08:19:07 +0530    

When wal_level=logical, write invalidations at command end into WAL so  
that decoding can use this information.  
  
This patch is required to allow the streaming of in-progress transactions  
in logical decoding.  The actual work to allow streaming will be committed  
as a separate patch.  
  
We still add the invalidations to the cache and write them to WAL at  
commit time in RecordTransactionCommit(). This uses the existing  
XLOG_INVALIDATIONS xlog record type, from the RM_STANDBY_ID resource  
manager (see LogStandbyInvalidations for details).  
  
So existing code relying on those invalidations (e.g. redo) does not need  
to be changed.  
  
The invalidations written at command end uses a new xlog record type  
XLOG_XACT_INVALIDATIONS, from RM_XACT_ID resource manager. See  
LogLogicalInvalidations for details.  
  
These new xlog records are ignored by existing redo procedures, which  
still rely on the invalidations written to commit records.  
  
The invalidations are decoded and accumulated in top-transaction, and then  
executed during replay.  This obviates the need to decode the  
invalidations as part of a commit record.  
  
Bump XLOG_PAGE_MAGIC, since this introduces XLOG_XACT_INVALIDATIONS.  
  
Author: Dilip Kumar, Tomas Vondra, Amit Kapila  
Reviewed-by: Amit Kapila  
Tested-by: Neha Sharma and Mahendra Singh Thalor  
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com  

commit   : 38f60f174e3279069b5547b5f4015eb4a8492037    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jul 2020 08:29:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jul 2020 08:29:08 +0900    

This reverts commit 9e10898, after finding out that buildfarm members  
running SLES 15 on z390 complain on the compression and decompression  
logic of the new test: pipistrelles, barbthroat and steamerduck.  
  
Those hosts are visibly using hardware-specific changes to improve zlib  
performance, requiring more investigation.  
  
Thanks to Tom Lane for the discussion.  
  
Discussion: https://postgr.es/m/20200722093749.GA2564@paquier.xyz  
Backpatch-through: 9.5  

commit   : a57d312a7706321d850faa048a562a0c0c01b835    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jul 2020 19:19:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jul 2020 19:19:44 -0400    

Add infinities that behave the same as they do in the floating-point  
data types.  Aside from any intrinsic usefulness these may have,  
this closes an important gap in our ability to convert floating  
values to numeric and/or replace float-based APIs with numeric.  
  
The new values are represented by bit patterns that were formerly  
not used (although old code probably would take them for NaNs).  
So there shouldn't be any pg_upgrade hazard.  
  
Patch by me, reviewed by Dean Rasheed and Andrew Gierth  
  
Discussion: https://postgr.es/m/606717.1591924582@sss.pgh.pa.us  

commit   : 9e108984fb35d8f9e2c2bffa10c0034f9161e802    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jul 2020 14:52:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jul 2020 14:52:23 +0900    

A compressed stream may end with an empty packet, and PGP decompression  
finished before reading this empty packet in the remaining stream.  This  
caused a failure in pgcrypto, handling this case as corrupted data.  
This commit makes sure to consume such extra data, avoiding a failure  
when decompression the entire stream.  This corner case was reproducible  
with a data length of 16kB, and existed since its introduction in  
e94dd6a.  A cheap regression test is added to cover this case.  
  
Thanks to Jeff Janes for the extra investigation.  
  
Reported-by: Frank Gagnepain  
Author: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/16476-692ef7b84e5fb893@postgresql.org  
Backpatch-through: 9.5  

commit   : a5073871ea655e37759f22f30c4c70359ad9759b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 22 Jul 2020 16:38:20 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 22 Jul 2020 16:38:20 +1200    

convutils.pm used implicit conversion of undefined value to integer  
zero.  Some of conversion scripts are susceptible to regexp greediness.  
Fix, avoiding whitespace changes in the output.  Also update ICU URLs  
that moved.  
  
No need to back-patch, because the output of these scripts is also in  
the source tree so we shouldn't need to rerun them on back-branches.  
  
Author: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJ7SEGLbj%3D%3DTQCcyKRA9aqj8%2B6L%3DexSq1y25TA%3DWxLziQ%40mail.gmail.com  

commit   : e47c2602aa4d35a4e3eb6ada40454c6c0f1279bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jul 2020 10:16:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jul 2020 10:16:21 +0900    

An incorrect reference to SHA-1 was present.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/FE26C953-FA87-4BB9-9105-AA1F8705B0D0@yesql.se  

commit   : bd0d893aa7aa303d7f344e267a9d3e53b0219491    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 19:40:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 19:40:44 -0400    

Since commit 044c99bc5, eqjoinsel passes the passed-in collation  
to any operators it invokes.  However, neqjoinsel failed to pass  
on whatever collation it got, so that if we invoked a  
collation-dependent operator via that code path, we'd get "could not  
determine which collation to use for string comparison" or the like.  
  
Per report from Justin Pryzby.  Back-patch to v12, like the previous  
commit.  
  
Discussion: https://postgr.es/m/20200721191606.GL5748@telsasoft.com  

commit   : 4a70f829d86cb8dbd68f561720e6329f5e818c94    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 21 Jul 2020 15:50:58 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 21 Jul 2020 15:50:58 -0700    

Holding just a buffer pin (with no buffer lock) on an nbtree buffer/page  
provides very weak guarantees, especially compared to heapam, where it's  
often safe to read a page while only holding a buffer pin.  This commit  
has Valgrind enforce the following rule: it is never okay to access an  
nbtree buffer without holding both a pin and a lock on the buffer.  
  
A draft version of this patch detected questionable code that was  
cleaned up by commits fa7ff642 and 7154aa16.  The code in question used  
to access an nbtree buffer page's special/opaque area with no buffer  
lock (only a buffer pin).  This practice (which isn't obviously unsafe)  
is hereby formally disallowed in nbtree.  There doesn't seem to be any  
reason to allow it, and banning it keeps things simple for Valgrind.  
  
The new checks are implemented by adding custom nbtree client requests  
(located in LockBuffer() wrapper functions); these requests are  
"superimposed" on top of the generic bufmgr.c Valgrind client requests  
added by commit 1e0dfd16.  No custom resource management cleanup code is  
needed to undo the effects of marking buffers as non-accessible under  
this scheme.  
  
Author: Peter Geoghegan  
Reviewed-By: Anastasia Lubennikova, Georgios Kokolatos  
Discussion: https://postgr.es/m/CAH2-WzkLgyN3zBvRZ1pkNJThC=xi_0gpWRUb_45eexLH1+k2_Q@mail.gmail.com  

commit   : 670c0a1d474bf296dbcc1d6de912d4841f2ed643    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 15:19:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 15:19:46 -0400    

Rather than always insisting on an exact match of the type OID in the  
data to the element type or column type we expect, complain only when  
both OIDs fall within the manually-assigned range.  This acknowledges  
the reality that user-defined types don't have stable OIDs, while  
still preserving some of the mistake-detection value of the old test.  
  
(It's not entirely clear whether to error if one OID is manually  
assigned and the other isn't.  But perhaps that case could arise in  
cross-version cases where a former extension type has been imported  
into core, so I let it pass.)  
  
This change allows us to remove the prohibition on binary transfer  
of user-defined arrays and composites in the recently-landed support  
for binary logical replication (commit 9de77b545).  We can just  
unconditionally drop that check, since if the client has asked for  
binary transfer it must be >= v14 and must have this change.  
  
Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com  

commit   : 606c3845988ddd9497cbbbf6fc559b91c76ed65d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2020 13:11:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2020 13:11:23 -0400    

Author: Jürgen Purtz <juergen@purtz.de>  
Discussion: https://postgr.es/m/95f90a5d-7692-701d-2c0c-0c88eb5cea7d@purtz.de  

commit   : a0b2d583db9f040e2c156570b741e46bc33c6aec    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2020 13:09:42 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2020 13:09:42 -0400    

Add "(process)" qualifier to two terms, remove self-reference in one  
term.  
  
Author: Jürgen Purtz <juergen@purtz.de>  
Discussion: https://postgr.es/m/95f90a5d-7692-701d-2c0c-0c88eb5cea7d@purtz.de  

commit   : fc032bed2fb809ee69eaf2fece349f65274c876f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 13:03:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 13:03:48 -0400    

The bug fixed in commit 72eab84a5 would not have occurred if initdb  
had a less surprising rule about which columns should be marked  
NOT NULL by default.  Let's make that rule be strictly that the  
column must be fixed-width and its predecessors must be fixed-width  
and NOT NULL, removing the hacky and unsafe exceptions for oidvector  
and int2vector.  
  
Since we do still want all existing oidvector and int2vector columns  
to be marked NOT NULL, we have to put BKI_FORCE_NOT_NULL labels on  
them.  But making this less magic and more documented seems like a  
good idea, even if it's a shade more verbose.  
  
I didn't bump catversion since the initial catalog contents are  
not actually changed by this patch.  Note however that the  
contents of postgres.bki do change, and feeding an old copy of  
that to a new backend will produce wrong results.  
  
Discussion: https://postgr.es/m/204760.1595181800@sss.pgh.pa.us  

commit   : 3e66019f15549d3e1e13da665b2549684061d630    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 12:38:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2020 12:38:08 -0400    

The executor checks for this error, and so does the bootstrap catalog  
loader, but we never checked for it in retail catalog manipulations.  
The folly of that has now been exposed, so let's add assertions  
checking it.  Checking in CatalogTupleInsert[WithInfo] and  
CatalogTupleUpdate[WithInfo] should be enough to cover this.  
  
Back-patch to v10; the aforesaid functions didn't exist before that,  
and it didn't seem worth adapting the patch to the oldest branches.  
But given the risk of JIT crashes, I think we certainly need this  
as far back as v11.  
  
Pre-v13, we have to explicitly exclude pg_subscription.subslotname  
and pg_subscription_rel.srsublsn from the checks, since they are  
mismarked.  (Even if we change our mind about applying BKI_FORCE_NULL  
in the branch tips, it doesn't seem wise to have assertions that  
would fire in existing databases.)  
  
Discussion: https://postgr.es/m/298837.1595196283@sss.pgh.pa.us  

commit   : c273d9d8ce412a475082b1729462845d2abb5ae8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Jul 2020 12:05:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Jul 2020 12:05:07 +0900    

This corrects and simplifies $subject in a number of ways:  
- Remove from the completion the pre-9.0 grammar still supported for  
compatibility purposes.  This simplifies the code, and allows to extend  
it more easily with new patterns.  
- Add completion for the options of FORMAT within a WITH clause.  
- Complete WHERE and WITH clauses correctly depending on if TO or FROM  
are used, WHERE being only available with COPY FROM.  
  
Author: Vignesh C, Michael Paquier  
Reviewed-by: Ahsan Hadi  
Discussion: https://postgr.es/m/CALDaNm3zWr=OmxeNqOqfT=uZTSdam_j-gkX94CL8eTNfgUtf6A@mail.gmail.com  

commit   : a4faef8f8fe1493397679c014cf11a6e27c0f1e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 22:03:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 22:03:18 -0400    

Many situations where the offset is infinity were not handled sanely.  
We should generally allow the val versus base +/- offset comparison to  
proceed according to the normal rules of IEEE arithmetic; however, we  
must do something special for the corner cases where base +/- offset  
would produce NaN due to subtracting two like-signed infinities.  
That corresponds to asking which values infinitely precede +inf or  
infinitely follow -inf, which should certainly be true of any finite  
value or of the opposite-signed infinity.  After some discussion it  
seems that the best decision is to make it true of the same-signed  
infinity as well, ie, just return constant TRUE if the calculation  
would produce a NaN.  
  
(We could write this with a bit less code by subtracting anyway,  
and then checking for a NaN result.  However, I prefer this  
formulation because it'll be easier to transpose into numeric.c.)  
  
Although this seems like clearly a bug fix with respect to finite  
values, it is less obviously correct for infinite values.  Between  
that and the fact that the whole issue only arises for very strange  
window specifications (e.g. RANGE BETWEEN 'inf' PRECEDING AND 'inf'  
PRECEDING), I'll desist from back-patching.  
  
Noted by Dean Rasheed.  
  
Discussion: https://postgr.es/m/3393130.1594925893@sss.pgh.pa.us  

commit   : 4fb6aeb4f6e807c8ce3e140d2d2281f50eb6fb1a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 19:44:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 19:44:41 -0400    

This is more consistent with the IEEE 754 spec and our treatment of  
NaNs elsewhere; in particular, the case has always acted that way in  
"numeric" arithmetic.  
  
Noted by Dean Rasheed.  
  
Discussion: https://postgr.es/m/3421746.1594927785@sss.pgh.pa.us  

commit   : 6ca7cd89a2d1998b16e8168dda62d43a9e0fdaff    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 20 Jul 2020 16:03:38 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 20 Jul 2020 16:03:38 -0700    

Strengthen the LockBuffer() assertion that verifies BufferIsValid() by  
making it verify BufferIsPinned() instead.  Do the same in nearby  
related functions.  
  
There is probably not much chance that anybody will try to lock a buffer  
that is not already pinned, but we might as well make sure of that.  

commit   : 0fa0b487b5d75d2b8576dec86a317212542642b8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 14:55:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 14:55:56 -0400    

The code has always set this column to NULL when it's not valid,  
but the catalog header's description failed to reflect that,  
as did the SGML docs, as did some of the code.  To prevent future  
coding errors of the same ilk, let's hide the field from C code  
as though it were variable-length (which, in a sense, it is).  
  
As with commit 72eab84a5, we can only fix this cleanly in HEAD  
and v13; the problem extends further back but we'll need some  
klugery in the released branches.  
  
Discussion: https://postgr.es/m/367660.1595202498@sss.pgh.pa.us  

commit   : d5daae47db5e8a61ce6ed7afaa3e3a99af108c06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 13:40:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jul 2020 13:40:16 -0400    

Commit b9c130a1f failed to apply the publisher-to-subscriber column  
mapping while checking which columns were updated.  Perhaps less  
significantly, it didn't exclude dropped columns either.  This could  
result in an incorrect updated-columns bitmap and thus wrong decisions  
about whether to fire column-specific triggers on the subscriber while  
applying updates.  In HEAD (since commit 9de77b545), it could also  
result in accesses off the end of the colstatus array, as detected by  
buildfarm member skink.  Fix the logic, and adjust 003_constraints.pl  
so that the problem is exposed in unpatched code.  
  
In HEAD, also add some assertions to check that we don't access off  
the ends of these newly variable-sized arrays.  
  
Back-patch to v10, as b9c130a1f was.  
  
Discussion: https://postgr.es/m/CAH2-Wz=79hKQ4++c5A060RYbjTHgiYTHz=fw6mptCtgghH2gJA@mail.gmail.com  

commit   : d98c08cdc638a290d80fb69b20b8288c3924d875    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 20 Jul 2020 13:59:50 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 20 Jul 2020 13:59:50 +0300    

All functions provided by this extension are PARALLEL SAFE.  
  
Discussion: https://postgr.es/m/AM5PR0901MB1587E47B1ACF23C6089DFCA3FD9B0%40AM5PR0901MB1587.eurprd09.prod.outlook.com  
Author: Steven Winfield  

commit   : c3fe108c025e4a080315562d4c15ecbe3f00405e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 20 Jul 2020 13:30:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 20 Jul 2020 13:30:18 +0900    

max_slot_wal_keep_size that was added in v13 and wal_keep_segments are  
the GUC parameters to specify how much WAL files to retain for  
the standby servers. While max_slot_wal_keep_size accepts the number of  
bytes of WAL files, wal_keep_segments accepts the number of WAL files.  
This difference of setting units between those similar parameters could  
be confusing to users.  
  
To alleviate this situation, this commit renames wal_keep_segments to  
wal_keep_size, and make users specify the WAL size in it instead of  
the number of WAL files.  
  
There was also the idea to rename max_slot_wal_keep_size to  
max_slot_wal_keep_segments, in the discussion. But we have been moving  
away from measuring in segments, for example, checkpoint_segments was  
replaced by max_wal_size. So we concluded to rename wal_keep_segments  
to wal_keep_size.  
  
Back-patch to v13 where max_slot_wal_keep_size was added.  
  
Author: Fujii Masao  
Reviewed-by: Álvaro Herrera, Kyotaro Horiguchi, David Steele  
Discussion: https://postgr.es/m/574b4ea3-e0f9-b175-ead2-ebea7faea855@oss.nttdata.com  

commit   : 0bead9af484c1d0a67e690fda47011addaa5bc9d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jul 2020 08:48:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jul 2020 08:48:26 +0530    

The logical decoding infrastructure needs to know which top-level  
transaction the subxact belongs to, in order to decode all the  
changes. Until now that might be delayed until commit, due to the  
caching (GPROC_MAX_CACHED_SUBXIDS), preventing features requiring  
incremental decoding.  
  
So we also write the assignment info into WAL immediately, as part  
of the next WAL record (to minimize overhead) only when wal_level=logical.  
We can not remove the existing XLOG_XACT_ASSIGNMENT WAL as that is  
required for avoiding overflow in the hot standby snapshot.  
  
Bump XLOG_PAGE_MAGIC, since this introduces XLR_BLOCK_ID_TOPLEVEL_XID.  
  
Author: Tomas Vondra, Dilip Kumar, Amit Kapila  
Reviewed-by: Amit Kapila  
Tested-by: Neha Sharma and Mahendra Singh Thalor  
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com  

commit   : d05b172a760e0ccb3008a2144f96053720000b12    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 20 Jul 2020 11:55:50 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 20 Jul 2020 11:55:50 +0900    

There was no easy way to find how many times generic and custom plans  
have been executed for a prepared statement. This commit exposes those  
numbers of times in pg_prepared_statements view.  
  
Author: Atsushi Torikoshi, Kyotaro Horiguchi  
Reviewed-by: Tatsuro Yamada, Masahiro Ikeda, Fujii Masao  
Discussion: https://postgr.es/m/CACZ0uYHZ4M=NZpofH6JuPHeX=__5xcDELF8hT8_2T+R55w4RQw@mail.gmail.com  

commit   : 044dc7b964147ec6303d59320fb743693b22af30    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jul 2020 07:45:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jul 2020 07:45:26 +0530    

Author: Vignesh C  
Reviewed-by: James Coleman  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CALDaNm0WjZqRvdeL59ZfYH0o4mLbKQ23jm-bnjXcFzgpANx55g@mail.gmail.com  

commit   : a766d6ca22ac7c233e69c896ae0c5f19de916db4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 19 Jul 2020 16:12:51 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 19 Jul 2020 16:12:51 -0700    

Valgrind builds with assertions enabled sometimes perform a  
theoretically unsafe page access inside an assertion in  
heapam_tuple_lock().  This happened when the eval-plan-qual isolation  
test ran one of the permutations added by commit a2418f9e238.  
  
Avoid complaints from Valgrind by moving the assertion ever so slightly.  
This is minor cleanup for commit 1e0dfd16, which added Valgrind buffer  
access instrumentation.  
  
No backpatch, since this only happens within an assertion, and seems  
very unlikely to cause any real problems even with assert-enabled  
builds.  

commit   : 46ef520b9566d9eccb095ceafa53e5c305cf80b9    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 19 Jul 2020 09:46:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 19 Jul 2020 09:46:44 -0700    

Make PinBuffer() mark buffers as defined to Valgrind unconditionally,  
including when the buffer header spinlock must be acquired.  Failure to  
handle that case could lead to false positive reports from Valgrind.  
  
This theoretically creates a risk that we'll mark buffers defined even  
when external callers don't end up with a buffer pin.  That seems  
perfectly acceptable, though, since in general we make no guarantees  
about buffers that are unsafe to access being reliably marked as unsafe.  
  
Oversight in commit 1e0dfd16, which added valgrind buffer access  
instrumentation.  

commit   : 72eab84a565cbc0677bf8907cd4bfaddf064bd64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jul 2020 12:37:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jul 2020 12:37:23 -0400    

Due to the layout of this catalog, subslotname has to be explicitly  
marked BKI_FORCE_NULL, else initdb will default to the assumption  
that it's non-nullable.  Since, in fact, CREATE/ALTER SUBSCRIPTION  
will store null values there, the existing marking is just wrong,  
and has been since this catalog was invented.  
  
We haven't noticed because not much in the system actually depends  
on attnotnull being truthful.  However, JIT'ed tuple deconstruction  
does depend on that in some cases, allowing crashes or wrong answers  
in queries that inspect pg_subscription.  Commit 9de77b545 quite  
accidentally exposed this on the buildfarm members that force JIT  
activation.  
  
Back-patch to v13.  The problem goes further back, but we cannot  
force initdb in released branches, so some klugier solution will  
be needed there.  Before working on that, push this simple fix  
to try to get the buildfarm back to green.  
  
Discussion: https://postgr.es/m/4118109.1595096139@sss.pgh.pa.us  

commit   : 4d3db13621be64fbac2faf7c01c4879d20885c1b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 19 Jul 2020 12:14:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 19 Jul 2020 12:14:42 +0200    

This avoids deprecation warnings from newer OpenSSL versions (3.0.0 in  
particular).  
  
Discussion: https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se  

commit   : 9b14280b207053f8b09e20b5719785ec4413b9d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2020 14:58:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2020 14:58:18 -0400    

This header hasn't changed recently, so the fact that it now fails  
headerscheck/cpluspluscheck testing must be due to changes in what  
it includes.  Probably f21916791 is to blame, but I didn't try to  
verify that.  
  
Discussion: https://postgr.es/m/3699703.1595016554@sss.pgh.pa.us  

commit   : 9de77b5453130242654ff0b30a551c9c862ed661    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2020 12:44:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2020 12:44:51 -0400    

This patch adds a "binary" option to CREATE/ALTER SUBSCRIPTION.  
When that's set, the publisher will send data using the data type's  
typsend function if any, rather than typoutput.  This is generally  
faster, if slightly less robust.  
  
As committed, we won't try to transfer user-defined array or composite  
types in binary, for fear that type OIDs won't match at the subscriber.  
This might be changed later, but it seems like fit material for a  
follow-on patch.  
  
Dave Cramer, reviewed by Daniel Gustafsson, Petr Jelinek, and others;  
adjusted some by me  
  
Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com  

commit   : 9add405014f8e47e038af7124528b7601249a2ac    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 22:43:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 22:43:35 +0900    

This updates some URLs that are redirections, mostly to an equivalent  
using https.  One URL referring to generalized partial indexes was  
outdated.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200717.121308.1369606287593685396.horikyota.ntt@gmail.com  
Backpatch-through: 9.5  

commit   : f41fbee7e704947fd1d2241f35bc8d0e37705919    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 18 Jul 2020 09:57:23 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 18 Jul 2020 09:57:23 +0530    

Author: Dave Cramer  
Reviewed-by: David G. Johnston  
Discussion: https://postgr.es/m/CADK3HHL8do4Fp1bsymgNasx375njV3AR7zY3UgYwzbL_Dx-n2Q@mail.gmail.com  

commit   : df7c5cb16e8fcf960e3302355fa6547fba428f5e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 18 Jul 2020 09:47:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 18 Jul 2020 09:47:38 +0530    

Author: Dave Cramer  
Reviewed-by: David G. Johnston  
Discussion: https://postgr.es/m/CADK3HHL8do4Fp1bsymgNasx375njV3AR7zY3UgYwzbL_Dx-n2Q@mail.gmail.com  

commit   : b74d449a02b3c972051b1847f3915128da8775dc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 10:42:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 10:42:41 +0900    

The WHERE clause introduced by 31f3817 was not described.  While on it,  
split the grammar of \copy FROM and TO into two distinct parts for  
clarity as they support different set of options.  
  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm3zWr=OmxeNqOqfT=uZTSdam_j-gkX94CL8eTNfgUtf6A@mail.gmail.com  
Backpatch-through: 12  

commit   : 564ce62164cd57c0311752ae07ec10439c78d599    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 18:24:23 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 18:24:23 -0700    

The term "hash_mem" will take on new significance when pending work to  
add a new hash_mem_multiplier GUC is committed.  Rename a local variable  
that happens to have been called hash_mem now to avoid confusion.  

commit   : 1e0dfd166b3fa7fc79e4fad73b6fae056bab598a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 17:49:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 17:49:45 -0700    

Teach Valgrind memcheck to maintain the "defined-ness" of each shared  
buffer based on whether the backend holds at least one pin at the point  
it is accessed by access method code.  Bugs like the one fixed by commit  
b0229f26 can be detected using this new instrumentation.  
  
Note that backends running with Valgrind naturally have their own  
independent ideas about whether any given byte in shared memory is safe  
or unsafe to access.  There is no risk that concurrent access by  
multiple backends to the same shared memory will confuse Valgrind's  
instrumentation, because everything already works at the process level  
(or at the memory mapping level, if you prefer).  
  
Author: Álvaro Herrera, Peter Geoghegan  
Reviewed-By: Anastasia Lubennikova  
Discussion: https://postgr.es/m/20150723195349.GW5596@postgresql.org  
Discussion: https://postgr.es/m/CAH2-WzkLgyN3zBvRZ1pkNJThC=xi_0gpWRUb_45eexLH1+k2_Q@mail.gmail.com  

commit   : f009591d6eddbeece955aab70c35e7002fd01aec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2020 13:03:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2020 13:03:50 -0400    

pg_dump produces custom-format archive files that lack data offsets  
when it is unable to seek its output.  Up to now that's been a hazard  
for pg_restore.  But if pg_restore is able to seek in the archive  
file, there is no reason to throw up our hands when asked to restore  
data blocks out of order.  Instead, whenever we are searching for a  
data block, record the locations of the blocks we passed over (that  
is, fill in the missing data-offset fields in our in-memory copy of  
the TOC data).  Then, when we hit a case that requires going  
backwards, we can just seek back.  
  
Also track the furthest point that we've searched to, and seek back  
to there when beginning a search for a new data block.  This avoids  
possible O(N^2) time consumption, by ensuring that each data block  
is examined at most twice.  (On Unix systems, that's at most twice  
per parallel-restore job; but since Windows uses threads here, the  
threads can share block location knowledge, reducing the amount of  
duplicated work.)  
  
We can also improve the code a bit by using fseeko() to skip over  
data blocks during the search.  
  
This is all of some use even in simple restores, but it's really  
significant for parallel pg_restore.  In that case, we require  
seekability of the input already, and we will very probably need  
to do out-of-order restores.  
  
Back-patch to v12, as this fixes a regression introduced by commit  
548e50976.  Before that, parallel restore avoided requesting  
out-of-order restores, so it would work on a data-offset-less  
archive.  Now it will again.  
  
Ideally this patch would include some test coverage, but there are  
other open bugs that need to be fixed before we can extend our  
coverage of parallel restore very much.  Plan to revisit that later.  
  
David Gilman and Tom Lane; reviewed by Justin Pryzby  
  
Discussion: https://postgr.es/m/CALBH9DDuJ+scZc4MEvw5uO-=vRyR2=QF9+Yh=3hPEnKHWfS81A@mail.gmail.com  

commit   : a8d0732ac2b5527ce47cce5b325f8df93f4d19cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2020 12:14:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2020 12:14:28 -0400    

We do not really need to track the file position by hand.  We were  
already relying on ftello() whenever the archive file is seekable,  
while if it's not seekable we don't need the file position info  
anyway because we're not going to be able to re-write the TOC.  
  
Moreover, that tracking was buggy since it failed to account for  
the effects of fseeko().  Somewhat remarkably, that seems not to  
have made for any live bugs up to now.  We could fix the oversights,  
but it seems better to just get rid of the whole error-prone mess.  
  
In itself this is merely code cleanup.  However, it's necessary  
infrastructure for an upcoming bug-fix patch (because that code  
*does* need valid file position after fseeko).  The bug fix  
needs to go back as far as v12; hence, back-patch that far.  
  
Discussion: https://postgr.es/m/CALBH9DDuJ+scZc4MEvw5uO-=vRyR2=QF9+Yh=3hPEnKHWfS81A@mail.gmail.com  

commit   : 5da8bf8bbb5c119d4bd767dbdfaf10efd348c0fd    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 09:50:48 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 09:50:48 -0700    

There is no advantage to attempting deduplication for a unique index  
during CREATE INDEX, since there cannot possibly be any duplicates.  
Doing so wastes cycles due to unnecessary copying.  Make sure that we  
avoid it consistently.  
  
We already avoided unique index deduplication in the case where there  
were some spool2 tuples to merge.  That didn't account for the fact that  
spool2 is removed early/unset in the common case where it has no tuples  
that need to be merged (i.e. it failed to account for the "spool2 turns  
out to be unnecessary" optimization in _bt_spools_heapscan()).  
  
Oversight in commit 0d861bbb, which added nbtree deduplication  
  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : 7fe3083f4cc9cb213f99deecf1bf775a9270b3b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2020 11:03:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2020 11:03:55 -0400    

We had two occurrences of "Mitteleuropäische Zeit" in Europe.txt,  
though the corresponding entries in Default were spelled  
"Mitteleuropaeische Zeit".  Standardize on the latter spelling to  
avoid questions of which encoding to use.  
  
While here, correct a couple of other trivial inconsistencies between  
the Default file and the supposedly-matching entries in the *.txt  
files, as exposed by some checking with comm(1).  Also, add BDST to  
the Europe.txt file; it previously was only listed in Default.  
None of this has any direct functional effect.  
  
Per complaint from Christoph Berg.  As usual for timezone data patches,  
apply to all branches.  
  
Discussion: https://postgr.es/m/20200716100743.GE3534683@msg.df7cb.de  

commit   : 20ef35516328350a244d22b590e37f24ea958526    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 17 Jul 2020 15:16:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 17 Jul 2020 15:16:13 +0200    

commit   : 44f34365b81fd1be575d212593c2bd9c47060aa6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 17 Jul 2020 15:07:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 17 Jul 2020 15:07:54 +0200    

commit   : 01160a3de3d89346c9597414ff85416b77f5391f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2020 09:02:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2020 09:02:44 +0530    

Commit 1e53fe0e70 has unified the usage of the config-file reload flag by  
using the same signal handler function for the SIGHUP signal at many places  
in the code.  By mistake, it used the wrong SIGNAL in apply launcher  
process for the SIGHUP signal handler function.  
  
Author: Bharath Rupireddy  
Reviewed-by: Dilip Kumar  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CALj2ACVzHCRnS20bOiEHaLtP5PVBENZQn4khdsSJQgOv_GM-LA@mail.gmail.com  

commit   : cdc7169509113018cc389da740e950c587b5751f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Jul 2020 14:57:50 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Jul 2020 14:57:50 +1200    

This representation saves 8 bytes per tuple compared to HeapTuple, and  
avoids the need to allocate, copy and free on the receiving side.  
  
Gather can emit the returned MinimalTuple directly, but GatherMerge now  
needs to make an explicit copy because it buffers multiple tuples at a  
time.  That should be no worse than before.  
  
Reviewed-by: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKG%2B8T_ggoUTAE-U%3DA%2BOcPc4%3DB0nPPHcSfffuQhvXXjML6w%40mail.gmail.com  

commit   : d2bddc2500fb74d56e5bc53a1cfa269e2e846510    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Jul 2020 14:33:00 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Jul 2020 14:33:00 +1200    

This allows the huge page size to be set explicitly.  The default is 0,  
meaning it will use the system default, as before.  
  
Author: Odin Ugedal <odin@ugedal.com>  
Discussion: https://postgr.es/m/20200608154639.20254-1-odin%40ugedal.com  

commit   : d66b23b032d75614e1be47ca182020960d89206d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 16 Jul 2020 14:48:37 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 16 Jul 2020 14:48:37 -0400    

Windows has junction points which function as symbolic links for  
directories. This patch introduces a new function TestLib::dir_symlink()  
which creates a junction point on Windows and a standard Unix type  
symbolic link elsewhere.  
  
The function TestLib::perl2host is also modified, first to use cygpath  
where it's available (e.g. msys2) and second to allow it to succeed if  
the gandparent directory exists but the parent does not.  
  
Given these changes the only symlink tests that need to be skipped on  
Windows are those related to permissions or to use of readlink. The  
relevant tests for pg_basebackup and pg_rewind are therefore adjusted  
accordingly.  
  
Andrew Dunstan, reviewed by Peter Eisentraut and Michael Paquier.  
  
Discussion: https://postgr.es/m/c50a646c-d9bb-7c62-a4bf-8256ff6ff338@2ndquadrant.com  

commit   : 932f9fb504a57f296cf698d15bd93462ddfe2776    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jul 2020 15:52:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jul 2020 15:52:37 +0900    

pg_test_fsync has always opened files using the text mode on Windows, as  
this is the default mode used if not enforced by _setmode().  
  
This fixes a failure when running pg_test_fsync down to 12 because  
O_DSYNC and the text mode are not able to work together nicely.  We  
fixed the handling of O_DSYNC in 12~ for the tool by switching to the  
concurrent-safe version of fopen() in src/port/ with 0ba06e0.  And  
40cfe86, by enforcing the text mode for compatibility reasons if O_TEXT  
or O_BINARY are not specified by the caller, broke pg_test_fsync.  For  
all versions, this avoids any translation overhead, and pg_test_fsync  
should test binary writes, so it is a gain in all cases.  
  
Note that O_DSYNC is still not handled correctly in ~11, leading to  
pg_test_fsync to show insanely high numbers for open_datasync() (using  
this property it is easy to notice that the binary mode is much  
faster).  This would require a backpatch of 0ba06e0 and 40cfe86, which  
could potentially break existing applications, so this is left out.  
  
There are no TAP tests for this tool yet, so I have checked all builds  
manually using MSVC.  We could invent a new option to run a single  
transaction instead of using a duration of 1s to make the tests a  
maximum short, but this is left as future work.  
  
Thanks to Bruce Momjian for the discussion.  
  
Reported-by: Jeff Janes  
Author: Michael Paquier  
Discussion: https://postgr.es/m/16526-279ded30a230d275@postgresql.org  
Backpatch-through: 9.5  

commit   : ed2c7f65bd9f15f8f7cd21ad61602f983b1e72e9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2020 14:23:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2020 14:23:22 +0200    

Similar to daa9fe8a5264a3f192efa5ddee8fb011ad9da365, instead of  
repeating the almost same large query in each version branch, use one  
query and add a few columns to the SELECT list depending on the  
version.  This saves a lot of duplication.  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/6594334b-40fd-14f1-6bc5-877afa3feed5@2ndquadrant.com  

commit   : 1d09fb1f0a9c7edc3298104fc4350e49169f6f2a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 15:17:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 15:17:23 +0900    

When working with an online source cluster, pg_rewind gets a list of all  
the files in the source data directory using a WITH RECURSIVE query,  
returning a NULL result for a file's metadata if it gets removed between  
the moment it is listed in a directory and the moment its metadata is  
obtained with pg_stat_file() (say a recycled WAL segment).  The query  
result was processed in such a way that for each tuple we checked only  
that the first file's metadata was NULL.  This could have two  
consequences, both resulting in a failure of the rewind:  
- If the first tuple referred to a removed file, all files from the  
source would be ignored.  
- Any file actually missing would not be considered as such.  
  
While on it, rework slightly the code so as no values are saved if we  
know that a file is going to be skipped.  
  
Issue introduced by b36805f, so backpatch down to 9.5.  
  
Author: Justin Pryzby, Michael Paquier  
Reviewed-by: Daniel Gustafsson, Masahiko Sawada  
Discussion: https://postgr.es/m/20200713061010.GC23581@telsasoft.com  
Backpatch-through: 9.5  

commit   : e949137397383de58f0c566f5a92b017343c5269    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 09:42:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 09:42:21 +0900    

One change for getObjectIdentity() has been missed in 2a10fdc, causing  
the module to not compile properly.  This was actually the only problem,  
and it happens that it is easy enough to check the compilation of the  
module on Debian after installing libselinux1-dev.  
  
Per buildfarm member rhinoceros.  

commit   : 2a10fdc4307a667883f7a3369cb93a721ade9680    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 09:03:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 09:03:10 +0900    

When using the following functions, users could see various types of  
errors of the type "cache lookup failed for OID XXX" with elog(), that  
can only be used for internal errors:  
* pg_describe_object()  
* pg_identify_object()  
* pg_identify_object_as_address()  
  
The set of APIs managing object addresses for all object types are made  
smarter by gaining a new argument "missing_ok" that allows any caller to  
control if an error is raised or not on an undefined object.  The SQL  
functions listed above are changed to handle the case where an object is  
missing.  
  
Regression tests are added for all object types for the cases where  
these are undefined.  Before this commit, these cases failed with cache  
lookup errors, and now they basically return NULL (minus the name of the  
object type requested).  
  
Author: Michael Paquier  
Reviewed-by: Aleksander Alekseev, Dmitry Dolgov, Daniel Gustafsson,  
Álvaro Herrera, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com  

commit   : 689696c7110f148ede8004aae50d7543d05b5587    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jul 2020 18:56:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jul 2020 18:56:49 -0400    

reparameterize_path_by_child() failed to reparameterize BitmapAnd  
and BitmapOr paths.  This matters only if such a path is chosen as  
the inside of a nestloop partition-wise join, where we have to pass  
in parameters from the outside of the nestloop.  If that did happen,  
we generated a bad plan that would likely lead to crashes at execution.  
  
This is not entirely reparameterize_path_by_child()'s fault though;  
it's the victim of an ancient decision (my ancient decision, I think)  
to not bother filling in param_info in BitmapAnd/Or path nodes.  That  
caused the function to believe that such nodes and their children  
contain no parameter references and so need not be processed.  
  
In hindsight that decision looks pretty penny-wise and pound-foolish:  
while it saves a few cycles during path node setup, we do commonly  
need the information later.  In particular, by reversing the decision  
and requiring valid param_info data in all nodes of a bitmap path  
tree, we can get rid of indxpath.c's get_bitmap_tree_required_outer()  
function, which computed the data on-demand.  It's not unlikely that  
that nets out as a savings of cycles in many scenarios.  A couple  
of other things in indxpath.c can be simplified as well.  
  
While here, get rid of some cases in reparameterize_path_by_child()  
that are visibly dead or useless, given that we only care about  
reparameterizing paths that can be on the inside of a parameterized  
nestloop.  This case reminds one of the maxim that untested code  
probably does not work, so I'm unwilling to leave unreachable code  
in this function.  (I did leave the T_Gather case in place even  
though it's not reached in the regression tests.  It's not very  
clear to me when the planner might prefer to put Gather below  
rather than above a nestloop, but at least in principle the case  
might be interesting.)  
  
Per bug #16536, originally from Arne Roland but with a test case  
by Andrew Gierth.  Back-patch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/16536-2213ee0b3aad41fd@postgresql.org  

commit   : de8feb1f3a23465b5737e8a8c160e8ca62f61339    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jul 2020 19:36:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jul 2020 19:36:30 +0200    

Three groups of issues needed to be addressed:  
  
load_external_function() and related functions returned PGFunction,  
even though not necessarily all callers are looking for a function of  
type PGFunction.  Since these functions are really just wrappers  
around dlsym(), change to return void * just like dlsym().  
  
In dynahash.c, we are using strlcpy() where a function with a  
signature like memcpy() is expected.  This should be safe, as the new  
comment there explains, but the cast needs to be augmented to avoid  
the warning.  
  
In PL/Python, methods all need to be cast to PyCFunction, per Python  
API, but this now runs afoul of these warnings.  (This issue also  
exists in core CPython.)  
  
To fix the second and third case, we add a new type pg_funcptr_t that  
is defined specifically so that gcc accepts it as a special function  
pointer that can be cast to any other function pointer without the  
warning.  
  
Also add -Wcast-function-type to the standard warning flags, subject  
to configure check.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/1e97628e-6447-b4fd-e230-d109cec2d584%402ndquadrant.com  

commit   : 101f903e51f52bf595cd8177d2e0bc6fe9000762    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Jul 2020 17:29:52 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Jul 2020 17:29:52 +1200    

Removing the unused 'miinfo' parameter has been raised a couple of times  
now.  It was decided in the 2nd discussion below that we're going to leave  
it alone.  It seems like it might be useful to add a comment to mention  
this fact so that nobody wastes any time in the future proposing its  
removal again.  
  
Discussion: https://postgr.es/m/CAApHDvpCf-qR5HC1rXskUM4ToV+3YDb4-n1meY=vpAHsRS_1PA@mail.gmail.com  
Discussion: https://postgr.es/m/CAE9k0P%3DFvcDswnSVtRpSyZMpcAWC%3DGp%3DifZ0HdfPaRQ%3D__LBtw%40mail.gmail.com  

commit   : f1fcf2d3b2e00b3d7ad3e0d2b1d26b77f5a48413    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Jul 2020 16:54:47 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Jul 2020 16:54:47 +1200    

An ALTER TABLE to validate a foreign key in which another subcommand  
already caused a pending table rewrite could fail due to ALTER TABLE  
attempting to validate the foreign key before the actual table rewrite  
takes place.  This situation could result in an error such as:  
  
ERROR:  could not read block 0 in file "base/nnnnn/nnnnn": read only 0 of 8192 bytes  
  
The failure here was due to the SPI call which validates the foreign key  
trying to access an index which is yet to be rebuilt.  
  
Similarly, we also incorrectly tried to validate CHECK constraints before  
the heap had been rewritten.  
  
The fix for both is to delay constraint validation until phase 3, after  
the table has been rewritten.  For CHECK constraints this means a slight  
behavioral change.  Previously ALTER TABLE VALIDATE CONSTRAINT on  
inheritance tables would be validated from the bottom up.  This was  
different from the order of evaluation when a new CHECK constraint was  
added.  The changes made here aligns the VALIDATE CONSTRAINT evaluation  
order for inheritance tables to be the same as ADD CONSTRAINT, which is  
generally top-down.  
  
Reported-by: Nazli Ugur Koyluoglu, using SQLancer  
Discussion: https://postgr.es/m/CAApHDvp%3DZXv8wiRyk_0rWr00skhGkt8vXDrHJYXRMft3TjkxCA%40mail.gmail.com  
Backpatch-through: 9.5 (all supported versions)  

commit   : b8401c32bacd0869bd00bc71fd64f1d6071bcd6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2020 13:39:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2020 13:39:45 +0900    

The following header files missed the shot:  
- jsonfuncs.h, as of ce0425b.  
- jsonapi.h, as of beb4699.  
- llvmjit_emit.h as of 7ec0d80.  
- partdesc.h, as of 1bb5e78.  
  
Author: Jesse Zhang  
Discussion: https://postgr.es/m/CAGf+fX4-8xULEOz09DE2dZGjT+q8VJ--rqfTpvcFwc+A4fc-3Q@mail.gmail.com  

commit   : 9168793d7275b4b318c153d607fba55d14098c19    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2020 13:17:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2020 13:17:11 +0900    

Incorrect function names were referenced.  As this fixes some portions  
of tableam.h, that is mentioned in the docs as something to look at when  
implementing a table AM, backpatch down to 12 where this has been  
introduced.  
  
Author: Hironobu Suzuki  
Discussion: https://postgr.es/m/8fe6d672-28dd-3f1d-7aed-ac2f6d599d3f@interdb.jp  
Backpatch-through: 12  

commit   : a742ecf9c63d454ccb107a357288c8ec1444ca12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jul 2020 20:38:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jul 2020 20:38:20 -0400    

The qual pushdown logic assumed that all Vars in a restriction clause  
must be Vars referencing subquery outputs; but since we introduced  
LATERAL, it's possible for such a Var to be a lateral reference instead.  
This led to an assertion failure in debug builds.  In a non-debug  
build, there might be no ill effects (if qual_is_pushdown_safe decided  
the qual was unsafe anyway), or we could get failures later due to  
construction of an invalid plan.  I've not gone to much length to  
characterize the possible failures, but at least segfaults in the  
executor have been observed.  
  
Given that this has been busted since 9.3 and it took this long for  
anybody to notice, I judge that the case isn't worth going to great  
lengths to optimize.  Hence, fix by just teaching qual_is_pushdown_safe  
that such quals are unsafe to push down, matching the previous behavior  
when it accidentally didn't fail.  
  
Per report from Tom Ellis.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20200713175124.GQ8220@cloudinit-builder  

commit   : b5b4c0fef9fb905d98f93c1f455397449c6e63a8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jul 2020 13:49:51 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jul 2020 13:49:51 -0400    

Remove previous hack in KeepLogSeg that added a case to deal with a  
(badly represented) invalid segment number.  This was added for the sake  
of GetWALAvailability.  But it's not needed if in that function we  
initialize the segment number to be retreated to the currently being  
written segment, so do that instead.  
  
Per valgrind-running buildfarm member skink, and some sparc64 animals.  
  
Discussion: https://postgr.es/m/1724648.1594230917@sss.pgh.pa.us  

commit   : 25fe5ac45a736e50d2b85280a3cb0ce169f583f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jul 2020 11:57:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jul 2020 11:57:55 -0400    

GSS-related resources should be cleaned up in pqDropConnection,  
not freePGconn, else the wrong things happen when resetting  
a connection or trying to switch to a different server.  
It's also critical to reset conn->gssenc there.  
  
During connection setup, initialize conn->try_gss at the correct  
place, else switching to a different server won't work right.  
  
Remove now-redundant cleanup of GSS resources around one (and, for  
some reason, only one) pqDropConnection call in connectDBStart.  
  
Per report from Kyotaro Horiguchi that psql would freeze up,  
rather than successfully resetting a GSS-encrypted connection  
after a server restart.  
  
This is YA oversight in commit b0b39f72b, so back-patch to v12.  
  
Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota.ntt@gmail.com  

commit   : 8d2ed66e4107ef27d05aef682c68af5952af7690    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 11 Jul 2020 14:14:49 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 11 Jul 2020 14:14:49 +0300    

 * Strategy number and purpose are essential information for opfamily operator.  
   So, show those columns in non-verbose output.  
 * "Left/right arg type" \dAp column names are confusing, because those type  
   don't necessary match to function arguments.  Rename them to "Registered  
   left/right type".  
 * Replace manual assembling of operator/procedure names with casts to  
   regoperator/regprocedure.  
 * Add schema-qualification for pg_catalog functions and tables.  
  
Reported-by: Peter Eisentraut, Tom Lane  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com  
Backpatch-through: 13  

commit   : 2302302236a0c7aeba3377d78dd9d80ba53247df    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 12 Jul 2020 17:48:49 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 12 Jul 2020 17:48:49 -0700    

This is a replacement for 4cad2534. Instead of projecting all tuples  
going into a HashAgg, only remove unnecessary attributes when actually  
spilling. This avoids the regression for the in-memory case.  
  
Discussion: https://postgr.es/m/a2fb7dfeb4f50aa0a123e42151ee3013933cb802.camel%40j-davis.com  
Backpatch-through: 13  

commit   : 0babd109801e5ecd90df29589c23c6daf3ae69f7    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 12 Jul 2020 16:46:19 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 12 Jul 2020 16:46:19 -0700    

This reverts commit 4cad2534da6d17067d98cf04be2dfc1bda8f2cd0 due to a  
performance regression. It will be replaced by a new approach in an  
upcoming commit.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20200614181418.mx4bvljmfkkhoqzl@alap3.anarazel.de  
Backpatch-through: 13  

commit   : d973747281caece520236e93d255c654cc613ec9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jul 2020 08:06:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jul 2020 08:06:05 +0530    

The stats with this commit was available only for WALSenders, however,  
users might want to see for backends doing logical decoding via SQL API.  
Then, users might want to reset and access these stats across server  
restart which was not possible with the current patch.  
  
List of commits reverted:  
  
caa3c4242c   Don't call elog() while holding spinlock.  
e641b2a995   Doc: Update the documentation for spilled transaction  
statistics.  
5883f5fe27   Fix unportable printf format introduced in commit 9290ad198.  
9290ad198b   Track statistics for spilling of changes from ReorderBuffer.  
  
Additionaly, remove the release notes entry for this feature.  
  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com  

commit   : 5bfe6a3c485d3259f59fa2d2e1d34dea1a3baeba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jul 2020 10:54:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jul 2020 10:54:26 +0900    

Switching the regression tests to use tstzrange() has proved to not be a  
good idea for environments where the timestamp precision is low, as  
internal range checks exclude the upper bound.  So, if the commit  
timestamp of a transaction matched with now() from the next query,  
the test would fail.  This changes to use two bound checks instead of  
the range function, where the upper bound is inclusive.  
  
Per buildfarm member jacana.  
  
Discussion: https://postgr.es/m/20200712122507.GD21680@paquier.xyz  

commit   : ea3e15d1691ec4cadc67f160cc91c7f237a705ae    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jul 2020 21:25:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jul 2020 21:25:36 +0900    

Replication origins created by regression tests should have names  
starting with "regress_", and the test introduced in b1e48bb for commit  
timestamps did not do that.  
  
Per buildfarm member longfin.  
  
Discussion: https://postgr.es/m/20200712122507.GD21680@paquier.xyz  

commit   : b1e48bbe64a411666bb1928b9741e112e267836d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jul 2020 20:47:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jul 2020 20:47:15 +0900    

This includes two changes:  
- Addition of a new function pg_xact_commit_timestamp_origin() able, for  
a given transaction ID, to return the commit timestamp and replication  
origin of this transaction.  An equivalent function existed in  
pglogical.  
- Addition of the replication origin to pg_last_committed_xact().  
  
The commit timestamp manager includes already APIs able to return the  
replication origin of a transaction on top of its commit timestamp, but  
the code paths for replication origins were never stressed as those  
functions have never looked for a replication origin, and the SQL  
functions available have never included this information since their  
introduction in 73c986a.  
  
While on it, refactor a test of modules/commit_ts/ to use tstzrange() to  
check that a transaction timestamp is within the wanted range, making  
the test a bit easier to read.  
  
Bump catalog version.  
  
Author: Movead Li  
Reviewed-by: Madan Kumar, Michael Paquier  
Discussion: https://postgr.es/m/2020051116430836450630@highgo.ca  

commit   : cd22d3cdb9bd9963c694c01a8c0232bbae3ddcfb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jul 2020 14:21:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jul 2020 14:21:28 -0400    

The raw_buf and line_buf buffers aren't used when reading binary format,  
so skip allocating them.  raw_buf is 64K so that seems like a worthwhile  
savings.  An unused line_buf only wastes 1K, but as long as we're checking  
it's free to avoid allocating that too.  
  
Bharath Rupireddy, tweaked a bit by me  
  
Discussion: https://postgr.es/m/CALj2ACXcCKaGPY0whowqrJ4OPJvDnTssgpGCzvuFQu5z0CXb-g@mail.gmail.com  

commit   : ea9125304dc6e90eabad165bd120eb1e667525d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jul 2020 13:36:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jul 2020 13:36:50 -0400    

Parallel pg_restore has always supposed that ACL items for different  
objects are independent and can be restored in parallel without  
conflicts.  However, there is one case where this fails: because  
REVOKE on a table is defined to also revoke the privilege(s) at  
column level, we can't restore per-column ACLs till after we restore  
any table-level privileges on their table.  Failure to honor this  
restriction can lead to "tuple concurrently updated" errors during  
parallel restore, or even to the per-column ACLs silently disappearing  
because the table-level REVOKE is executed afterwards.  
  
To fix, add a dependency from each column-level ACL item to its table's  
ACL item, if there is one.  Note that this doesn't fix the hazard  
for pre-existing archive files, only for ones made with a corrected  
pg_dump.  Given that the bug's been there quite awhile without  
field reports, I think this is acceptable.  
  
This requires changing the API of pg_dump's dumpACL() function.  
To keep its argument list from getting even longer, I removed the  
"CatalogId objCatId" argument, which has been unused for ages.  
  
Per report from Justin Pryzby.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20200706050129.GW4107@telsasoft.com  

commit   : 64fe120b57c6a928a527880476e9882b9bf7ae8a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jul 2020 13:47:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jul 2020 13:47:29 +0200    

Reported-by: Lee Dong Wook <sh95119@gmail.com>  

commit   : cc35d8933a211d9965eb1c1d2749a903d5735db2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 Jul 2020 13:32:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 Jul 2020 13:32:28 +0900    

"relkind" normally refers to the char field from pg_class.  However, in  
the parse nodes AlterTableStmt and CreateTableAsStmt, "relkind" was used  
for a field of type enum ObjectType, that could refer to other object  
types than those possible for a relkind.  Such fields being usually  
named "objtype", switch the name in both structures to make things more  
consistent.  Note that this led to some confusion in functions that  
also operate on a RangeTableEntry object, which also has a field named  
"relkind".  
  
This naming goes back to commit 09d4e96, where only OBJECT_TABLE and  
OBJECT_INDEX were used.  This got extended later to use as well  
OBJECT_TYPE with e440e12, not really a relation kind.  
  
Author: Mark Dilger  
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/609181AE-E399-47C7-9221-856E0F96BF93@enterprisedb.com  

commit   : df646509f371069c65f84309eb5749642e8650b3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 11 Jul 2020 03:21:00 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 11 Jul 2020 03:21:00 +0300    

SQL standard doesn't define numeric Inf or NaN values.  It appears even more  
ridiculous to support then in jsonpath assuming JSON doesn't support these  
values as well.  This commit forbids returning NaN from .double(), which was  
previously allowed.  NaN can't be result of inner-jsonpath computation over  
non-NaNs.  So, we can not expect NaN in the jsonpath output.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/203949.1591879542%40sss.pgh.pa.us  
Author: Alexander Korotkov  
Reviewed-by: Tom Lane  
Backpatch-through: 12  

commit   : 0657181167467ec5cfb5a28aacf47ca02f5f4588    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 11 Jul 2020 03:20:46 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 11 Jul 2020 03:20:46 +0300    

When jsonpath .double() method detects that numeric or string can't be  
converted to double precision, it throws an error.  This commit makes these  
errors explicitly express the reason of failure.  
  
Discussion: https://postgr.es/m/CAPpHfdtqJtiSXkP7tOXez18NxhLUH_-75bL8%3DOce4Ki%2Bbv7V6Q%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Tom Lane  
Backpatch-through: 12  

commit   : e91cd951b1114a009a0256f211a41d0ec873b2fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jul 2020 13:16:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jul 2020 13:16:00 -0400    

Re-point comp.ai.genetic FAQ link to a more stable address.  
  
Remove stale links to AIX documentation; we don't really need to  
tell AIX users how to use their systems.  
  
Remove stale links to HP documentation about SSL.  We've had to  
update those twice before, making it increasingly obvious that  
HP does not intend them to be stable landing points.  They're  
not particularly authoritative, either.  (This change effectively  
reverts bbd3bdba3.)  
  
Daniel Gustafsson and Álvaro Herrera, per a gripe from  
Kyotaro Horiguchi.  Back-patch, since these links are  
just as dead in the back branches.  
  
Discussion: https://postgr.es/m/20200709.161226.204639179120026914.horikyota.ntt@gmail.com  

commit   : 72a16cb3ee3017ccd8e4d58ea3c0c7bceec8b702    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 10 Jul 2020 16:51:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 10 Jul 2020 16:51:29 +0200    

Most of them already have this, but some were missing.  
  
Author: Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf%40wibble.ilmari.org  

commit   : 61be85afabba0cd85bb1bcaacbea8efa8641f564    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jul 2020 17:08:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jul 2020 17:08:13 +0900    

This reverts commit 2b2a070, that moved the reset of path  
"testtablespace" used by the regression tests as a path for tablespaces  
(via --outputdir) from pg_regress to the MSVC script vcregress.pl, as  
this broke the behavior added by ce5d342 to be able to safely run the  
regression test suite with an administrative Windows account using a  
restricted token.  
  
Note that before 2b2a070, the code doing the reset in pg_regress.c  
included a comment telling that we had better move that out to a  
different place, leading to the mistake done in 2b2a070.  Fix this  
comment, and document instead that we had better never remove this code,  
for the sake of not breaking again the behavior we expect on Windows.  
  
Thanks to Thomas Munro and Andrew Dunstan for the discussion.  
  
Discussion: https://postgr.es/m/6d9eee97-54c8-e14a-48f7-3194e712f54f@2ndQuadrant.com  
Discussion: https://postgr.es/m/CA+hUKGLiieEzfrdWxWFE+_wnXho_F5Smx972X1wEubhS7v1q9g@mail.gmail.com  

commit   : ff61359ad7cd10e48a9ce662b5f2a5e7f3ca23e1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 10 Jul 2020 08:27:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 10 Jul 2020 08:27:00 +0200    

This order makes more sense because the location is effectively at the  
lowest level of the backtrace.  
  
Discussion: https://www.postgresql.org/message-id/flat/90f5fa04-c410-a54e-9449-aa3749fb7972%402ndquadrant.com  

commit   : 986529ce40c6edcd7f83689c00fcfaab8d9436d8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 9 Jul 2020 20:13:25 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 9 Jul 2020 20:13:25 -0400    

This message was being emitted on the grounds that only crashed  
summarization could cause it, but in reality even an aborted vacuum  
could do it ... which makes it way too noisy, particularly since it  
shows up in regression tests and makes them die.  
  
Reported by Tom Lane.  
Discussion: https://postgr.es/m/489091.1593534251@sss.pgh.pa.us  

commit   : 183926da3162b1807904710e46882c004beff5fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2020 16:02:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2020 16:02:23 -0400    

Due to not having our signals straight about CRLF vs. LF line  
termination, the output of pg_current_logfile() included a trailing  
\r on Windows.  To fix, force the file descriptor it uses into text  
mode.  
  
While here, move a couple of local variable declarations to make  
the function's logic clearer.  
  
In v12 and v13, also back-patch the test added by 1c4e88e2f so that  
this function has some test coverage.  However, the 004_logrotate.pl  
test script doesn't exist before v12, and it didn't seem worth adding  
to older branches just for this.  
  
Per report from Thomas Kellerer.  Back-patch to v10 where this  
function was added.  
  
Discussion: https://postgr.es/m/412ae8da-76bb-640f-039a-f3513499e53d@gmx.net  

commit   : ffb4cee43bdccb54f0cf072a51dedc74e343b6f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2020 11:37:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2020 11:37:21 -0400    

Buildfarm results now imply that Perl's IPC::Run does CRLF conversion  
for us if we're using native Perl, but not when using MSys Perl.  
Restrict the conversions done by PostgresNode.pm to act only in the  
latter case.  (Similar conversions done in TestLib.pm and RewindTest.pm  
were already handled this way.)  
  
Discussion: https://postgr.es/m/412ae8da-76bb-640f-039a-f3513499e53d@gmx.net  

commit   : 991c444e7ad3a1ff7bcffff4121e6ff67c4783fc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jul 2020 09:47:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jul 2020 09:47:43 +0200    

After further discussion after  
daa9fe8a5264a3f192efa5ddee8fb011ad9da365, reorder the version-specific  
sections from oldest to newest.  Also, remove the variable assignments  
from PQfnumber() to reduce vertical space.  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/6594334b-40fd-14f1-6bc5-877afa3feed5@2ndquadrant.com  

commit   : a5cd7047e7c6dacdef79a763a26802469ac4e02b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Jul 2020 13:31:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Jul 2020 13:31:33 +0900    

pg_stat_activity.query text is truncated at 1024 bytes. But previously  
the document described that it's truncated at 1024 characters.  
This was not accurate when considering multibyte characters.  
  
Back-patch to v10 where this inaccurate description was added.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Daniel Gustafsson, Fujii Masao  
Discussion: https://postgr.es/m/cd5b49a5a14e887542f5f569c1c6bde2@oss.nttdata.com  

commit   : 91bdf499b37b0bbef34e2bab5cc40dde52bda52c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jul 2020 20:25:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jul 2020 20:25:52 -0400    

The previous approach was to search-and-destroy all \r occurrences  
no matter what.  That seems more likely to hide bugs than anything  
else; indeed it seems to be hiding one now.  Fix things so that  
we only transform \r\n to \n.  
  
Side effects: must do this before, not after, chomp'ing if we're  
going to chomp, else we'd fail to clean up a trailing \r\n.  Also,  
remove safe_psql's redundant repetition of what psql already did;  
else it might reduce \r\r\n to \n, which is exactly the scenario  
I'm hoping to expose.  
  
Perhaps this should be back-patched, but for now I'm content to  
see what happens in HEAD.  
  
Discussion: https://postgr.es/m/412ae8da-76bb-640f-039a-f3513499e53d@gmx.net  

commit   : 2b7dbc0db6ecf38fc305284d006a1ef8f5354fbb    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2020 10:06:24 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2020 10:06:24 +1200    

The Sort node does not put a space between the number of kilobytes and  
the "kB" of memory or disk space used, but HashAgg does.  Here we align  
HashAgg to do the same as Sort.  Sort has been displaying this  
information for longer than HashAgg, so it makes sense to align HashAgg  
to Sort rather than the other way around.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20200708163021.GW4107@telsasoft.com  
Backpatch-through: 13, where the hashagg started showing these details  

commit   : a9a4a7ad565b136cbee735d4bb505d98d06da522    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:14:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:14:40 -0700    

Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : 7c89f8a5b810d10dae300ec58ea7d70024e9123e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:19:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:19:32 -0700    

Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : 09dfd430118f1fadf52a782db5ee161b1eb16337    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:18:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:18:41 -0700    

These uses of 'master' refer to partitioning / inheritance. 'root'  
seems more descriptive than 'master'.  
  
Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : 9e101cf60612f4be4f855d7393531900c2986a55    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:12:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 10:12:58 -0700    

Also changed "in the primary" to "on the primary", and added a few  
"the" before "primary".  
  
Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : e07633646a22734e85d7fc58a66855f747128e6b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 14 Jun 2020 14:22:47 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 14 Jun 2020 14:22:47 -0700    

Leader already is the more widely used terminology, but a few places  
didn't get the message.  
  
Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : 5e7bbb528638c0f6d585bab107ec7a19e3a39deb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 14 Jun 2020 14:05:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 14 Jun 2020 14:05:18 -0700    

Also changed "in the primary" to "on the primary", and added a few  
"the" before "primary".  
  
Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : 229f8c219f8fffacc253eca6023eab10a16eb009    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 14 Jun 2020 11:47:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 14 Jun 2020 11:47:37 -0700    

We've largely replaced master with primary in docs etc, but tap test  
still widely used master.  
  
Author: Andres Freund  
Reviewed-By: David Steele  
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de  

commit   : 2661a793ff59149af1d844d6be504e421c04733e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Jul 2020 14:52:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Jul 2020 14:52:39 -0400    

This has been an integer count since 7e413a0f82c8 so treat it explicitly  
like an integer.  
  
No backpatch since this is just cosmetic.  

commit   : 1c4e88e2fe41dbd1cb3431fbfed5ee6d92bfe089    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jul 2020 13:41:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jul 2020 13:41:52 -0400    

There has been no coverage at all up to now.  Given Thomas Kellerer's  
recent report, I suspect this may fail on (some?) Windows machines,  
but let's find out.  
  
Discussion: https://postgr.es/m/412ae8da-76bb-640f-039a-f3513499e53d@gmx.net  

commit   : 654242fd81cfbdd229ec2a752a9f857a84cc039b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2020 21:24:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2020 21:24:34 +0900    

Since slot_keep_segs indicates the number of WAL segments not LSN,  
its datatype should not be XLogRecPtr.  
  
Back-patch to v13 where this issue was added.  
  
Reported-by: Atsushi Torikoshi  
Author: Atsushi Torikoshi, tweaked by Fujii Masao  
Discussion: https://postgr.es/m/ebd0d674f3e050222238a960cac5251a@oss.nttdata.com  

commit   : eb2c8a8f816b6c411047eeab7a326e8356a2c0a8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2020 11:17:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jul 2020 11:17:52 +0200    

Remove a redundant and failing command, probably a typo.  

commit   : 98f0eba5b7840197ee43f52833ef08f9090fbc44    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 8 Jul 2020 10:11:43 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 8 Jul 2020 10:11:43 +0200    

Author: Daniel Gustafsson  

commit   : 5e574d170e2eb112e1da8a40f011741b82340f68    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2020 11:00:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2020 11:00:23 +0900    

Author: Masahiro Ikeda  
Discussion: https://postgr.es/m/0043eee90b38351ea199d7e3294c10c4@oss.nttdata.com  

commit   : d92be269103acaf58e87ba4ba732eac0e3c4d78a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2020 10:41:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2020 10:41:53 +0900    

The GIN and SP-GiST parts were out-of-sync since the changes of 14903f2,  
and the BRIN part was wrong since its introduction in 15cb2bd.  
  
Author: Guillaume Lelarge  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CAECtzeXKvEPEr967h0PRYRi39uTmdEms=oUtc_PWGjZRNN1prw@mail.gmail.com  
Backpatch-through: 13  

commit   : 3f96af4619c8b129ec8d5f4fb961df4310999383    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jul 2020 18:10:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jul 2020 18:10:42 -0400    

I neglected to test this scenario while preparing commit f3faf35f3,  
so of course it was broken, thanks to some very obscure and undocumented  
code in pg_dump.  Pre-v12 databases might have toast tables attached to  
partitioned tables, which we need to ignore since newer servers never  
create such useless toast tables.  There was a filter for this case in  
binary_upgrade_set_type_oids_by_rel_oid(), which appeared to just  
prevent the pg_type OID from being copied.  But actually it managed to  
prevent the toast table from being created at all --- or it did before  
I took out that logic.  But that was a fundamentally bizarre place to be  
making the test in the first place.  The place where the filter should  
have been, one would think, is binary_upgrade_set_pg_class_oids(), so  
add it there.  
  
While at it, reorganize binary_upgrade_set_pg_class_oids() so that it  
doesn't make a completely useless query when it knows it's being  
invoked for an index.  And correct a comment that mis-described the  
scenario where we need to force creation of a TOAST table.  
  
Per buildfarm.  

commit   : f3faf35f370f558670c8213a08f2683f3811ffc7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jul 2020 15:43:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jul 2020 15:43:22 -0400    

Commit f7f70d5e2 left one inconsistency behind: we're still creating  
pg_type entries for the composite types of sequences and toast tables,  
but not arrays over those composites.  But there seems precious little  
reason to have named composite types for toast tables, and not much more  
to have them for sequences (especially given the thought that sequences  
may someday not be standalone relations at all).  
  
So, let's close that inconsistency by removing these composite types,  
rather than adding arrays for them.  This buys back a little bit of  
the initial pg_type bloat added by the previous patch, and could be  
a significant savings in a large database with many toast tables.  
  
Aside from a small logic rearrangement in heap_create_with_catalog,  
this patch mostly needs to clean up some places that were assuming that  
pg_class.reltype always has a valid value.  Those are really pre-existing  
bugs, given that it's documented otherwise; notably, the plpgsql changes  
fix code that gives "cache lookup failed for type 0" on indexes today.  
But none of these seem interesting enough to back-patch.  
  
Also, remove the pg_dump/pg_upgrade infrastructure for propagating  
a toast table's pg_type OID into the new database, since we no longer  
need that.  
  
Discussion: https://postgr.es/m/761F1389-C6A8-4C15-80CE-950C961F5341@gmail.com  

commit   : a8aaa0c786b3a27706172cc7979684a122ebb706    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jul 2020 13:08:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jul 2020 13:08:00 -0400    

The previous definition of the column was almost universally disliked,  
so provide this updated definition which is more useful for monitoring  
purposes: a large positive value is good, while zero or a negative value  
means danger.  This should be operationally more convenient.  
  
Backpatch to 13, where the new column to pg_replication_slots (and the  
feature it represents) were added.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://postgr.es/m/9ddfbf8c-2f67-904d-44ed-cf8bc5916228@oss.nttdata.com  

commit   : 6a5c750f3f72899f4f982f921d5bf5665f55651e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Jul 2020 16:57:27 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Jul 2020 16:57:27 +0200    

Previously we checked that the ssl pointer was not null, but this puts a  
requirement on there being such a pointer which may not be true in  
future multi-ssl-library supporting times. This seems to have been an  
oversight in 9029f4b3740, but hasn't really had any effect since we only  
have one library.  
  
Author: Daniel Gustafsson  

commit   : 71ec58e7fc1e180165fbed7a983d8179a03ddfc6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2020 10:21:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Jul 2020 10:21:54 +0200    

commit   : 28c16f4947df0a98c124ec1724faff629d6c77f7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 6 Jul 2020 13:47:29 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 6 Jul 2020 13:47:29 -0700    

nbtree index builds cannot write out an empty page.  That would mean  
that there was no way to create a pivot tuple pointing to the page one  
level up, since _bt_truncate() generates one based on page's firstright  
tuple.  
  
Replace the unnecessary PageIsEmpty() check with an assertion that  
checks that the page has space for at least two line pointers (the  
would-be high key line pointer, plus at least one valid "data item"  
tuple line pointer).  
  
The PageIsEmpty() check was added by commit 5d9f146c over 20 years ago.  
It looks like it has always been unnecessary.  

commit   : f7f70d5e22aa2330b8cc31dfc8732cd26ef0bbdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2020 14:21:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jul 2020 14:21:16 -0400    

When we invented arrays of composite types (commit bc8036fc6),  
we excluded system catalogs, basically just on the grounds of not  
wanting to bloat pg_type.  However, it's definitely inconsistent that  
catalogs' composite types can't be put into arrays when others can.  
Another problem is that the exclusion is done by checking  
IsUnderPostmaster in heap_create_with_catalog, which means that  
  
(1) If a user tries to create a table in single-user mode, it doesn't  
get an array type.  That's bad in itself, plus it breaks pg_upgrade.  
  
(2) If someone drops and recreates a system view or information_schema  
view (as we occasionally recommend doing), it will now have an array  
type where it did not before, making for still more inconsistency.  
  
So this is all pretty messy.  Let's just get rid of the inconsistency  
and decree that system-created relations should have array types if  
similar user-created ones would, i.e. it only depends on the relkind.  
As of HEAD, that means that the initial contents of pg_type grow from  
411 rows to 605, which is a lot of growth percentage-wise, but it's  
still quite a small catalog compared to others.  
  
Wenjing Zeng, reviewed by Shawn Wang, further hacking by me  
  
Discussion: https://postgr.es/m/761F1389-C6A8-4C15-80CE-950C961F5341@gmail.com  

commit   : bae9e8a58bf642aa383f5dc01b2c5947bae533dd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Jul 2020 09:53:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Jul 2020 09:53:37 +0200    

The test was supposed to error but didn't.  Apparently, a copy and  
paste and string replace mistake from a nearby similar test.  

commit   : 321fa6a4a26c9b649a0fbec9fc8b019f19e62289    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2020 14:27:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2020 14:27:09 +0900    

Enabling pg_stat_statements.track_plaanning may incur a noticeable  
performance penalty, especially when a fewer kinds of queries are executed  
on many concurrent connections. This commit documents this note.  
  
Back-patch to v13 where pg_stat_statements.track_plaanning was added.  
  
Suggested-by: Pavel Stehule  
Author: Fujii Masao  
Reviewed-by: Pavel Stehule  
Discussion: https://postgr.es/m/CAFj8pRC9Jxa8r5i0TNBWLb8mzuaYzEoLq3QOvip0jVpHPOLbVA@mail.gmail.com  

commit   : aa38434824c4fa52e55a9c7465b24c246caddc81    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jul 2020 13:06:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jul 2020 13:06:08 +0900    

This introduces a new set of extended routines for procedure and  
operator name lookups, with a flag bitmask argument that can modify the  
result.  The following options are available:  
- Force schema qualification, ignoring search_path.  This is similar to  
the existing option for format_{operator|procedure}_qualified().  
- Force NULL as result instead of a numeric OID for an undefined  
object.  This option is new.  
  
This is a refactoring similar to 1185c78, that will be used for a future  
patch to improve the SQL functions providing information using object  
addresses for undefined objects.  
  
Author: Michael Paquier  
Reviewed-by: Aleksander Alekseev, Dmitry Dolgov, Daniel Gustafsson,  
Álvaro Herrera  
Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com  

commit   : 04c7f4144fec3bcddc82b6abdbfebd88989f7953    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:44:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:44:33 +0530    

Backpatch-through: 13, where it was introduced  

commit   : 1185c782943c6d36835db481b199dce8e6f30246    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jul 2020 12:12:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jul 2020 12:12:11 +0900    

If a type scanned is undefined, type format routines have two behaviors  
depending on if FORMAT_TYPE_ALLOW_INVALID is used by the caller or not:  
- Issue a cache lookup error  
- Return an undefined type name "???", "???[]" or "-"  
  
The current interface is not really helpful for callers willing to  
format properly a type name, but still make sure that the type is  
defined as there could be types matching the strings generated when  
looking for an undefined type, even if that should not be a problem in  
practice.  In order to counter that, add a new flag called  
FORMAT_TYPE_INVALID_AS_NULL that returns a NULL result instead of "???  
or "-" which does not generate an error.  This flag will be used in a  
follow-up patch improving the set of SQL functions showing information  
for object addresses when it comes to undefined objects.  
  
Author: Michael Paquier  
Reviewed-by: Aleksander Alekseev, Dmitry Dolgov, Daniel Gustafsson,  
Álvaro Herrera  
Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com  

commit   : 231ef5b90d3a8a4ddf9de137e8e0997409c7a8b1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:21:52 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:21:52 +0530    

Author: Vignesh C  
Reviewed-by: Sawada Masahiko  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CALDaNm3Ppt71NafGY5mk3V2i3Q+mm93pVibDq-0NpW7WU67Jcg@mail.gmail.com  

commit   : 404b912c5cab05d4a2ddac85696a300e00783c73    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jul 2020 09:16:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jul 2020 09:16:17 +0900    

This commit includes two improvements for build.pl in src/tools/msvc/:  
- Fix two warnings related to $ARGV[0] being uninitialized, something  
that happens when calling build.pl (or build.bat) without arguments to  
compile all the components with a release quality.  
- If calling the script with more than two arguments, exit immediately  
and show a new help output.  build.pl was not failing in this case  
before this commit, and the extra arguments were just ignored, but the  
new behavior helps in understanding how to run the script without  
looking at the documentation for the Windows builds.  
  
Reported-by: Ranier Vilela  
Author: Michael Paquier  
Reviewed-by: Juan José Santamaría Flecha, David Zhang  
Discussion: https://postgr.es/m/CAEudQAo38dfR_0Ugt2OHy4mq-6Hz93XPSBAGEUV67RhKdgp8Zg@mail.gmail.com  

commit   : fe2e206cdb00a2d5dcebc3c8e8119017392d9781    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2020 13:12:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2020 13:12:31 -0400    

In the common case where this function isn't actually asked to perform  
any type conversion, there's nothing it has to do beyond comparing the  
arguments.  Arrange for that part to be inlined into callers, with the  
slower path remaining out-of-line.  This seems to be good for several  
percent speedup on simple cases, with only minimal code bloat.  
  
Amit Khandekar  
  
Discussion: https://postgr.es/m/CAJ3gD9eBNrmUD7WBBLG8ohaZ485H9y+4eihQTgr+K8Lhka3vcQ@mail.gmail.com  

commit   : 90b2d8c1adc86d1fc46f83c73444a1fb5b28dd3c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 5 Jul 2020 15:37:57 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 5 Jul 2020 15:37:57 +0200    

commit   : 8cea55e99b766fd654431f24987a774622594c9b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Jul 2020 19:35:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Jul 2020 19:35:56 +0900    

This error has survived for 22 years, and has been introduced by  
da63386.  
  
Reported-by: Erwin Brandstetter  
Discussion: https://postgr.es/m/CAGHENJ57wogGOvGXo5LgWYcqswxafLck8ELqHDR+zrkTPgs_OQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : e61225ffab3f8726ecd053b1c22ff249c417f9ba    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 5 Jul 2020 11:41:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 5 Jul 2020 11:41:52 +0200    

Author: James Coleman <jtc331@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/df652910-e985-9547-152c-9d4357dc3979%402ndquadrant.com  

commit   : 1d05627fcf54b26e0cbd7527f9858f165d117813    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 13:46:31 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 13:46:31 -0400    

The cfbot and some BF animals are complaining about the previous  
read_binary_file commit because of ignoring return value of ‘fread’.  
So let's make everyone happy by testing the return value even though  
not strictly needed.  
  
Reported by Justin Pryzby, and suggested patch by Tom Lane. Backpatched  
to v11 same as the previous commit.  
  
Reported-By: Justin Pryzby  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/flat/969b8d82-5bb2-5fa8-4eb1-f0e685c5d736%40joeconway.com  
Backpatch-through: 11  

commit   : 96d1f423f95d15c74989336e0776e1d55561a3f1    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 06:26:53 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 06:26:53 -0400    

read_binary_file(), used by SQL functions pg_read_file() and friends,  
uses stat to determine file length to read, when not passed an explicit  
length as an argument. This is problematic, for example, if the file  
being read is a virtual file with a stat-reported length of zero.  
Arrange to read until EOF, or StringInfo data string lenth limit, is  
reached instead.  
  
Original complaint and patch by me, with significant review, corrections,  
advice, and code optimizations by Tom Lane. Backpatched to v11. Prior to  
that only paths relative to the data and log dirs were allowed for files,  
so no "zero length" files were reachable anyway.  
  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/flat/969b8d82-5bb2-5fa8-4eb1-f0e685c5d736%40joeconway.com  
Backpatch-through: 11  

commit   : ca5e93f769e1bf5e90d080cfcc8c0368ef649a7c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2020 19:01:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2020 19:01:21 -0400    

After running GetForeignRelSize for a foreign table, adjust rel->tuples  
to be at least as large as rel->rows.  This prevents bizarre behavior  
in estimate_num_groups() and perhaps other places, especially in the  
scenario where rel->tuples is zero because pg_class.reltuples is  
(suggesting that ANALYZE has never been run for the table).  As things  
stood, we'd end up estimating one group out of any GROUP BY on such a  
table, whereas the default group-count estimate is more likely to result  
in a sane plan.  
  
Also, clarify in the documentation that GetForeignRelSize has the option  
to override the rel->tuples value if it has a better idea of what to use  
than what is in pg_class.reltuples.  
  
Per report from Jeff Janes.  Back-patch to all supported branches.  
  
Patch by me; thanks to Etsuro Fujita for review  
  
Discussion: https://postgr.es/m/CAMkU=1xNo9cnan+Npxgz0eK7394xmjmKg-QEm8wYG9P5-CcaqQ@mail.gmail.com  

commit   : f7b5988cc0d879d6cc9d481ba898e55747a53bbe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2020 17:01:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2020 17:01:34 -0400    

Commit ecd9e9f0b fixed the problem in the wrong place, causing unwanted  
side-effects on the behavior of GetNextTempTableSpace().  Instead,  
let's make SharedFileSetInit() responsible for subbing in the value  
of MyDatabaseTableSpace when the default tablespace is called for.  
  
The convention about what is in the tempTableSpaces[] array is  
evidently insufficiently documented, so try to improve that.  
  
It also looks like SharedFileSetInit() is doing the wrong thing in the  
case where temp_tablespaces is empty.  It was hard-wiring use of the  
pg_default tablespace, but it seems like using MyDatabaseTableSpace  
is more consistent with what happens for other temp files.  
  
Back-patch the reversion of PrepareTempTablespaces()'s behavior to  
9.5, as ecd9e9f0b was.  The changes in SharedFileSetInit() go back  
to v11 where that was introduced.  (Note there is net zero code change  
before v11 from these two patch sets, so nothing to release-note.)  
  
Magnus Hagander and Tom Lane  
  
Discussion: https://postgr.es/m/CABUevExg5YEsOvqMxrjoNvb3ApVyH+9jggWGKwTDFyFCVWczGQ@mail.gmail.com  

commit   : 1f902d499eda862a98e881a2227b8d2cf3565374    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2020 15:42:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jul 2020 15:42:10 -0400    

This saves one level of C function call per plpgsql statement executed,  
and permits a tiny additional optimization of not saving and restoring  
estate->err_stmt for each statement in a block.  The net effect seems  
nearly un-measurable on x86_64, but there's a clear win on aarch64,  
amounting to two or three percent in a loop over a few simple plpgsql  
statements.  
  
To do this, we have to get rid of the other existing call sites for  
exec_stmt().  Replace them with exec_toplevel_block(), which is just  
defined to do what exec_stmts() does, but for a single  
PLpgSQL_stmt_block statement.  Hard-wiring the expectation of which  
statement type applies here allows us to skip the dispatch switch,  
making this not much uglier than the previous factorization.  
  
Amit Khandekar, tweaked a bit by me  
  
Discussion: https://postgr.es/m/CAJ3gD9eBNrmUD7WBBLG8ohaZ485H9y+4eihQTgr+K8Lhka3vcQ@mail.gmail.com  

commit   : ecd9e9f0bc141550726b2205dd6f5745a58e9ecd    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 3 Jul 2020 15:09:06 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 3 Jul 2020 15:09:06 +0200    

A likely copy/paste error in 98e8b480532 from  back in 2004 would  
cause temp tablespace to be reset to InvalidOid if temp_tablespaces  
was set to the same value as the primary tablespace in the database.  
This would cause shared filesets (such as for parallel hash joins)  
to ignore them, putting the temporary files in the default tablespace  
instead of the configured one. The bug is in the old code, but it  
appears to have been exposed only once we had shared filesets.  
  
Reviewed-By: Daniel Gustafsson  
Discussion: https://postgr.es/m/CABUevExg5YEsOvqMxrjoNvb3ApVyH+9jggWGKwTDFyFCVWczGQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 8f9b6d40570bd8991f18a089a8445cc5275c1f49    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2020 12:08:35 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2020 12:08:35 +0900    

Previously the document explained that restart_lsn indicates the LSN of  
oldest WAL won't be automatically removed during checkpoints. But  
since v13 this was no longer true thanks to max_slot_wal_keep_size.  
  
Back-patch to v13 where max_slot_wal_keep_size was added.  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/6497f1e9-3148-c5da-7e49-b2fddad9a42f@oss.nttdata.com  

commit   : d1763ea8c9c32837d373a196ed0c2e1256a55824    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2020 11:35:22 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2020 11:35:22 +0900    

Since v13 pg_stat_statements is allowed to track the planning time of  
statements when track_planning option is enabled. Its default was on.  
  
But this feature could cause more terrible spinlock contentions in  
pg_stat_statements. As a result of this, Robins Tharakan reported that  
v13 beta1 showed ~45% performance drop at high DB connection counts  
(when compared with v12.3) during fully-cached SELECT-only test using  
pgbench.  
  
To avoid this performance regression by the default setting,  
this commit changes default of pg_stat_statements.track_planning to off.  
  
Back-patch to v13 where pg_stat_statements.track_planning was introduced.  
  
Reported-by: Robins Tharakan  
Author: Fujii Masao  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/2895b53b033c47ccb22972b589050dd9@EX13D05UWC001.ant.amazon.com  

commit   : 947456a823d6b0973b68c6b38c8623a0504054e7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jul 2020 16:34:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jul 2020 16:34:54 -0700    

Do the same for the maintenance_work_mem global variable.  
  
Oversight in commit 848ae330a49, which increased the previous defaults  
for work_mem and maintenance_work_mem by 4X.  

commit   : e25d462a38f853621a2ad529638d463836230766    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jul 2020 14:54:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jul 2020 14:54:55 -0700    

Make some of the variable names in _bt_search() consistent with  
corresponding variables within _bt_getstackbuf().  This naming scheme is  
clearer because the variable names always express a relationship between  
the currently locked buffer/page and some other page.  

commit   : 641dd167a3424f97eed8416b5ef1c21dbbf8cf12    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Jul 2020 13:57:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Jul 2020 13:57:03 +0900    

src/backend/replication/README includes since 32bc08b a basic  
description of the WAL receiver hooks available in walreceiver.h for a  
module like libpqwalreceiver, but the README has never been updated to  
reflect changes done to the hooks, so the contents of the README have  
rotten with the time.  This commit moves the description from the README  
to walreceiver.h, where it will be hard to miss that a description  
update or addition is needed depending on the modifications done to the  
hooks.  
  
Each hook now includes a description of what it does in walreceiver.h,  
and the replication's README mentions walreceiver.h.  
  
Thanks also to Amit Kapila for the discussion.  
  
Author: Michael Paquier  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/20200502024606.GA471944@paquier.xyz  

commit   : 4315e8c23b9a897e12fcf91de7bfd734621096bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 17:03:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 17:03:50 +0900    

This is a follow-up commit similar to 68de144, with more places in the  
backend code simplified with the macros able to assign values to the  
fields of ObjectAddress.  The code paths changed here could be  
transitioned later into using more grouping when inserting dependency  
records, simplifying this future work.  
  
Author: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de  

commit   : a69e041d0c91759fb60ab52e7e21e3ec3752c69b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Jul 2020 07:58:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Jul 2020 07:58:36 +0530    

Use separate functions to save and restore error context information as  
that made code easier to understand.  Also, make it clear that the index  
information required for error context is sane.  
  
Author: Andres Freund, Justin Pryzby, Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CAA4eK1LWo+v1OWu=Sky27GTGSCuOmr7iaURNbc5xz6jO+SaPeA@mail.gmail.com  

commit   : 684b4f29b729e5b135d256802d6e712222b9551f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 11:12:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 11:12:33 +0900    

When creating an extension, the same type of dependency is used when  
registering a dependency to a schema and required extensions.  This  
improves the code so as those dependencies are not recorded one-by-one,  
but grouped together.  Note that this has as side effect to remove  
duplicate dependency entries, even if it should not happen in practice  
as extensions listed as required in a control file should be listed only  
once.  
  
Extracted from a larger patch by the same author.  
  
Author: Daniel Dustafsson  
Discussion: https://postgr.es/m/20200629065535.GA183079@paquier.xyz  

commit   : c4342c932abb6792f6c7d8528b6224ca4d5e1a84    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 10:47:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 10:47:24 +0900    

001_ssltests.pl and 002_scram.pl both generated an extra file for a  
client key used in the tests that were not removed.  In Debian, this  
causes repeated builds to fail.  
  
The code refactoring done in 4dc6355 broke the cleanup done in  
001_ssltests.pl, and the new tests added in 002_scram.pl via d6e612f  
forgot the removal of one file.  While on it, fix a second issue  
introduced in 002_scram.pl where we use the same file name in 001 and  
002 for the temporary client key whose permissions are changed in the  
test, as using the same file name in both tests could cause failures  
with parallel jobs of src/test/ssl/ if one test removes a file still  
needed by the second test.  
  
Reported-by: Felix Lechner  
Author: Daniel Gustafsson, Felix Lechner  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/CAFHYt543sjX=Cm_aEeoejStyP47C+Y3+Wh6WbirLXsgUMaw7iw@mail.gmail.com  
Backpatch-through: 13  

commit   : 40efbf8706cdd96e06bc4d1754272e46d9857875    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 1 Jul 2020 12:15:59 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 1 Jul 2020 12:15:59 +1200    

The "Disk Usage" and "HashAgg Batches" properties in the EXPLAIN ANALYZE  
output for HashAgg were previously only shown if the number of batches  
was greater than 0.  Here we change this so that these properties are  
always shown for EXPLAIN ANALYZE formats other than "text".  The idea here  
is that since the HashAgg could have spilled to disk if there had been  
more data or groups to aggregate, then it's relevant that we're clear in  
the EXPLAIN ANALYZE output when no spilling occurred in this particular  
execution of the given plan.  
  
For the "text" EXPLAIN format, we still hide these properties when no  
spilling occurs.  This EXPLAIN format is designed to be easy for humans  
to read.  To maintain the readability we have a higher threshold for which  
properties we display for this format.  
  
Discussion: https://postgr.es/m/CAApHDvo_dmNozQQTmN-2jGp1vT%3Ddxx7Q0vd%2BMvD1cGpv2HU%3DSg%40mail.gmail.com  
Backpatch-through: 13, where the hashagg spilling code was added.  

commit   : e576f71fbe713d9357d1b480b4993043f7fcc73a    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 30 Jun 2020 17:31:08 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 30 Jun 2020 17:31:08 +0200    

Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  

commit   : aa90d9957bd2d9ce39f9078d15914a37d99af072    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Jun 2020 12:26:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Jun 2020 12:26:51 -0400    

In a few cases, the documented syntax specified storage parameter values  
as required.  
  
Reported-by: galiev_mr@taximaxim.ru  
  
Discussion: https://postgr.es/m/159283163235.684.4482737698910467437@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 2a06cb86dbacdf19a19d5bfd00d5156584f2188a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Jun 2020 11:55:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 30 Jun 2020 11:55:53 -0400    

Previously it was specified to be only replica.  
  
Discussion: https://postgr.es/m/20200618180058.GK7349@momjian.us  
  
Backpatch-through: 9.5  

commit   : 9bae7e4cde7c9786ee61dac4a3e032b346350a88    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Jun 2020 23:55:07 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 30 Jun 2020 23:55:07 +0900    

By using these operators, the number of bytes can be added into and  
subtracted from LSN.  
  
Bump catalog version.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Asif Rehman  
Discussion: https://postgr.es/m/ed9f7f74-e996-67f8-554a-52ebd3779b3b@oss.nttdata.com  

commit   : 324435eb14e4f41cd430f96c9b13ad9b160e45e4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Jun 2020 13:26:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Jun 2020 13:26:11 +0900    

Any frontend-only file of src/common/ should include a protection to  
prevent such code to be included in the backend compilation.  
fe_memutils.c and restricted_token.c have been doing that, while  
file_utils.c (since bf5bb2e) and logging.c (since fc9a62a) forgot it.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200625080757.GI130132@paquier.xyz  

commit   : ee0202d552791f14bc407ce299628ce8d50eebe3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 30 Jun 2020 00:29:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 30 Jun 2020 00:29:35 +0200    

TOAST tables have a visibility map and a free space map, so they can  
be supported by pgstattuple_approx just fine.  
  
Add test cases to show how various pgstattuple functions accept TOAST  
tables.  Also add similar tests to pg_visibility, which already  
accepted TOAST tables correctly but had no test coverage for them.  
  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://www.postgresql.org/message-id/flat/27c4496a-02b9-dc87-8f6f-bddbef54e0fe@2ndquadrant.com  

commit   : ea57e531b9487e042131ca1151a3ef5d655f40ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2020 18:55:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2020 18:55:01 -0400    

The IANA tzcode library has a feature to read a time zone file named  
"posixrules" and apply the daylight-savings transition dates and times  
therein, when it is given a POSIX-style time zone specification that  
lacks an explicit transition rule.  However, there's a problem with  
that code: it doesn't work for dates past the Y2038 time_t rollover.  
(Effectively, all times beyond that point are treated as standard  
time.)  The IANA crew regard this feature as legacy, so their plan is  
to remove it not fix it.  The time frame in which that will happen  
is unclear, but presumably it'll happen well before 2038.  
  
Moreover, effective with the next IANA data update (probably this  
fall), the recommended default will be to not install a "posixrules"  
file in the first place.  The time frame in which tzdata packagers  
might adopt that suggestion is likewise unclear, but at least some  
platforms will probably do it in the next year or so.  While we could  
ignore that recommendation so far as PG-supplied tzdata trees are  
concerned, builds using --with-system-tzdata will be subject to  
whatever the platform's tzdata packager decides to do.  
  
Thus, whether or not we do anything, some increasing fraction of  
Postgres users will be exposed to the behavior observed when there  
is no "posixrules" file; and if we do nothing, we'll have essentially  
no control over the timing of that change.  
  
The best thing to do to ameliorate the uncertainty seems to be to  
proactively remove the posixrules-reading feature.  If we do that in  
a scheduled release then at least we can release-note the behavioral  
change, rather than having users be surprised by it after a routine  
tzdata update.  
  
The change in question is fairly minor anyway: to be affected,  
you have to be using a POSIX-style timezone spec, it has to not  
have an explicit rule, and it has to not be one of the four traditional  
continental-USA zone names (EST5EDT, CST6CDT, MST7MDT, or PST8PDT),  
as those are special-cased.  Since the default "posixrules" file  
provides USA DST rules, the number of people who are likely to find  
such a zone spec useful is probably quite small.  Moreover, the  
fallback behavior with no explicit rule and no "posixrules" file is to  
apply current USA rules, so the only thing that really breaks is the  
DST transitions in years before 2007 (and you get the countervailing  
fix that transitions after 2038 will be applied).  
  
Now, some installations might have replaced the "posixrules" file,  
allowing e.g. EU rules to be applied to a POSIX-style timezone spec.  
That won't work anymore.  But it's not exactly clear why this solution  
would be preferable to using a regular named zone.  In any case, given  
the Y2038 issue, we need to be pushing users to stop depending on this.  
  
Back-patch into v13; it hasn't been released yet, so it seems OK to  
change its behavior.  (Personally I think we ought to back-patch  
further, but I've been outvoted.)  
  
Discussion: https://postgr.es/m/1390.1562258309@sss.pgh.pa.us  
Discussion: https://postgr.es/m/20200621211855.6211-1-eggert@cs.ucla.edu  

commit   : c410af098c46949e36607eb13689e697fa2def97    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2020 17:12:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2020 17:12:38 -0400    

Commit 54cd4f045 added some kluges to work around an old glibc bug,  
namely that %.*s could misbehave if glibc thought any characters in  
the supplied string were incorrectly encoded.  Now that we use our  
own snprintf.c implementation, we need not worry about that bug (even  
if it still exists in the wild).  Revert a couple of particularly  
ugly hacks, and remove or improve assorted comments.  
  
Note that there can still be encoding-related hazards here: blindly  
clipping at a fixed length risks producing wrongly-encoded output  
if the clip splits a multibyte character.  However, code that's  
doing correct multibyte-aware clipping doesn't really need a comment  
about that, while code that isn't needs an explanation why not,  
rather than a red-herring comment about an obsolete bug.  
  
Discussion: https://postgr.es/m/279428.1593373684@sss.pgh.pa.us  

commit   : f7a476f0d656bbc673474b9165cd05fa548c18c9    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 29 Jun 2020 12:30:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 29 Jun 2020 12:30:39 -0700    

Minor oversight in commit fab25024338.  

commit   : 16e3ad5d143795b05a21dc887c2ab384cce4bcb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2020 11:41:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2020 11:41:19 -0400    

Since %c only passes a C "char" to printf, it's incapable of dealing  
with multibyte characters.  Passing just the first byte of such a  
character leads to an output string that is visibly not correctly  
encoded, resulting in undesirable behavior such as encoding conversion  
failures while sending error messages to clients.  
  
We've lived with this issue for a long time because it was inconvenient  
to avoid in a portable fashion.  However, now that we always use our own  
snprintf code, it's reasonable to use the %.*s format to print just one  
possibly-multibyte character in a string.  (We previously avoided that  
obvious-looking answer in order to work around glibc's bug #6530, cf  
commits 54cd4f045 and ed437e2b2.)  
  
Hence, run around and fix a bunch of places that used %c to report  
a character found in a user-supplied string.  For simplicity, I did  
not touch places that were emitting non-user-facing debug messages,  
or reporting catalog data that should always be ASCII.  (It's also  
unclear how useful this approach could be in frontend code, where  
it's less certain that we know what encoding we're dealing with.)  
  
In passing, improve a couple of poorly-written error messages in  
pageinspect/heapfuncs.c.  
  
This is a longstanding issue, but I'm hesitant to back-patch because  
of the impact on translatable message strings.  In any case this fix  
would not work reliably before v12.  
  
Tom Lane and Quan Zongliang  
  
Discussion: https://postgr.es/m/a120087c-4c88-d9d4-1ec5-808d7a7f133d@gmail.com  

commit   : 78c887679d7632c1211f85eb95723f3226bf1b46    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jun 2020 11:04:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jun 2020 11:04:42 +0200    

SQL:1999 had syntax  
  
    SUBSTRING(text FROM pattern FOR escapechar)  
  
but this was replaced in SQL:2003 by the more clear  
  
    SUBSTRING(text SIMILAR pattern ESCAPE escapechar)  
  
but this was never implemented in PostgreSQL.  This patch adds that  
new syntax as an alternative in the parser, and updates documentation  
and tests to indicate that this is the preferred alternative now.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Vik Fearing <vik@postgresfriends.org>  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/a15db31c-d0f8-8ce0-9039-578a31758adb%402ndquadrant.com  

commit   : aafefb4dcbf79e8cb1439e888a9cdb3dfefa7657    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jun 2020 10:36:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jun 2020 10:36:52 +0200    

Simplify the grammar specification of substring() and overlay() a bit,  
simplify and update some comments.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Vik Fearing <vik@postgresfriends.org>  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/a15db31c-d0f8-8ce0-9039-578a31758adb%402ndquadrant.com  

commit   : 68de1440c79d75e529ff8c7395d698252370f992    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jun 2020 09:56:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jun 2020 09:56:52 +0900    

The logic used to build the set of dependencies needed for a type is  
rather repetitive with direct assignments for each ObjectAddress field.  
This refactors the code to use the macro ObjectAddressSet() instead, to  
do the same work.  There are more areas of the backend code that could  
use this macro, but these are left for a follow-up patch that will  
partially rework the way dependencies are recorded as well.  Type  
dependencies are left out of the follow-up patch, so they are refactored  
separately here.  
  
Extracted from a larger patch by the same author.  
  
Author: Daniel Gustafsson  
Discussion: https://potgr.es/m/20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de  

commit   : 96879a0efb65b9cde0a688201516633aa79fd5b0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 27 Jun 2020 22:05:04 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 27 Jun 2020 22:05:04 -0700    

Warnings start 10M transactions before xidStopLimit, which is 11M  
transactions before wraparound.  The sample WARNING output showed a  
value greater than 11M, and its HINT message predated commit  
25ec228ef760eb91c094cc3b6dea7257cc22ffb5.  Hence, the sample was  
impossible.  Back-patch to 9.5 (all supported versions).  

commit   : e1cc25f59a8a90d821aaf894e1691575ed94454e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2020 13:26:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2020 13:26:17 -0400    

Apparently 1.0.1 lacks SSL_R_VERSION_TOO_HIGH and  
SSL_R_VERSION_TOO_LOW.  Per buildfarm.  

commit   : b63dd3d88f479947ef7fb7cbf5db27de66ae0654    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2020 12:47:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2020 12:47:58 -0400    

OpenSSL's native reports about problems related to protocol version  
restrictions are pretty opaque and inconsistent.  When we get an  
SSL error that is plausibly due to this, emit a hint message that  
includes the range of SSL protocol versions we (think we) are  
allowing.  This should at least get the user thinking in the right  
direction to resolve the problem, even if the hint isn't totally  
accurate, which it might not be for assorted reasons.  
  
Back-patch to v13 where we increased the default minimum protocol  
version, thereby increasing the risk of this class of failure.  
  
Patch by me, reviewed by Daniel Gustafsson  
  
Discussion: https://postgr.es/m/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com  

commit   : 6e682f61a5bdb08164a805419144318db6b7229f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2020 12:20:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2020 12:20:33 -0400    

When we initially created this parameter, in commit ff8ca5fad, we left  
the default as "allow any protocol version" on grounds of backwards  
compatibility.  However, that's inconsistent with the backend's default  
since b1abfec82; protocol versions prior to 1.2 are not considered very  
secure; and OpenSSL has had TLSv1.2 support since 2012, so the number  
of PG servers that need a lesser minimum is probably quite small.  
  
On top of those things, it emerges that some popular distros (including  
Debian and RHEL) set MinProtocol=TLSv1.2 in openssl.cnf.  Thus, far  
from having "allow any protocol version" behavior in practice, what  
we actually have as things stand is a platform-dependent lower limit.  
  
So, change our minds and set the min version to TLSv1.2.  Anybody  
wanting to connect with a new libpq to a pre-2012 server can either  
set ssl_min_protocol_version=TLSv1 or accept the fallback to non-SSL.  
  
Back-patch to v13 where the aforementioned patches appeared.  
  
Patch by me, reviewed by Daniel Gustafsson  
  
Discussion: https://postgr.es/m/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com  

commit   : e7b476c657ebe4c0a47fa14b8f1c7ec767067585    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 27 Jun 2020 09:54:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 27 Jun 2020 09:54:51 +0530    

As this doesn't cause any harm so we decided to this clean up in HEAD only.  
  
Author: Ádám Balogh  
Discussion: https://postgr.es/m/VI1PR0702MB36631BD67559461AFDE1FEEE81920@VI1PR0702MB3663.eurprd07.prod.outlook.com  

commit   : 4ae08cd5fd19d566538005c15e7bf992ebae4c72    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jun 2020 20:41:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jun 2020 20:41:29 -0400    

We failed to save slot to disk after invalidating it, so the state was  
lost in case of server restart or crash.  Fix by marking it dirty and  
flushing.  
  
Also, if the slot is known invalidated we don't need to reason about the  
LSN at all -- it's known invalidated.  Only test the LSN if the slot is  
known not invalidated.  
  
Author: Fujii Masao <masao.fujii@oss.nttdata.com>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/17a69cfe-f1c1-a416-ee25-ae15427c69eb@oss.nttdata.com  

commit   : eca08f58d05f45c4cae02bca5e1556ba58732fc4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jun 2020 13:54:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jun 2020 13:54:01 -0400    

Back-patch to v13; before that, there's not really space for this  
kind of detail.  
  
Discussion: https://postgr.es/m/c1696f68-fa8d-7759-6a9c-eb293ab1bbc9@gmx.net  

commit   : 81d46ea12cef2391a4cae63c1f3951401e3dd883    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jun 2020 18:33:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jun 2020 18:33:28 -0400    

Reported-by: petermpallesen@gmail.com  
  
Discussion: https://postgr.es/m/159195294959.673.5752624528747900508@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : d352de8d8eb7102e51e6adf0a965a9eae09e3f39    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jun 2020 18:22:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jun 2020 18:22:44 -0400    

That is, those database permissions set by GRANT.  
  
Diagnosed-by: Joseph Nahmias  
  
Discussion: https://postgr.es/m/20200614072613.GA21852@nahmias.net  
  
Backpatch-through: 9.5  

commit   : 10f1ab2cb8bea3c6741a78f6dc19a5c91c0a34e1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 25 Jun 2020 10:55:28 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 25 Jun 2020 10:55:28 -0700    

Commit 0d861bbb, which added deduplication to nbtree, had  
_bt_check_unique() pass a TID to table_index_fetch_tuple_check() that  
isn't safe to mutate.  table_index_fetch_tuple_check()'s tid argument is  
modified when the TID in question is not the latest visible tuple in a  
hot chain, though this wasn't documented.  
  
To fix, go back to using a local copy of the TID in _bt_check_unique(),  
and update comments above table_index_fetch_tuple_check().  
  
Backpatch: 13-, where B-Tree deduplication was introduced.  

commit   : 463b808e757928f053490dd397af77a80b4e7baa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2020 13:28:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2020 13:28:30 -0400    

Daniel Gustafsson and Erik Rijkers, per report from nick@cleaton  
  
Discussion: https://postgr.es/m/159275646273.679.16940709892308114570@wrigleys.postgresql.org  

commit   : a82ba066ea217e7fe4da3c20ced01e7ca976a351    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Jun 2020 11:13:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Jun 2020 11:13:13 +0900    

If restart_lsn of logical replication slot gets behind more than  
max_slot_wal_keep_size from the current LSN, the logical replication slot  
would be invalidated and its restart_lsn is reset to an invalid LSN.  
If this logical replication slot with an invalid restart_lsn was specified as  
the source slot in pg_copy_logical_replication_slot(), the function caused  
the assertion failure unexpectedly.  
  
This assertion was added because restart_lsn should not be invalid before.  
But in v13, it can be invalid thanks to max_slot_wal_keep_size. So since this  
assertion is no longer useful, this commit removes it.  
  
This commit also changes the errcode in the error message that  
pg_copy_logical_replication_slot() emits when the slot with an invalid  
restart_lsn is specified, to more appropriate one.  
  
Back-patch to v13 where max_slot_wal_keep_size was added and  
the assertion was no longer valid.  
  
Author: Fujii Masao  
Reviewed-by: Alvaro Herrera, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/f91de4fb-a7ab-b90e-8132-74796e049d51@oss.nttdata.com  

commit   : 235c0f6eed2d9f5650f9b6ee0c51601792eff8e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jun 2020 15:47:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jun 2020 15:47:30 -0400    

I forgot that INT64_FORMAT can't be used with sscanf on Windows.  
Use the same trick of sscanf'ing into a temp variable as we do in  
some other places in zic.c.  
  
The upstream IANA code avoids the portability problem by relying on  
<inttypes.h>'s SCNdFAST64 macro.  Once we're requiring C99 in all  
branches, we should do likewise and drop this set of diffs from  
upstream.  For now, though, a hack seems fine, since we do not  
actually care about leapseconds anyway.  
  
Discussion: https://postgr.es/m/4e5d1a5b-143e-e70e-a99d-a3b01c1ae7c3@2ndquadrant.com  

commit   : b8fd4e02c6d01183bf6def5897ad6cf7766bfff4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Jun 2020 14:23:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Jun 2020 14:23:39 -0400    

In pg_replication_slot, change output from normal/reserved/lost to  
reserved/extended/unreserved/ lost, which better expresses the possible  
states particularly near the time where segments are no longer safe but  
checkpoint has not run yet.  
  
Under the new definition, reserved means the slot is consuming WAL  
that's still under the normal WAL size constraints; extended means it's  
consuming WAL that's being protected by wal_keep_segments or the slot  
itself, whose size is below max_slot_wal_keep_size; unreserved means the  
WAL is no longer safe, but checkpoint has not yet removed those files.  
Such as slot is in imminent danger, but can still continue for a little  
while and may catch up to the reserved WAL space.  
  
Also, there were some bugs in the calculations used to report the  
status; fixed those.  
  
Backpatch to 13.  
  
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200616.120236.1809496990963386593.horikyota.ntt@gmail.com  

commit   : 0188bb82531f1b0ae3648fb81a4bd4a4f6242127    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Jun 2020 14:15:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Jun 2020 14:15:17 -0400    

We put it aside as invalidated_at, which let us show "lost" in  
pg_replication slot.  Prior to this change, the state value was reported  
as NULL.  
  
Backpatch to 13.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200617.101707.1735599255100002667.horikyota.ntt@gmail.com  
Discussion: https://postgr.es/m/20200407.120905.1507671100168805403.horikyota.ntt@gmail.com  

commit   : 368d7f3297e7e1304da03904d2e1310d79fa82a9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Jun 2020 14:00:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Jun 2020 14:00:37 -0400    

The current definition is dangerous.  No bugs exist in our code at  
present, but backpatch to 11 nonetheless where it was introduced.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : a3554b2d718520cbd16c13ff5c9f2e8257846170    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jun 2020 15:14:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jun 2020 15:14:04 +0900    

The description of InsertPgAttributeTuple() does not match its handling  
of pg_attribute contents with NULL values for a long time, with 911e702  
making things more inconsistent.  This adjusts the description to match  
the reality.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/4E4E4B33-9FDF-4D21-B77A-642D027AEAD9@yesql.se  

commit   : 7ce461560159948ba0c802c767e42c5f5ae08b4a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 22 Jun 2020 12:14:55 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 22 Jun 2020 12:14:55 -0700    

Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20200620220402.GZ17995@telsasoft.com  
Backport-through: 13  

commit   : 63d2ac23b018c2b173f42d274ae46b7b0c3263df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jun 2020 11:46:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jun 2020 11:46:41 -0400    

explain_get_index_name() applied quote_identifier() to the index name.  
This is fine for text output, but the non-text output formats all have  
their own quoting conventions and would much rather start from the  
actual index name.  For example in JSON you'd get something like  
  
       "Index Name": "\"My Index\"",  
  
which is surely not desirable, especially when the same does not  
happen for table names.  Hence, move the responsibility for applying  
quoting out to the callers, where it can go into already-existing  
special code paths for text format.  
  
This changes the API spec for users of explain_get_index_name_hook:  
before, they were supposed to apply quote_identifier() if necessary,  
now they should not.  Research suggests that the only publicly  
available user of the hook is hypopg, and it actually forgot to  
apply quoting anyway, so it's fine.  (In any case, there's no  
behavioral change for the output of a hook as seen in non-text  
EXPLAIN formats, so this won't break any case that programs should  
be relying on.)  
  
Digging in the commit logs, it appears that quoting was included in  
explain_get_index_name's duties when commit 604ffd280 invented it;  
and that was fine at the time because we only had text output format.  
This should have been rethought when non-text formats were invented,  
but it wasn't.  
  
This is a fairly clear bug for users of non-text EXPLAIN formats,  
so back-patch to all supported branches.  
  
Per bug #16502 from Maciek Sakrejda.  Patch by me (based on  
investigation by Euler Taveira); thanks to Julien Rouhaud for review.  
  
Discussion: https://postgr.es/m/16502-57bd1c9f913ed1d1@postgresql.org  

commit   : fe186b4c200b76a5c0f03379fe8645ed1c70a844    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jun 2020 13:40:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jun 2020 13:40:04 +0900    

Some fields related to pg_opclass and pg_opfamily were using incorrect  
markups, listing them as structname instead of structfield.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2006210903560.859381@pseudo  

commit   : 9550ea3027aa4f290c998afd8836a927df40b09d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jun 2020 13:23:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jun 2020 13:23:38 +0900    

Both INDEX_CLEANUP and TRUNCATE have been available since v12, and are  
enabled by default except if respectively vacuum_index_cleanup and  
vacuum_truncate are disabled for a given relation.  This change adds  
support for disabling these options from vacuumdb.  
  
Author: Nathan Bossart  
Reviewed-by: Michael Paquier, Masahiko Sawada  
Discussion: https://postgr.es/m/6F7F17EF-B1F2-4681-8D03-BA96365717C0@amazon.com  

commit   : 14903f238ec999802df5c539010c6be32d72f8cd    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 21 Jun 2020 04:48:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 21 Jun 2020 04:48:03 +0300    

Discussion: https://postgr.es/m/20200620232145.GB17995%40telsasoft.com  
Author: Justin Pryzby  
Backpatch-through: 13  

commit   : 48c6959864491964ae3f893af8242d5770b3d3d2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jun 2020 17:34:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jun 2020 17:34:07 -0700    

Defining duplicates as "close by" to each other was unclear.  Simplify  
the definition.  
  
Backpatch: 13-, where deduplication was introduced (by commit 0d861bbb)  

commit   : 3be015c9fc02316f1f1579301391fb5c67731057    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 21 Jun 2020 00:35:42 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 21 Jun 2020 00:35:42 +0300    

Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzmwhYbxuoL0WjTLaiCxW3gj6qadeNpBhWAo_KZsE5-FGw%40mail.gmail.com  

commit   : a44dd932ff3816de7fe0414063cfcc5656117c3a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 20 Jun 2020 17:34:51 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 20 Jun 2020 17:34:51 +0300    

spg_mask() didn't take into account that pd_lower equal to SizeOfPageHeaderData  
is still valid value.  This commit fixes that.  Backpatch to 11, where  
spg_mask() pg_lower check was introduced.  
  
Reported-by: Michael Paquier  
Discussion: https://postgr.es/m/20200615131405.GM52676%40paquier.xyz  
Backpatch-through: 11  

commit   : 15cb2bd27009f73a84a35c2ba60fdd105b4bf263    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 20 Jun 2020 13:34:54 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 20 Jun 2020 13:34:54 +0300    

911e7020770 added opclass options and adjusted documentation for each  
particular affected opclass.  However, documentation for extendability was  
not adjusted.  This commit adjusts documentation for interfaces of index AMs  
and opclasses.  
  
Discussion: https://postgr.es/m/CAH2-WzmQnW6%2Bz5F9AW%2BSz%2BzEcEvXofTwh_A9J3%3D_WA-FBP0wYg%40mail.gmail.com  
Author: Alexander Korotkov  
Reported-by: Peter Geoghegan  
Reviewed-by: Peter Geoghegan  

commit   : d28ab91e7155353d4377abad5a7d5b0f07450867    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 20 Jun 2020 01:25:40 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 20 Jun 2020 01:25:40 -0700    

The function has been reading global variable forceSyncCommit, mirroring  
the intent of the caller that passed forceSync=forceSyncCommit.  The  
other caller, RecordTransactionCommitPrepared(), passed false.  Since  
COMMIT PREPARED can't share a transaction with any command, it certainly  
doesn't share a transaction with a command that sets forceSyncCommit.  
  
Reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/20200617032615.GC2916904@rfd.leadboat.com  

commit   : 74b4d78e037c1d4d55fd61f1b58c161e6249dfde    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 20 Jun 2020 09:18:57 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 20 Jun 2020 09:18:57 +0530    

The function parameter column_no is not used in CopyReadBinaryAttribute,  
this can be removed.  
  
Commit 0e319c7ad7 removed the usage of column_no parameter in function  
CopyReadBinaryAttribute but forgot to remove the parameter.  
  
Reported-by: Vignesh C  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm1TYSNTfqx_jfz9_mwEZ2Er=dZnu++duXpC1uQo1cG=WA@mail.gmail.com  

commit   : ae3259c55067c926d25c745d70265fca15c2d26b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2020 16:46:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2020 16:46:07 -0400    

A few places calling fwrite and gzwrite were not setting errno to ENOSPC  
when reporting errors, as is customary; this led to some failures being  
reported as  
"could not write file: Success"  
which makes us look silly.  Make a few of these places in pg_dump and  
pg_basebackup use our customary pattern.  
  
Backpatch-to: 9.5  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200611153753.GU14879@telsasoft.com  

commit   : 2c8ef9363db199aed9e8f17edba866b1215803c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2020 13:55:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2020 13:55:21 -0400    

The IANA time zone folk have deprecated use of a "posixrules" file in  
the tz database.  While for now it's our choice whether to keep  
supplying one in our own builds, installations built with  
--with-system-tzdata will soon be needing to cope with that file not  
being present, at least on some platforms.  
  
This causes a problem for the horology test, which expected the  
nonstandard POSIX zone spec "CST7CDT" to apply pre-2007 US daylight  
savings rules.  That does happen if the posixrules file supplies such  
information, but otherwise the test produces undesired results.  
To fix, add an explicit transition date rule that matches 2005 practice.  
(We could alternatively have switched the test to use some real time  
zone, but it seems useful to have coverage of this type of zone spec.)  
  
While at it, update a documentation example that also relied on  
"CST7CDT"; use a real-world zone name instead.  Also, document why  
the zone names EST5EDT, CST6CDT, MST7MDT, PST8PDT aren't subject to  
similar failures when "posixrules" is missing.  
  
Back-patch to all supported branches, since the hazard is the same  
for all.  
  
Discussion: https://postgr.es/m/1665379.1592581287@sss.pgh.pa.us  

commit   : 816cbb59e3008112c5b217af7b9213b7a09881bf    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2020 12:55:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2020 12:55:43 -0400    

Mostly in response to Jürgen Purtz critique of previous definitions,  
though I added many other changes.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Jürgen Purtz <juergen@purtz.de>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/c1e06008-2132-30f4-9b38-877e8683d418@purtz.de  

commit   : be14f884d57bc9c8ec8415edafea35ba5d31af59    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 19 Jun 2020 08:57:24 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 19 Jun 2020 08:57:24 -0700    

It was possible for deduplication's single value strategy to mistakenly  
believe that a very small duplicate tuple counts as one of the six large  
tuples that it aims to leave behind after the page finally splits.  This  
could cause slightly suboptimal space utilization with very low  
cardinality indexes, though only under fairly narrow conditions.  
  
To fix, be particular about what kind of tuple counts as a  
maxpostingsize-capped tuple.  This avoids confusion in the event of a  
small tuple that gets "wedged" between two large tuples, where all  
tuples on the page are duplicates of the same value.  
  
Discussion: https://postgr.es/m/CAH2-Wz=Y+sgSFc-O3LpiZX-POx2bC+okec2KafERHuzdVa7-rQ@mail.gmail.com  
Backpatch: 13-, where deduplication was introduced (by commit 0d861bbb)  

commit   : f9e9704f09daf882f5a1cf1fbe3f5a3150ae2bb9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Jun 2020 17:15:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Jun 2020 17:15:52 +0900    

This commit fixes the following issues.  
  
1. There is the case where the slot is dropped while trying to invalidate it.  
    InvalidateObsoleteReplicationSlots() did not handle this case, and  
    which could cause checkpoint to fail.  
  
2. InvalidateObsoleteReplicationSlots() could emit the same log message  
    multiple times unnecessary. It should be logged only once.  
  
3. When marking the slot as used, we always searched the target slot from  
    all the replication slots even if we already found it. This could cause  
    useless waste of cycles.  
  
Back-patch to v13 where these issues were added as a part of  
max_slot_wal_keep_size code.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Alvaro Herrera  
Discussion: https://postgr.es/m/66c05b67-3396-042c-1b41-bfa6c3ddcf82@oss.nttdata.com  

commit   : 9bdb300dedf086cc54edf740088208e6b24307ef    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 19 Jun 2020 17:24:27 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 19 Jun 2020 17:24:27 +1200    

Since 1f39bce02, HashAgg nodes have had the ability to spill to disk when  
memory consumption exceeds work_mem. That commit added new properties to  
EXPLAIN ANALYZE to show the maximum memory usage and disk usage, however,  
it didn't quite go as far as showing that information for parallel  
workers.  Since workers may have experienced something very different from  
the main process, we should show this information per worker, as is done  
in Sort.  
  
Reviewed-by: Justin Pryzby  
Reviewed-by: Jeff Davis  
Discussion: https://postgr.es/m/CAApHDvpEKbfZa18mM1TD7qV6PG+w97pwCWq5tVD0dX7e11gRJw@mail.gmail.com  
Backpatch-through: 13, where the hashagg spilling code was added.  

commit   : f219167910ad33dfd8f1b0bba15323d71a91c4e9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 18 Jun 2020 19:40:09 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 18 Jun 2020 19:40:09 -0700    

Users of spinlocks should use spin.h, not s_lock.h. And lwlock.h  
hasn't utilized spinlocks for quite a while.  
  
Discussion: https://postgr.es/m/20200618183041.upyrd25eosecyf3x@alap3.anarazel.de  

commit   : cf1234a10e50ff9be0dc85184689ee4ebc57cd77    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 16:50:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 16:50:37 -0700    

This was a danger only for --disable-spinlocks in combination with  
atomic operations unsupported by the current platform.  
  
While atomics.c was careful to signal that a separate semaphore ought  
to be used when spinlock emulation is active, spin.c didn't actually  
implement that mechanism. That's my (Andres') fault, it seems to have  
gotten lost during the development of the atomic operations support.  
  
Fix that issue and add test for nesting atomic operations inside a  
spinlock.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20200605023302.g6v3ydozy5txifji@alap3.anarazel.de  
Backpatch: 9.5-  

commit   : 3b37a6de027c27f1e4ac865aaa34dd92cf5dc7a1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 16:36:51 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 16:36:51 -0700    

As s_lock_test, the already existing test for spinlocks, isn't run in  
an automated fashion (and doesn't test a normal backend environment),  
adding tests that are run as part of a normal regression run is a good  
idea. Particularly in light of several recent and upcoming spinlock  
related fixes.  
  
Currently the new tests are run as part of the pre-existing  
test_atomic_ops() test. That perhaps can be quibbled about, but for  
now seems ok.  
  
The only operations that s_lock_test tests but the new tests don't are  
the detection of a stuck spinlock and S_LOCK_FREE (which is otherwise  
unused, not implemented on all platforms, and will be removed).  
  
This currently contains a test for more than INT_MAX spinlocks (only  
run with --disable-spinlocks), to ensure the recent commit fixing a  
bug with more than INT_MAX spinlock initializations is correct. That  
test is somewhat slow, so we might want to disable it after a few  
days.  
  
It might be worth retiring s_lock_test after this. The added coverage  
of a stuck spinlock probably isn't worth the added complexity?  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20200606023103.avzrctgv7476xj7i@alap3.anarazel.de  

commit   : a3235a53ae9f6f21f823081c610b0901db6aa665    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jun 2020 16:27:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jun 2020 16:27:18 -0400    

We'd glossed over most of this complexity for years, but it's hard  
to avoid writing it all down now, so that we can explain what happens  
when there's no "posixrules" file in the IANA time zone database.  
That was at best a tiny minority situation till now, but it's likely  
to become quite common in the future, so we'd better explain it.  
  
Nonetheless, we don't really encourage people to use POSIX zone specs;  
picking a named zone is almost always what you really want, unless  
perhaps you're stuck with an out-of-date zone database.  Therefore,  
let's shove all this detail into an appendix.  
  
Patch by me; thanks to Robert Haas for help with some awkward wording.  
  
Discussion: https://postgr.es/m/1390.1562258309@sss.pgh.pa.us  

commit   : b48df818dcbd1a5e34ab7a2d9f98828b7b62140c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2020 16:34:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2020 16:34:59 +0900    

Advancing a replication slot did not recompute the oldest xmin and LSN  
values across replication slots, preventing resource removal like  
segments not recycled at checkpoint time.  The original commit that  
introduced the slot advancing in 9c7d06d never did the update of those  
oldest values, and b0afdca removed this code.  
  
This commit adds a TAP test to check segment recycling with advancing  
for physical slots, enforcing an extra segment switch before advancing  
to check if the segment gets correctly recycled after a checkpoint.  
  
Reported-by: Andres Freund  
Reviewed-by: Alexey Kondratov, Kyptaro Horiguchi  
Discussion: https://postgr.es/m/20200609171904.kpltxxvjzislidks@alap3.anarazel.de  
Backpatch-through: 11  

commit   : 0a40563eadc67472d6fd50dabf7002afa25c3330    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 18 Jun 2020 08:41:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 18 Jun 2020 08:41:31 +0200    

The previous implementation returned 1 for all negative numbers, which  
is not sensible under any definition.  
  
Discussion: https://www.postgresql.org/message-id/flat/6ce1df0e-86a3-e544-743a-f357ff663f68%402ndquadrant.com  

commit   : 9d402c73ade412bdeb9064c81fc4ed071c4e93f8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 18 Jun 2020 08:41:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 18 Jun 2020 08:41:31 +0200    

Move from int4 to numeric test.  (They were originally int4 functions,  
but were reimplemented for numeric in  
04a4821adef38155b7920ba9eb83c4c3c29156f8.)  Add some tests for edge  
cases.  
  
Discussion: https://www.postgresql.org/message-id/flat/6ce1df0e-86a3-e544-743a-f357ff663f68%402ndquadrant.com  

commit   : 2b2a070d98b2f2c7ecc031e582cfefa400316ce3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2020 10:40:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2020 10:40:10 +0900    

testtablespace is an extra path used as tablespace location in the main  
regression test suite, computed from --outputdir as defined by the  
caller of pg_regress (current directory if undefined).  
  
This special handling was introduced as of f10589e to be specific to  
MSVC, as we let pg_regress' Makefile handle this cleanup in other  
environments.  This moves the cleanup to the MSVC script running  
regression tests instead where needed: check, installcheck and  
upgradecheck.  I have also checked this patch on MSVC with repeated runs  
of each target.  
  
Author: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20200219.142519.437573253063431435.horikyota.ntt@gmail.com  

commit   : d8b15eeb8a1acbe01b502ddd3390d7f1824c7a25    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jun 2020 18:29:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jun 2020 18:29:29 -0400    

This absorbs a leap-second-related bug fix in localtime.c, and  
teaches zic to handle an expiration marker in the leapseconds file.  
Neither are of any interest to us (for the foreseeable future  
anyway), but we need to stay more or less in sync with upstream.  
  
Also adjust some over-eager changes in the README from commit 957338418.  
I have no intention of making changes that require C99 in this code,  
until such time as all the live back branches require C99.  Otherwise  
back-patching will get too exciting.  
  
For the same reason, absorb assorted whitespace and other cosmetic  
changes from HEAD into the back branches; mostly this reflects use of  
improved versions of pgindent.  
  
All in all then, quite a boring update.  But I figured I'd get it  
done while I was looking at this code.  

commit   : 6924c37f772cd7701d3e1267a1fb3221ca159ba4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 17 Jun 2020 15:23:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 17 Jun 2020 15:23:55 -0700    

Oversight in commit 0d861bbb.  

commit   : 4d4ca24efe8ebda9547337f47dcb61d3163be765    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 15:25:49 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 15:25:49 -0700    

Once the counter goes negative we ended up with spinlocks that errored  
out on first use (due to check in tas_sema).  
  
Author: Andres Freund  
Reviewed-By: Robert Haas  
Discussion: https://postgr.es/m/20200606023103.avzrctgv7476xj7i@alap3.anarazel.de  
Backpatch: 9.5-  

commit   : fd49d53807575e009f7b66771d48c9356344d7d1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 18:23:10 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 15 Jun 2020 18:23:10 -0700    

On platforms without support for 64bit atomic operations where we also  
cannot rely on 64bit reads to have single copy atomicity, such atomics  
are implemented using a spinlock based fallback. That means it's not  
safe to even read such atomics from within a signal handler (since the  
signal handler might run when the spinlock already is held).  
  
To avoid this issue defer global barrier processing out of the signal  
handler. Instead of checking local / shared barrier generation to  
determine whether to set ProcSignalBarrierPending, introduce  
PROCSIGNAL_BARRIER and always set ProcSignalBarrierPending when  
receiving such a signal. Additionally avoid redundant work in  
ProcessProcSignalBarrier if ProcSignalBarrierPending is unnecessarily.  
  
Also do a small amount of other polishing.  
  
Author: Andres Freund  
Reviewed-By: Robert Haas  
Discussion: https://postgr.es/m/20200609193723.eu5ilsjxwdpyxhgz@alap3.anarazel.de  
Backpatch: 13-, where the code was introduced.  

commit   : 2fd2effc50824a8775a088435a13f47b7a6f3b94    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jun 2020 11:39:17 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jun 2020 11:39:17 -0400    

Don't use fread(), since that doesn't necessarily set errno. We could  
use read() instead, but it's even better to use pg_pread(), which  
allows us to avoid some extra calls to seek to the desired location in  
the file.  
  
Also, advertise a wait event while reading from a file, as we do for  
most other places where we're reading data from files.  
  
Patch by me, reviewed by Hamid Akhtar.  
  
Discussion: http://postgr.es/m/CA+TgmobBw-3573vMosGj06r72ajHsYeKtksT_oTxH8XvTL7DxA@mail.gmail.com  

commit   : 453e0e3f0ef3202386b553719f628cef93ff95a7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jun 2020 11:05:42 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jun 2020 11:05:42 -0400    

Merge two calls to sendDir() that are exactly the same except for  
the fifth argument. Adjust comments to match.  
  
Also, don't bother checking whether tblspc_map_file is NULL. We  
initialize it in all cases, so it can't be.  
  
Patch by me, reviewed by Amit Kapila and Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/CA+TgmoYq+59SJ2zBbP891ngWPA9fymOqntqYcweSDYXS2a620A@mail.gmail.com  

commit   : 1fa092913d260056b1aaf627ebc9cd9655c3a27c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jun 2020 10:57:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jun 2020 10:57:34 -0400    

Commit 72d422a5227ef6f76f412486a395aba9f53bf3f0 made xlog.c call  
sendTablespace() with the 'sizeonly' argument set to true, which  
required basebackup.c to export sendTablespace(). However, that's  
kind of ugly, so instead defer the call to sendTablespace() until  
basebackup.c regains control. That way, it can still be a static  
function.  
  
Patch by me, reviewed by Amit Kapila and Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/CA+TgmoYq+59SJ2zBbP891ngWPA9fymOqntqYcweSDYXS2a620A@mail.gmail.com  

commit   : a513f1dfbf2c29a51b0f7cbd5913ce2d2ee452c5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 17 Jun 2020 09:14:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 17 Jun 2020 09:14:37 +0200    

Add a separate enum for use in the locking APIs, which were the only  
user.  
  
Discussion: https://www.postgresql.org/message-id/flat/a6f91ead-0ce4-2a34-062b-7ab9813ea308%402ndquadrant.com  

commit   : 42aa1f0ab321fd43cbfdd875dd9e13940b485900    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jun 2020 16:41:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jun 2020 16:41:11 -0400    

The synopsis for PGTYPESinterval_free() used the wrong name.  
  
Discussion: https://postgr.es/m/159231203030.679.3061023914894071953@wrigleys.postgresql.org  

commit   : 3a990a1263560ef28707bc623e875e75ae42041c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jun 2020 15:28:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jun 2020 15:28:37 -0400    

Per POSIX this case should produce +0, but buildfarm member fossa  
(with icc (ICC) 19.0.5.281 20190815) is reporting -0.  icc has a  
boatload of unsafe floating-point optimizations, with a corresponding  
boatload of not-too-well-documented compiler switches, and it seems our  
default use of "-mp1" isn't whacking it hard enough to keep it from  
misoptimizing the stanza in dpow() that checks whether y is odd.  
There's nothing wrong with that code (seeing that no other buildfarm  
member has trouble with it), so I'm content to blame this on the  
compiler.  But without access to the compiler I'm not going to guess at  
what switches might be needed to fix it.  For now, tweak the test case  
so it will accept either -0 or +0 as a correct answer.  
  
Discussion: https://postgr.es/m/E1jkyFX-0005RR-1Q@gemulon.postgresql.org  

commit   : eab6e460e00d61e5aae95298a0fe8c79a1653184    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Jun 2020 17:25:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Jun 2020 17:25:20 +0200    

Broken by move of fe_archive.c to fe_utils.  

commit   : 400f16937328d50a7e8d7f0d158f7c92be1da45a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jun 2020 11:09:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jun 2020 11:09:42 -0400    

I failed to notice that we don't really need to check for y being an  
integer in the code path where x = -inf; we already did.  
  
Also make some further cosmetic rearrangements in that spot in hopes  
of dodging the seeming compiler bug that buildfarm member fossa is  
hitting.  And be consistent about declaring variables as "float8"  
not "double", since the pre-existing variables in this function are  
like that.  
  
Discussion: https://postgr.es/m/E1jkyFX-0005RR-1Q@gemulon.postgresql.org  

commit   : 4dd804a99cd66d8d336ce7060c91e23db3263c31    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jun 2020 17:40:06 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jun 2020 17:40:06 +1200    

commit   : f5d18862bbb327b67cd0f33f3d11351096080665    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jun 2020 17:23:36 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jun 2020 17:23:36 +1200    

It now either returns after it wrote all the data you gave it, or raises  
an error.  Not done in back-branches, because it might cause problems  
for external code.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJE04G%3D8TLK0DLypT_27D9dR8F1RQgNp0jK6qR0tZGWOw%40mail.gmail.com  

commit   : 7897e3bb902c557412645b82120f4d95f7474906    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jun 2020 13:50:56 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jun 2020 13:50:56 +1200    

Convert buffile.c error handling to use ereport.  This fixes cases where  
I/O errors were indistinguishable from EOF or not reported.  Also remove  
"%m" from error messages where errno would be bogus.  While we're  
modifying those strings, add block numbers and short read byte counts  
where appropriate.  
  
Back-patch to all supported releases.  
  
Reported-by: Amit Khandekar <amitdkhan.pg@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Ibrar Ahmed <ibrar.ahmad@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CA%2BhUKGJE04G%3D8TLK0DLypT_27D9dR8F1RQgNp0jK6qR0tZGWOw%40mail.gmail.com  

commit   : 4c5cf5431410f8e28fb855c892cb2880649df850    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Jun 2020 08:51:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Jun 2020 08:51:46 +0200    

This has existed for a very long time, equivalent to the ! and !!  
operators, but it was never documented.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/6ce1df0e-86a3-e544-743a-f357ff663f68%402ndquadrant.com  

commit   : 3f5863e15664757393c7a1416181fb58deac37a6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jun 2020 20:59:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jun 2020 20:59:40 -0400    

Non-zero vacuum_defer_cleanup_age values cause pg_upgrade freezing of  
the system catalogs to be incomplete, or do nothing.  This will cause  
the upgrade to fail in confusing ways.  
  
Reported-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/7d6f6c22ba05ce0c526e9e8b7bfa8105e7da45e6.camel@cybertec.at  
  
Backpatch-through: 9.5  

commit   : 5674eb98762ed41c7f9672a3bc56edf925e9d97d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2020 19:10:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2020 19:10:30 -0400    

Buildfarm results for commit e532b1d57 reveal the error in my thinking  
about the unexpected-EDOM case.  I'd supposed this was no longer really  
a live issue, but it seems the fix for glibc's bug #3866 is not all that  
old, and we still have at least one buildfarm animal (lapwing) with the  
bug.  Hence, resurrect essentially the previous logic (but, I hope, less  
opaquely presented), and explain what it is we're really doing here.  
  
Also, blindly try to fix fossa's failure by tweaking the logic that  
figures out whether y is an odd integer when x is -inf.  This smells  
a whole lot like a compiler bug, but I lack access to icc to try to  
pin it down.  Maybe doing division instead of multiplication will  
dodge the issue.  
  
Discussion: https://postgr.es/m/E1jkU7H-00024V-NZ@gemulon.postgresql.org  

commit   : 2961c9711c17e5fe05fb1fbd72c3e47f3b601ee4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Apr 2020 10:38:10 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Apr 2020 10:38:10 -0400    

Introduce TAR_BLOCK_SIZE and replace many instances of 512 with  
the new constant. Introduce function tarPaddingBytesRequired  
and use it to replace numerous repetitions of (x + 511) & ~511.  
  
Add preprocessor guards against multiple inclusion to pgtar.h.  
  
Reformat the prototype for tarCreateHeader so it doesn't extend  
beyond 80 characters.  
  
Discussion: http://postgr.es/m/CA+TgmobWbfReO9-XFk8urR1K4wTNwqoHx_v56t7=T8KaiEoKNw@mail.gmail.com  

commit   : e532b1d57df9b55557263303dba883e06521b0d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2020 12:15:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jun 2020 12:15:56 -0400    

Buildfarm results for commit decbe2bfb show that AIX and illumos  
have non-POSIX-compliant pow() functions, as do ancient NetBSD  
and HPUX releases.  While it's dubious how much we should care  
about the latter two platforms, the former two are probably enough  
reason to put in manual handling of infinite-input cases.  Hence,  
do so, and clean up the post-pow() error handling to reflect its  
now-more-limited scope.  (Notably, while we no longer expect to  
ever see EDOM from pow(), report it as a domain error if we do.  
The former coding had the net effect of expensively converting the  
error to ERANGE, which seems highly questionable: if pow() wanted  
to report ERANGE, it would have done so.)  
  
Patch by me; thanks to Michael Paquier for review.  
  
Discussion: https://postgr.es/m/E1jkU7H-00024V-NZ@gemulon.postgresql.org  

commit   : 7a3543c2ea23d032865f207c2605942b7a32e9ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2020 21:18:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2020 21:18:14 +0900    

Timestamp can only be an int64 since b9d092c, and support for WITH OIDS  
has been removed as of 578b229.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200612023709.GC14879@telsasoft.com  

commit   : 3baa7e38d51579b69e1228f3e1a43f56001b6d64    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Jun 2020 10:47:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Jun 2020 10:47:59 +0200    

Recently broken by d9fa17aa7c34dea66ce64da6fb4c643e75ba452c.  

commit   : 47d4d0cfad6921fe1f6aabacc8a7a328ce9acb76    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Jun 2020 08:22:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 Jun 2020 08:22:52 +0200    

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

commit   : 46241b28d84551bf6aeec3aa7e2391cda2757a21    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2020 15:26:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Jun 2020 15:26:51 +0900    

Oversight in cc07264.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/1098356.1592196242@sss.pgh.pa.us  

commit   : 1575fbf1ac3c8464b2dade245deff537a3aa2498    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Jun 2020 11:33:13 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Jun 2020 11:33:13 +1200    

Our documentation failed to point out that REPEATABLE READ is really  
snapshot isolation, which might be important to some users.  Point to  
the standard reference paper for this complicated topic.  
  
Likewise, add a reference to the VLDB paper about PostgreSQL SSI, for  
technical information about our SSI implementation and how it compares  
to S2PL.  
  
While here, add a note about catalog access using a lower isolation  
level, per recent user complaint.  
  
Back-patch to all releases.  
  
Reported-by: Kyle Kingsbury <aphyr@jepsen.io>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Tatsuo Ishii <ishii@sraoss.co.jp>  
Discussion: https://postgr.es/m/db7b729d-0226-d162-a126-8a8ab2dc4443%40jepsen.io  
Discussion: https://postgr.es/m/16454-9408996bb1750faf%40postgresql.org  

commit   : decbe2bfb1051c5ab6c382b19e1d909e34227a22    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Jun 2020 11:00:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Jun 2020 11:00:07 -0400    

Previously, these functions tended to throw underflow errors for  
negative-infinity exponents.  The correct thing per POSIX is to  
return 0, so let's do that instead.  (Note that the SQL standard  
is silent on such issues, as it lacks the concepts of either Inf  
or NaN; so our practice is to follow POSIX whenever a corresponding  
C-library function exists.)  
  
Also, add a bunch of test cases verifying that exp() and power()  
actually do follow POSIX for Inf and NaN inputs.  While this patch  
should guarantee that exp() passes the tests, power() will not unless  
the platform's pow(3) is fully POSIX-compliant.  I already know that  
gaur fails some of the tests, and I am suspicious that the Windows  
animals will too; the extent of compliance of other old platforms  
remains to be seen.  We might choose to drop failing test cases, or  
to work harder at overriding pow(3) for these cases, but first let's  
see just how good or bad the situation is.  
  
Discussion: https://postgr.es/m/582552.1591917752@sss.pgh.pa.us  

commit   : 378badc8ebebc8fece7a18001f6b876cc00b12c0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 14 Jun 2020 07:48:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 14 Jun 2020 07:48:15 +0200    

The variants for time and timetz had zero test coverage, the variant  
for interval only very little.  This adds practically full coverage  
for those functions.  
  
Reviewed-by: Vik Fearing <vik@postgresfriends.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/c3306ac7-fcae-a1b8-1e30-6a379d605bcb%402ndquadrant.com  

commit   : cc072641d41c55c6aa24a331fc1f8029e0a8d799    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 14 Jun 2020 12:40:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 14 Jun 2020 12:40:37 +0900    

This patch removes the hardcoded check for superuser privileges when  
executing replication origin functions.  Instead, execution is revoked  
from public, meaning that those functions can be executed by a superuser  
and that access to them can be granted.  
  
Author: Martín Marqués  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Masahiko Sawada  
Discussion: https:/postgr.es/m/CAPdiE1xJMZOKQL3dgHMUrPqysZkgwzSMXETfKkHYnBAB7-0VRQ@mail.gmail.com  

commit   : 23cbeda50b94c817bed4f7d2127ee09c4e8c8b86    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Jun 2020 14:01:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Jun 2020 14:01:46 -0400    

var_samp(numeric) and stddev_samp(numeric) disagreed with their float  
cousins about what to do for a single non-null input value that is NaN.  
The float versions return NULL on the grounds that the calculation is  
only defined for more than one non-null input, which seems like the  
right answer.  But the numeric versions returned NaN, as a result of  
dealing with edge cases in the wrong order.  Fix that.  The patch  
also gets rid of an insignificant memory leak in such cases.  
  
This inconsistency is of long standing, but on the whole it seems best  
not to back-patch the change into stable branches; nobody's complained  
and it's such an obscure point that nobody's likely to complain.  
(Note that v13 and v12 now contain test cases that will notice if we  
accidentally back-patch this behavior change in future.)  
  
Report and patch by me; thanks to Dean Rasheed for review.  
  
Discussion: https://postgr.es/m/353062.1591898766@sss.pgh.pa.us  

commit   : 03109a53020e4663df3a8d822cdc665a7d712a93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Jun 2020 13:43:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Jun 2020 13:43:24 -0400    

When there is just one non-null input value, and it is infinity or NaN,  
aggregates such as stddev_pop and covar_pop should produce a NaN  
result, because the calculation is not well-defined.  They used to do  
so, but since we adopted Youngs-Cramer aggregation in commit e954a727f,  
they produced zero instead.  That's an oversight, so fix it.  Add tests  
exercising these edge cases.  
  
Affected aggregates are  
  
 var_pop(double precision)  
 stddev_pop(double precision)  
 var_pop(real)  
 stddev_pop(real)  
 regr_sxx(double precision,double precision)  
 regr_syy(double precision,double precision)  
 regr_sxy(double precision,double precision)  
 regr_r2(double precision,double precision)  
 regr_slope(double precision,double precision)  
 regr_intercept(double precision,double precision)  
 covar_pop(double precision,double precision)  
 corr(double precision,double precision)  
  
Back-patch to v12 where the behavior change was accidentally introduced.  
  
Report and patch by me; thanks to Dean Rasheed for review.  
  
Discussion: https://postgr.es/m/353062.1591898766@sss.pgh.pa.us  

commit   : d64f1cdf2f4bef1454c74af1028c9ea0c3280322    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 13 Jun 2020 09:33:33 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 13 Jun 2020 09:33:33 -0700    

Reported-By: Tom Lane  
Discussion: https://postgr.es/m/841649.1592065060@sss.pgh.pa.us  

commit   : 8f5b5967441f05e56446fa4cdeffd0774c01e553    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 13 Jun 2020 09:03:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 13 Jun 2020 09:03:28 +0200    

Make use of the general object support already used by COMMENT, DROP,  
and SECURITY LABEL.  
  
Discussion: https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com  

commit   : a332b366d4fa19ee3578a864993a8dc7abb47177    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 13 Jun 2020 09:03:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 13 Jun 2020 09:03:28 +0200    

Unify the grammar of COMMENT, DROP, and SECURITY LABEL further.  They  
all effectively just take an object address for later processing, so  
we can make the grammar more generalized.  Some extra checking about  
which object types are supported can be done later in the statement  
execution.  
  
Discussion: https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com  

commit   : e78900afd217fa3eaa77c51e23a94c1466af421c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jun 2020 14:04:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jun 2020 14:04:56 +0900    

Using --outputdir with a custom output repository has never created by  
default the sql/ and expected/ paths generated with contents from  
respectively input/ and output/ if they don't exist, while the base  
output directory gets created if it does not exist.  If sql/ and  
expected/ are not present, pg_regress would fail with the path missing,  
requiring test scripts to create those extra paths by themselves.  This  
commit changes pg_regress so as both get created by default if they do  
not exist, removing the need for external test scripts to do so.  
  
This cleans up two code paths in the tree for pg_upgrade tests in MSVC  
and environments able to use test.sh.  sql/ and expected/ were created  
as part of each test script, but this is not needed anymore as  
pg_regress handles the work now.  
  
Author: Roman Zharkov, Daniel Gustafsson  
Reviewed-by: Michael Paquier, Tom Lane  
Discussion: https://postgr.es/m/16484-4d89e9cc11241996@postgresql.org  

commit   : 64725728e790b76c97984b1029d9ffe90bcb2ec4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jun 2020 09:34:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jun 2020 09:34:38 +0900    

This adds two tests for --extra-float-digits and --rows-per-insert,  
similar to what exists for --compress.  
  
Author: Dong Wook Lee  
Discussion: https://postgr.es/m/CAAcByaJsgrB-qc-ALb0mALprRGLAdmcBap7SZxO4kCAU-JEHcQ@mail.gmail.com  

commit   : dad75eb4a8d5835ecc795d7a7978e7702e4d5912    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 13 Jun 2020 12:32:00 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 13 Jun 2020 12:32:00 +1200    

Core by no means makes excessive use of these functions, but quite a large  
number of those usages do require the caller to call strlen() on the  
returned string.  This is quite wasteful since these functions do already  
have a good idea of the length of the string, so we might as well just  
have them return that.  
  
Reviewed-by: Andrew Gierth  
Discussion: https://postgr.es/m/CAApHDvrm2A5x2uHYxsqriO2cUaGcFvND%2BksC9e7Tjep0t2RK_A%40mail.gmail.com  

commit   : 9a7fccd9eac85726ced3f3794a743eeab447f334    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 13 Jun 2020 11:27:25 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 13 Jun 2020 11:27:25 +1200    

In passing, also remove a few surplus empty lines from pg_ltoa and  
pg_ulltoa_n in numutils.c  
  
Reported-by: Andrew Gierth  
Discussion: https://postgr.es/m/87y2ou3xuh.fsf@news-spur.riddles.org.uk  
Backpatch-through: 13, where these changes were introduced  

commit   : 2f48ede080f42b97b594fb14102c82ca1001b80c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jun 2020 12:14:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jun 2020 12:14:32 -0400    

plpgsql has always executed the query given in a RETURN QUERY command  
by opening it as a cursor and then fetching a few rows at a time,  
which it turns around and dumps into the function's result tuplestore.  
The point of this was to keep from blowing out memory with an oversized  
SPITupleTable result (note that while a tuplestore can spill tuples  
to disk, SPITupleTable cannot).  However, it's rather inefficient, both  
because of extra data copying and because of executor entry/exit  
overhead.  In recent versions, a new performance problem has emerged:  
use of a cursor prevents use of a parallel plan for the executed query.  
  
We can improve matters by skipping use of a cursor and having the  
executor push result tuples directly into the function's result  
tuplestore.  However, a moderate amount of new infrastructure is needed  
to make that idea work:  
  
* We can use the existing tstoreReceiver.c DestReceiver code to funnel  
executor output to the tuplestore, but it has to be extended to support  
plpgsql's requirement for possibly applying a tuple conversion map.  
  
* SPI needs to be extended to allow use of a caller-supplied  
DestReceiver instead of its usual receiver that puts tuples into  
a SPITupleTable.  Two new API calls are needed to handle both the  
RETURN QUERY and RETURN QUERY EXECUTE cases.  
  
I also felt that I didn't want these new API calls to use the legacy  
method of specifying query parameter values with "char" null flags  
(the old ' '/'n' convention); rather they should accept ParamListInfo  
objects containing the parameter type and value info.  This required  
a bit of additional new infrastructure since we didn't yet have any  
parse analysis callback that would interpret $N parameter symbols  
according to type data supplied in a ParamListInfo.  There seems to be  
no harm in letting makeParamList install that callback by default,  
rather than leaving a new ParamListInfo's parserSetup hook as NULL.  
(Indeed, as of HEAD, I couldn't find anyplace that was using the  
parserSetup field at all; plpgsql was using parserSetupArg for its  
own purposes, but parserSetup seemed to be write-only.)  
  
We can actually get plpgsql out of the business of using legacy null  
flags altogether, and using ParamListInfo instead of its ad-hoc  
PreparedParamsData structure; but this requires inventing one more  
SPI API call that can replace SPI_cursor_open_with_args.  That seems  
worth doing, though.  
  
SPI_execute_with_args and SPI_cursor_open_with_args are now unused  
anywhere in the core PG distribution.  Perhaps someday we could  
deprecate/remove them.  But cleaning up the crufty bits of the SPI  
API is a task for a different patch.  
  
Per bug #16040 from Jeremy Smith.  This is unfortunately too invasive to  
consider back-patching.  Patch by me; thanks to Hamid Akhtar for review.  
  
Discussion: https://postgr.es/m/16040-eaacad11fecfb198@postgresql.org  

commit   : aaf8c990502f7bb28c10f6bab1d23fe2f9f0b537    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2020 21:05:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2020 21:05:10 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200612023709.GC14879@telsasoft.com  

commit   : ffd2582297b86f640b60ba46097b70743f920d35    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 Jun 2020 08:51:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 Jun 2020 08:51:16 +0200    

Make use of RELKIND_HAS_STORAGE() where appropriate, instead of  
listing out the relkinds individually.  No behavior change intended.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/7a22bf51-2480-d999-1794-191ba67ff47c%402ndquadrant.com  

commit   : 7aa4fb592530b74bf05f62c52b736ee3910691b9    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 12 Jun 2020 10:44:32 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 12 Jun 2020 10:44:32 +1200    

Rewrite the documentation of these functions, in light of recent bug fix  
commit 5940ffb2.  
  
Back-patch to 13 where the check-for-conflict-out code was split up into  
AM-specific and generic parts, and new documentation was added that now  
looked wrong.  
  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/db7b729d-0226-d162-a126-8a8ab2dc4443%40jepsen.io  

commit   : 59fa7eb60364b8e71fe0f515d6ad87c274af839b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:44:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:44:49 -0400    

Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/8315c0ca-7758-8823-fcb6-f37f9413e6b6@2ndquadrant.com  
  
Backpatch-through: master  

commit   : 0dd1eb3aea636c0b28a18e1290ef108629e5eddd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:19:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:19:25 -0400    

xreflabels prevent references to the chapter numbers of sections id's.  
It should only be used in specific cases.  
  
Discussion: https://postgr.es/m/8315c0ca-7758-8823-fcb6-f37f9413e6b6@2ndquadrant.com  
  
Backpatch-through: 9.5  

commit   : 77a3be32f7c16538bc4e05edad85560d9f88369b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Jun 2020 17:38:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Jun 2020 17:38:42 -0400    

When merging two NumericAggStates, the code missed adding the new  
state's NaNcount unless its N was also nonzero; since those counts  
are independent, this is wrong.  
  
This would only have visible effect if some partial aggregate scans  
found only NaNs while earlier ones found only non-NaNs; then we could  
end up falsely deciding that there were no NaNs and fail to return a  
NaN final result as expected.  That's pretty improbable, so it's no  
surprise this hasn't been reported from the field.  Still, it's a bug.  
  
I didn't try to produce a regression test that would show the bug,  
but I did notice that these functions weren't being reached at all  
in our regression tests, so I improved the tests to at least  
exercise them.  With these additions, I see pretty complete code  
coverage on the aggregation-related functions in numeric.c.  
  
Back-patch to 9.6 where this code was introduced.  (I only added  
the improved test case as far back as v10, though, since the  
relevant part of aggregates.sql isn't there at all in 9.6.)  

commit   : 92c58fd94801dd5c81ee20e26c5bb71ad64552a8    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 11 Jun 2020 11:58:16 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 11 Jun 2020 11:58:16 -0700    

Eliminate enable_groupingsets_hash_disk, which was primarily useful  
for testing grouping sets that use HashAgg and spill. Instead, hack  
the table stats to convince the planner to choose hashed aggregation  
for grouping sets that will spill to disk. Suggested by Melanie  
Plageman.  
  
Rename enable_hashagg_disk to hashagg_avoid_disk_plan, and invert the  
meaning of on/off. The new name indicates more strongly that it only  
affects the planner. Also, the word "avoid" is less definite, which  
should avoid surprises when HashAgg still needs to use the  
disk. Change suggested by Justin Pryzby, though I chose a different  
GUC name.  
  
Discussion: https://postgr.es/m/CAAKRu_aisiENMsPM2gC4oUY1hHG3yrCwY-fXUg22C6_MJUwQdA%40mail.gmail.com  
Discussion: https://postgr.es/m/20200610021544.GA14879@telsasoft.com  
Backpatch-through: 13  

commit   : 5940ffb221316ab73e6fdc780dfe9a07d4221ebb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 11 Jun 2020 10:09:47 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 11 Jun 2020 10:09:47 -0700    

SSI's HeapCheckForSerializableConflictOut() test failed to correctly  
handle conditions involving a concurrently inserted tuple which is later  
concurrently updated by a separate transaction .  A SELECT statement  
that called HeapCheckForSerializableConflictOut() could end up using the  
same XID (updater's XID) for both the original tuple, and the successor  
tuple, missing the XID of the xact that created the original tuple  
entirely.  This only happened when neither tuple from the chain was  
visible to the transaction's MVCC snapshot.  
  
The observable symptoms of this bug were subtle.  A pair of transactions  
could commit, with the later transaction failing to observe the effects  
of the earlier transaction (because of the confusion created by the  
update to the non-visible row).  This bug dates all the way back to  
commit dafaa3ef, which added SSI.  
  
To fix, make sure that we check the xmin of concurrently inserted tuples  
that happen to also have been updated concurrently.  
  
Author: Peter Geoghegan  
Reported-By: Kyle Kingsbury  
Reviewed-By: Thomas Munro  
Discussion: https://postgr.es/m/db7b729d-0226-d162-a126-8a8ab2dc4443@jepsen.io  
Backpatch: All supported versions  

commit   : d9fa17aa7c34dea66ce64da6fb4c643e75ba452c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 14:14:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 14:14:12 +0200    

Remove some code relevant only for dumping from pre-7.1 servers,  
support for which had already been removed by  
64f3524e2c8deebc02808aa5ebdfa17859473add.  

commit   : ad9291f5e6f81ebca978c4438a1c7a448ca5b9ad    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 11 Jun 2020 14:10:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 11 Jun 2020 14:10:43 +0530    

Reported-by: John Naylor  
Author: John Naylor  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CACPNZCtRuvs6G+EYqejhVJgBq2AKeZdXRVJsbX4syhO9gn5SNQ@mail.gmail.com  

commit   : 3fbd4bb6f494dd70cc5075536a754261853de167    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 11:18:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 11:18:15 +0200    

Fold it into the generic DropStmt.  
  
Discussion: https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com  

commit   : 5333e014ab943b201fe71cfaf409419c204f36be    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 10:26:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 10:26:12 +0200    

Remove the option to specify the language name as a single-quoted  
string.  This has been obsolete since ee8ed85da3b.  Removing it allows  
better grammar refactoring.  
  
The syntax of the CREATE FUNCTION LANGUAGE clause is not changed.  
  
Discussion: https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com  

commit   : a3b2bf1fe7ce7cf88af6af2c100c6ed61c976780    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2020 15:48:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2020 15:48:46 +0900    

fe_archive.c was compiled only for the frontend in src/common/, but as  
it will never share anything with the backend, it makes most sense to  
move this file to src/fe_utils/.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/e9766d71-8655-ac86-bdf6-77e0e7169977@2ndquadrant.com  
Backpatch-through: 13  

commit   : c4325cefba512772efc108baf8ef7182c3833716    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 08:21:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 11 Jun 2020 08:21:24 +0200    

All other relation types are handled by AlterTableStmt, so it's  
unnecessary to make a different statement for foreign tables.  
  
Discussion: https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com  

commit   : c2bd1fec32ab5407a3675272af1a06f425cb5161    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Jun 2020 22:58:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Jun 2020 22:58:46 +0200    

access_method, database_name, and index_name are all just name, and  
they are not used consistently for their alleged purpose, so remove  
them.  They have been around since ancient times but have no current  
reason for existing.  Removing them can simplify future grammar  
refactoring.  
  
Discussion: https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com  

commit   : c7eab0e97e6cf1d0c136c22269c10ae11ba874c4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Jun 2020 16:16:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Jun 2020 16:16:37 +0200    

Also, the legacy values on/true/yes/1 for password_encryption that  
mapped to md5 are removed.  The only valid values are now  
scram-sha-256 and md5.  
  
Reviewed-by: Jonathan S. Katz <jkatz@postgresql.org>  
Discussion: https://www.postgresql.org/message-id/flat/d5b0ad33-7d94-bdd1-caac-43a1c782cab2%402ndquadrant.com  

commit   : 5a4ada71a8f944600c348a6e4f5feb388ba8bd37    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Jun 2020 11:57:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 Jun 2020 11:57:41 +0200    

The previous description string still described the pre-PostgreSQL  
10 (pre eb61136dc75a76caef8460fa939244d8593100f2) behavior of  
selecting between encrypted and unencrypted, but it is now choosing  
between encryption algorithms.  

commit   : c5c000b1038e3037289806f7f29c203f05a2b1e3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Jun 2020 10:20:10 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Jun 2020 10:20:10 +0530    

Commit cec2edfa78 introduced logical_decoding_work_mem to limit  
ReorderBuffer memory usage. We spill the changes once the memory occupied  
by changes exceeds logical_decoding_work_mem.  There was an assumption  
in the code that by evicting the largest (sub)transaction we will come  
under the memory limit as the selected transaction will be at least as  
large as the most recent change (which caused us to go over the memory  
limit).  However, that is not true because a user can reduce the  
logical_decoding_work_mem to a smaller value before the most recent  
change.  
  
We fix it by allowing to evict the transactions until we reach under the  
memory limit.  
  
Reported-by: Fujii Masao  
Author: Amit Kapila  
Reviewed-by: Fujii Masao  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/2b7ba291-22e0-a187-d167-9e5309a3458d@oss.nttdata.com  

commit   : 350f47786c3444d822d6d27829dd6a5426487150    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jun 2020 10:41:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jun 2020 10:41:41 +0200    

similar to 0fd2a79a637f9f96b9830524823df0454e962f96  

commit   : b1d32d3e3230f00b5baba08f75b4f665c7d6dac6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jun 2020 09:10:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jun 2020 09:10:14 +0200    

There are a number of Remove${Something}ById() functions that are  
essentially identical in structure and only different in which catalog  
they are working on.  Refactor this to be one generic function.  The  
information about which oid column, index, etc. to use was already  
available in ObjectProperty for most catalogs, in a few cases it was  
easily added.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/331d9661-1743-857f-1cbb-d5728bcd62cb%402ndquadrant.com  

commit   : b27c90bbe4a3d607f8fc6703c7183e56e4039acd    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 9 Jun 2020 18:43:15 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 9 Jun 2020 18:43:15 +1200    

These appear to have been forgotten when the functions were renamed in  
1fd687a03.  
  
Backpatch-through: 13, where the functions were renamed  

commit   : 05dea2427c2f6ba83f0b11f4e9472db2032dc1c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2020 01:17:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2020 01:17:59 -0400    

Commit 0c882e52a tried to force table atest12 to have more-accurate-  
than-default statistics; but transiently setting default_statistics_target  
isn't enough for that, because autovacuum could come along and overwrite  
the stats later.  This evidently explains some intermittent buildfarm  
failures we've seen since then.  Repair by disabling autovac on this table.  
  
Thanks to David Rowley for correctly diagnosing the cause.  
  
Discussion: https://postgr.es/m/CA+hUKG+OUkQSOUTg=qo=S=fWa_tbm99i7rB7mfbHz1SYm4v-jQ@mail.gmail.com  

commit   : 1b2c29469a58cd9086bd86e20c708eb437564a80    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2020 20:59:45 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2020 20:59:45 -0700    

Diagnosis by Andres.  
  
Reported-by: Pavel Stehule  
Discussion: https://postgr.es/m/CAFj8pRDLVakD5Aagt3yZeEQeTeEWaS3YE5h8XC3Q3qJ6TYkc2Q%40mail.gmail.com  
Backpatch-through: 13  

commit   : 47c718792b885c2a06e32cf86f4caca69ce5cda4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 19:52:19 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2020 19:52:19 -0700    

Previously we used pg_atomic_write_64_impl inside  
pg_atomic_init_u64. That works correctly, but on platforms without  
64bit single copy atomicity it could trigger spurious valgrind errors  
about uninitialized memory, because we use compare_and_swap for atomic  
writes on such platforms.  
  
I previously suppressed one instance of this problem (6c878edc1df),  
but as Tom reports that wasn't enough. As the atomic variable cannot  
yet be concurrently accessible during initialization, it seems better  
to have pg_atomic_init_64_impl set the value directly.  
  
Change pg_atomic_init_u32_impl for symmetry.  
  
Reported-By: Tom Lane  
Author: Andres Freund  
Discussion: https://postgr.es/m/1714601.1591503815@sss.pgh.pa.us  
Backpatch: 9.5-  

commit   : c2e71cb355a43d3ea0eaa6433d07f3681f934d54    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2020 22:44:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2020 22:44:15 +0200    

Discussion: https://www.postgresql.org/message-id/flat/a8eeabd6-2be1-43fe-401e-a97594c38478%402ndquadrant.com  

commit   : cbcc8726bb1c3075e58b9907547104271ff5899b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2020 07:58:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2020 07:58:51 +0200    

Update to snowball tag v2.0.0.  Major changes are new stemmers for  
Basque, Catalan, and Hindi.  
  
Discussion: https://www.postgresql.org/message-id/flat/a8eeabd6-2be1-43fe-401e-a97594c38478%402ndquadrant.com  

commit   : 57cb8063089a7d6c54e27adfd5d028cc01f21536    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 8 Jun 2020 13:57:24 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 8 Jun 2020 13:57:24 +1200    

The redo routines for XLOG_CHECKPOINT_{ONLINE,SHUTDOWN} must acquire  
ControlFileLock before modifying ControlFile->checkPointCopy, or the  
checkpointer could write out a control file with a bad checksum.  
  
Likewise, XLogReportParameters() must acquire ControlFileLock before  
modifying ControlFile and calling UpdateControlFile().  
  
Back-patch to all supported releases.  
  
Author: Nathan Bossart <bossartn@amazon.com>  
Author: Fujii Masao <masao.fujii@oss.nttdata.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/70BF24D6-DC51-443F-B55A-95735803842A%40amazon.com  

commit   : d094bf93014b467cc3c129cc0d7d3f0f69968c96    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 8 Jun 2020 13:20:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 8 Jun 2020 13:20:46 +1200    

In PostgreSQL 10, we stopped using System V semaphores on Linux  
systems.  Update the example we give of an error message from a  
misconfigured system to show what people are most likely to see these  
days.  
  
Back-patch to 10, where PREFERRED_SEMAPHORES=UNNAMED_POSIX arrived.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com  

commit   : 879ad9f90e83b94db14b8be11f1cc1fb38187cc0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2020 10:12:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2020 10:12:24 +0900    

Since database connections can be used with WAL senders in 9.4, it is  
possible to use physical replication.  This commit fixes a crash when  
starting physical replication with a WAL sender using a database  
connection, caused by the refactoring done in 850196b.  
  
There have been discussions about forbidding the use of physical  
replication in a database connection, but this is left for later,  
taking care only of the crash new to 13.  
  
While on it, add a test to check for a failure when attempting logical  
replication if the WAL sender does not have a database connection.  This  
part is extracted from a larger patch by Kyotaro Horiguchi.  
  
Reported-by: Vladimir Sitnikov  
Author: Michael Paquier, Kyotaro Horiguchi  
Reviewed-by: Kyotaro Horiguchi, Álvaro Herrera  
Discussion: https://postgr.es/m/CAB=Je-GOWMj1PTPkeUhjqQp-4W3=nW-pXe2Hjax6rJFffB5_Aw@mail.gmail.com  
Backpatch-through: 13  

commit   : 5a2398b0b2d30315469ee00ca289ea88b03ccfd8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 7 Jun 2020 16:27:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 7 Jun 2020 16:27:13 -0700    

Commit 7be5d8df1f74b78620167d3abf32ee607e728919 surfaced the logic  
error, which had no functional implications, by adding "use warnings".  
The buildfarm always customizes PROVE_FLAGS, so the warning did not  
appear there.  Back-patch to 9.5 (all supported versions).  

commit   : d10b19e224c2ead10b59382f695f0c2bd65039fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 17:16:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 17:16:30 -0400    

Let the hacking begin ...  

commit   : b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 16:57:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 16:57:08 -0400    

pgperltidy and reformat-dat-files too, though those didn't  
find anything to change.  

commit   : 7247e243a803044a79a2828ced51b05765e049a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 13:44:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 13:44:13 -0400    

Even when we've concluded that we have a hard write failure on the  
socket, we should continue to try to read data.  This gives us an  
opportunity to collect any final error message that the backend might  
have sent before closing the connection; moreover it is the job of  
pqReadData not pqSendSome to close the socket once EOF is detected.  
  
Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect  
data in the case where we'd already set write_failed.  The problem was  
masked for ordinary query operations (which really only make one write  
attempt anyway), but COPY to the server would continue to send data  
indefinitely after a mid-COPY connection loss.  
  
Hence, add pqReadData calls into the paths where pqSendSome drops data  
because of write_failed.  If we've lost the connection, this will  
eventually result in closing the socket and setting CONNECTION_BAD,  
which will cause PQputline and siblings to report failure, allowing  
the application to terminate the COPY sooner.  (Basically this restores  
what happened before 1f39a1c06.)  
  
There are related issues that this does not solve; for example, if the  
backend sends an error but doesn't drop the connection, we did and  
still will keep pumping COPY data as long as the application sends it.  
Fixing that will require application-visible behavior changes though,  
and anyway it's an ancient behavior that we've had few complaints about.  
For now I'm just trying to fix the regression from 1f39a1c06.  
  
Per a complaint from Andres Freund.  Back-patch into v12 where  
1f39a1c06 came in.  
  
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de  

commit   : 92f33bb7afd373ed562e23077c14831944d1b0d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 13:07:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2020 13:07:31 -0400    

As it stands, this flag is only set when we've successfully sent a  
cancel request, not if we get SIGINT and then fail to send a cancel.  
However, for almost all callers, that's the Wrong Thing: we'd prefer  
to abort processing after control-C even if no cancel could be sent.  
  
As an example, since commit 1d468b9ad "pgbench -i" fails to give up  
sending COPY data even after control-C, if the postmaster has been  
stopped, which is clearly not what the code intends and not what anyone  
would want.  (The fact that it keeps going at all is the fault of a  
separate bug in libpq, but not letting CancelRequested become set is  
clearly not what we want here.)  
  
The sole exception, as far as I can find, is that scripts_parallel.c's  
ParallelSlotsGetIdle tries to consume a query result after issuing a  
cancel, which of course might not terminate quickly if no cancel  
happened.  But that behavior was poorly thought out too.  No user of  
ParallelSlotsGetIdle tries to continue processing after a cancel,  
so there is really no point in trying to clear the connection's state.  
Moreover this has the same defect as for other users of cancel.c,  
that if the cancel request fails for some reason then we end up with  
control-C being completely ignored.  (On top of that, select_loop failed  
to distinguish clearly between SIGINT and other reasons for select(2)  
failing, which means that it's possible that the existing code would  
think that a cancel has been sent when it hasn't.)  
  
Hence, redefine CancelRequested as simply meaning that SIGINT was  
received.  We could add a second flag with the other meaning, but  
in the absence of any compelling argument why such a flag is needed,  
I think it would just offer an opportunity for future callers to  
get it wrong.  Also remove the consumeQueryResult call in  
ParallelSlotsGetIdle's failure exit.  In passing, simplify the  
API of select_loop.  
  
It would now be possible to re-unify psql's cancel_pressed with  
CancelRequested, partly undoing 5d43c3c54.  But I'm not really  
convinced that that's worth the trouble, so I left psql alone,  
other than fixing a misleading comment.  
  
This code is new in v13 (cf a4fd3aa71), so no need for back-patch.  
  
Per investigation of a complaint from Andres Freund.  
  
Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de  

commit   : 1fbb6c93df30801f83c6804ab7befde3cdefe677    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 7 Jun 2020 09:14:24 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 7 Jun 2020 09:14:24 -0700    

Commit 24d85952 made a change that indirectly caused a performance  
regression by triggering a change in the way GCC optimizes memcpy() on  
some platforms.  
  
The behavior seemed to contradict a GCC document, so I filed a report:  
  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556  
  
This patch implements a narrow workaround which eliminates the  
regression I observed. The workaround is benign enough that it seems  
unlikely to cause a different regression on another platform.  
  
Discussion: https://postgr.es/m/99b2eab335c1592c925d8143979c8e9e81e1575f.camel@j-davis.com  

commit   : aa7927698acb813283d21aa6a47a67cd3c5a8b0c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 16:12:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 16:12:05 +0200    

commit   : 1e8ada0c8a448891971faf71f48125439ee07023    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 15:11:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 15:11:51 +0200    

Two parts of the same message shouldn't be split across two function  
calls.  

commit   : 0fd2a79a637f9f96b9830524823df0454e962f96    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 15:06:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 15:06:51 +0200    

commit   : a02b8bdd9878ae1d1ead87aabb673d60432500ea    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 14:54:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 14:54:28 +0200    

Whitespace between tags is significant, and in some cases it creates  
extra vertical space in man pages.  The fix is either to remove some  
newlines or in some cases to reword slightly to avoid the awkward  
markup layout.  

commit   : f4c88ce1a20e8e944d74cb964926781d6ca4cb18    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 14:35:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 14:35:12 +0200    

commit   : b25da866152347109943f998b66b1a320a9de3e0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 14:07:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 14:07:33 +0200    

commit   : 9ac0a26210901a5869fd7ea83ab1c59489c1aeef    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:34:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:34:37 +0200    

commit   : 4c6f70cd33ac395dea1acca7dabf4cb8556235e7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:27:57 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:27:57 +0200    

commit   : b79cb8a919c2614c81ae7578b863b7f582a9baf2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:24:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:24:40 +0200    

commit   : b3c2412e70f2be25ac70f7e9b2f12dbe4efd2a8b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:18:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:18:36 +0200    

commit   : ab5b55505ec4bf08a9f93810e1bfada93bc63bb5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:10:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 13:10:18 +0200    

This creates unnecessary rendering problem risks, and it's  
inconsistent and gets copied around.  

commit   : c8be915aa9fcc4c0cba563ddbb2e5af7a2dadd12    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 7 Jun 2020 21:36:43 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 7 Jun 2020 21:36:43 +1200    

Remove obsolete instructions for old operating system versions, and  
update the text to reflect the defaults on modern systems.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Reviewed-by: Magnus Hagander <magnus@hagander.net>  
Discussion: https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com  

commit   : c14a98032b17d514a195e4e76073ebc98a6521be    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 11:16:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 7 Jun 2020 11:16:51 +0200    

commit   : 35b527428d6110dd0de585223a4783fe996a0020    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jun 2020 19:56:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jun 2020 19:56:21 +0200    

commit   : 6e2f11b631b712d691aecdbbcaa7a75b391c1e98    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 6 Jun 2020 15:35:42 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 6 Jun 2020 15:35:42 +0200    

The estimate of total backup size effects the view  
pg_stat_progress_basebackup, not pg_stat_progress_analyze.  

commit   : 26056b3ba84d6cb51eea5d6c83fefae19919a56b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 5 Jun 2020 20:10:53 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 5 Jun 2020 20:10:53 -0700    

Back-patch to 9.5, where commit 4f700bcd20c087f60346cb8aefd0e269be8e2157  
first appeared.  
  
Reviewed by Tom Lane.  Reported by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/4dfabec2-a3ad-0546-2d62-f816c97edd0c@2ndQuadrant.com  

commit   : ec5d6fc4ae8c75391d99993cd030a8733733747d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2020 18:04:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2020 18:04:37 -0400    

I thought this added clarity, or at least was consistent with the way  
these entries looked before v13 ... but apparently I'm in the minority.  
  
Discussion: https://postgr.es/m/CAFj8pRAXuetiHUfs73zjsJD6B78FWcUsBS-j23sdCMFXkgx5Fg@mail.gmail.com  

commit   : 0c882e52a8660114234a0c4a29db919bb727e552    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2020 16:55:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2020 16:55:16 -0400    

ineq_histogram_selectivity() can be invoked in situations where the  
ordering we care about is not that of the column's histogram.  We could  
be considering some other collation, or even more drastically, the  
query operator might not agree at all with what was used to construct  
the histogram.  (We'll get here for anything using scalarineqsel-based  
estimators, so that's quite likely to happen for extension operators.)  
  
Up to now we just ignored this issue and assumed we were dealing with  
an operator/collation whose sort order exactly matches the histogram,  
possibly resulting in junk estimates if the binary search gets confused.  
It's past time to improve that, since the use of nondefault collations  
is increasing.  What we can do is verify that the given operator and  
collation match what's recorded in pg_statistic, and use the existing  
code only if so.  When they don't match, instead execute the operator  
against each histogram entry, and take the fraction of successes as our  
selectivity estimate.  This gives an estimate that is probably good to  
about 1/histogram_size, with no assumptions about ordering.  (The quality  
of the estimate is likely to degrade near the ends of the value range,  
since the two orderings probably don't agree on what is an extremal value;  
but this is surely going to be more reliable than what we did before.)  
  
At some point we might further improve matters by storing more than one  
histogram calculated according to different orderings.  But this code  
would still be good fallback logic when no matches exist, so that is  
not an argument for not doing this.  
  
While here, also improve get_variable_range() to deal more honestly  
with non-default collations.  
  
This isn't back-patchable, because it requires adding another argument  
to ineq_histogram_selectivity, and because it might have significant  
impact on the estimation results for extension operators relying on  
scalarineqsel --- mostly for the better, one hopes, but in any case  
destabilizing plan choices in back branches is best avoided.  
  
Per investigation of a report from James Lucas.  
  
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com  

commit   : 87fb04af1e705b615ac01feba958f841ea4a71a6    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Fri, 5 Jun 2020 16:49:25 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Fri, 5 Jun 2020 16:49:25 -0400    

Add the unlikely() branch hint macro to CHECK_FOR_INTERRUPTS().  
Backpatch to REL_10_STABLE where we first started using unlikely().  
  
Discussion: https://www.postgresql.org/message-id/flat/8692553c-7fe8-17d9-cbc1-7cddb758f4c6%40joeconway.com  

commit   : 044c99bc567ac5d44dff0af7aebb81737dc36a69    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2020 16:18:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2020 16:18:50 -0400    

Commit 5e0928005 changed the planner so that, instead of blindly using  
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,  
it would use the collation of the column whose statistics we're  
considering.  This was recognized as still being not quite the right  
thing, but it seemed like a good incremental improvement.  However,  
shortly thereafter we introduced nondeterministic collations, and that  
creates cases where operators can fail if they're passed the wrong  
collation.  We don't want planning to fail in cases where the query itself  
would work, so this means that we *must* use the query's collation when  
invoking operators for estimation purposes.  
  
The only real problem this creates is in ineq_histogram_selectivity, where  
the binary search might produce a garbage answer if we perform comparisons  
using a different collation than the column's histogram is ordered with.  
However, when the query's collation is significantly different from the  
column's default collation, the estimate we previously generated would be  
pretty irrelevant anyway; so it's not clear that this will result in  
noticeably worse estimates in practice.  (A follow-on patch will improve  
this situation in HEAD, but it seems too invasive for back-patch.)  
  
The patch requires changing the signatures of mcv_selectivity and allied  
functions, which are exported and very possibly are used by extensions.  
In HEAD, I just did that, but an API/ABI break of this sort isn't  
acceptable in stable branches.  Therefore, in v12 the patch introduces  
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes  
the old functions into wrappers that assume DEFAULT_COLLATION_OID should  
be used.  That does not match the prior behavior, but it should avoid risk  
of failure in most cases.  (In practice, I think most extension datatypes  
aren't collation-aware, so the change probably doesn't matter to them.)  
  
Per report from James Lucas.  Back-patch to v12 where the problem was  
introduced.  
  
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com  

commit   : f0d2c65f17cab8cfaf4d39f7f8e2254824cd4092    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jun 2020 11:18:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jun 2020 11:18:11 +0200    

DES has been deprecated in OpenSSL 3.0.0 which makes loading keys  
encrypted with DES fail with "fetch failed".  Solve by changing the  
cipher used to aes256 which has been supported since 1.0.1 (and is  
more realistic to use anyways).  
  
Note that the minimum supported OpenSSL version is 1.0.1 as of  
7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, so this does not introduce  
any new version requirements.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se  

commit   : 1127f0e392c757fc4fbbeffd7d0202bb02670e9c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2020 10:26:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2020 10:26:02 +0900    

If the flag value is lost, logical decoding would work the same way as  
REPLICA IDENTITY NOTHING, meaning that no old tuple values would be  
included in the changes anymore produced by logical decoding.  
  
Author: Michael Paquier  
Reviewed-by: Euler Taveira  
Discussion: https://postgr.es/m/20200603065340.GK89559@paquier.xyz  
Backpatch-through: 12  

commit   : a9632830bb05dc98ae24017cafc652e4a66d44a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2020 16:42:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2020 16:42:08 -0400    

It's intentional that we don't allow values greater than 24 hours,  
while we do allow "24:00:00" as well as "23:59:60" as inputs.  
However, the range check was miscoded in such a way that it would  
accept "23:59:60.nnn" with a nonzero fraction.  For time or timetz,  
the stored result would then be greater than "24:00:00" which would  
fail dump/reload, not to mention possibly confusing other operations.  
  
Fix by explicitly calculating the result and making sure it does not  
exceed 24 hours.  (This calculation is redundant with what will happen  
later in tm2time or tm2timetz.  Maybe someday somebody will find that  
annoying enough to justify refactoring to avoid the duplication; but  
that seems too invasive for a back-patched bug fix, and the cost is  
probably unmeasurable anyway.)  
  
Note that this change also rejects such input as the time portion  
of a timestamp(tz) value.  
  
Back-patch to v10.  The bug is far older, but to change this pre-v10  
we'd need to ensure that the logic behaves sanely with float timestamps,  
which is possibly nontrivial due to roundoff considerations.  
Doesn't really seem worth troubling with.  
  
Per report from Christoph Berg.  
  
Discussion: https://postgr.es/m/20200520125807.GB296739@msg.df7cb.de  

commit   : f5067049cde38cd0d6333a5e3bf1bed8d99e6f44    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2020 22:09:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2020 22:09:41 +0200    

The preferred terminology has been support "function", not procedure,  
for some time, so change that over.  The command stays \dAp, since  
\dAf is already something else.  

commit   : 3fa44a30049826bfe2fd58eec0e8acabd5757411    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jun 2020 13:02:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jun 2020 13:02:59 +0900    

Since 573bd08, hardcoded DH parameters have been moved to a different  
file, making the comment on top of load_dh_buffer() incorrect.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/D9492CCB-9A91-4181-A847-1779630BE2A7@yesql.se  

commit   : c1669fd5812a02daac58778e2708ede11edd36a3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jun 2020 10:17:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jun 2020 10:17:49 +0900    

This broke the project rule to not call any complex code while a  
spinlock is held.  Issue introduced by b89e151.  
  
Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com  
Backpatch-through: 9.5  

commit   : f88bd3139f3e2a557c086215c6b15d7f66bee845    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jun 2020 12:36:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jun 2020 12:36:00 -0400    

Fix some more violations of the "only straight-line code inside a  
spinlock" rule.  These are hazardous not only because they risk  
holding the lock for an excessively long time, but because it's  
possible for palloc to throw elog(ERROR), leaving a stuck spinlock  
behind.  
  
copy_replication_slot() had two separate places that did pallocs  
while holding a spinlock.  We can make the code simpler and safer  
by copying the whole ReplicationSlot struct into a local variable  
while holding the spinlock, and then referencing that copy.  
(While that's arguably more cycles than we really need to spend  
holding the lock, the struct isn't all that big, and this way seems  
far more maintainable than copying fields piecemeal.  Anyway this  
is surely much cheaper than a palloc.)  That bug goes back to v12.  
  
InvalidateObsoleteReplicationSlots() not only did a palloc while  
holding a spinlock, but for extra sloppiness then leaked the memory  
--- probably for the lifetime of the checkpointer process, though  
I didn't try to verify that.  Fortunately that silliness is new  
in HEAD.  
  
pg_get_replication_slots() had a cosmetic violation of the rule,  
in that it only assumed it's safe to call namecpy() while holding  
a spinlock.  Still, that's a hazard waiting to bite somebody, and  
there were some other cosmetic coding-rule violations in the same  
function, so clean it up.  I back-patched this as far as v10; the  
code exists before that but it looks different, and this didn't  
seem important enough to adapt the patch further back.  
  
Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com  

commit   : 4d685f6d7b65fa1ca5afb5138e610cd08a3c1e12    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Jun 2020 22:11:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Jun 2020 22:11:47 -0400    

Use "guc-enable-groupingsets-hash-disk".  
  
Reported-by: TAKATSUKA Haruka  
  
Discussion: https://postgr.es/m/16468-7939d39f1786516c@postgresql.org  
  
Backpatch-through: master  

commit   : 43e592c706f8ce073d166f541687ad8f02dc22c0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2020 09:59:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2020 09:59:43 +0900    

The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c,  
but previously their documents were located in  
"Replication"/"Sending Servers" section. This commit moves them to  
the proper section "Write Ahead Log"/"Settings".  
  
Back-patch to v12 where wal_init_zero and wal_recycle parameters  
were introduced.  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/b5190ab4-a169-6a42-0e49-aed0807c8976@oss.nttdata.com  

commit   : caa3c4242cf86322e2ed0c86199e6462a2c41565    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 2 Jun 2020 19:18:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 2 Jun 2020 19:18:13 +0900    

Previously UpdateSpillStats() called elog(DEBUG2) while holding  
the spinlock even though the local variables that the elog() accesses  
don't need to be protected by the lock. Since spinlocks are intended  
for very short-term locks, they should not be used when calling  
elog(DEBUG2). So this commit moves that elog() out of spinlock period.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Amit Kapila and Fujii Masao  
Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com  

commit   : e641b2a995abfa0dd7039863e2597feb3abf2b1e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 2 Jun 2020 11:11:25 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 2 Jun 2020 11:11:25 +0530    

Reported-by: Sawada Masahiko  
Author: Sawada Masahiko, Amit Kapila  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CA+fd4k4vNg7dRO5ECHdtQXXf1=Q4M98pfLW0dU7BKD8h79pkqA@mail.gmail.com  

commit   : b846091fd0a7a747933232016f0a52aa764398b8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 1 Jun 2020 17:32:32 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 1 Jun 2020 17:32:32 -0400    

The recipe was previously given in comments in the module's test  
script, but now we have an explicit recipe in the Makefile. The now  
redundant comments in the script are removed.  
  
This recipe shouldn't be needed in normal use, as the certificate and  
key are in git and don't need to be regenerated.  
  
Discussion: https://postgr.es/m/ae8f21fc-95cb-c98a-f241-1936133f466f@2ndQuadrant.com  

commit   : 42181b1015b18e877e65be66ac5a2e90b731ac8b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jun 2020 21:18:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jun 2020 21:18:36 +0200    

commit   : ce1c5b9ae87b6153d3f40a4f7806f2effef12363    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jun 2020 14:41:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jun 2020 14:41:18 +0900    

This issue has been present since the introduction of this code as of  
a3519a2 from 2002, and has been found by buildfarm member prion that  
uses RELCACHE_FORCE_RELEASE via the tests introduced recently in  
e786be5.  
  
Discussion: https://postgr.es/m/20200601022055.GB4121@paquier.xyz  
Backpatch-through: 9.5  

commit   : e786be5fcb257a09b05bd8e509c8d1b82e626352    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jun 2020 10:32:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jun 2020 10:32:06 +0900    

A relation that has no storage initializes rd_tableam to NULL, which  
caused those two functions to crash because of a pointer dereference.  
Note that in 11 and older versions, this has always failed with a  
confusing error "could not open file".  
  
These two functions are used by the Postgres ODBC driver, which requires  
them only when connecting to a backend strictly older than 8.1.  When  
connected to 8.2 or a newer version, the driver uses a RETURNING clause  
instead whose support has been added in 8.2, so it should be possible to  
just remove both functions in the future.  This is left as an issue to  
address later.  
  
While on it, add more regression tests for those functions as we never  
really had coverage for them, and for aggregates of TIDs.  
  
Reported-by: Jaime Casanova, via sqlsmith  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/CAJGNTeO93u-5APMga6WH41eTZ3Uee9f3s8dCpA-GSSqNs1b=Ug@mail.gmail.com  
Backpatch-through: 12  

commit   : af4ea507c3d9217579a8d75fc17f4796a9bab0bb    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2020 18:33:00 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2020 18:33:00 -0400    

Also add a top-level install-tests target.  
  
Backpatch to all live branches.  
  
Craig Ringer, tweaked by me.  

commit   : 4cad2534da6d17067d98cf04be2dfc1bda8f2cd0    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 31 May 2020 14:43:13 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 31 May 2020 14:43:13 +0200    

Commit 1f39bce021 added disk-based hash aggregation, which may spill  
incoming tuples to disk. It however did not request projection to make  
the tuples as narrow as possible, which may mean having to spill much  
more data than necessary (increasing I/O, pushing other stuff from page  
cache, etc.).  
  
This adds CP_SMALL_TLIST in places that may use hash aggregation - we do  
that only for AGG_HASHED. It's unnecessary for AGG_SORTED, because that  
either uses explicit Sort (which already does projection) or pre-sorted  
input (which does not need spilling to disk).  
  
Author: Tomas Vondra  
Reviewed-by: Jeff Davis  
Discussion: https://postgr.es/m/20200519151202.u2p2gpiawoaznsv2%40development  

commit   : 9b60c4b979bce060495e2b05ba01d1cc6bffdd2d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 31 May 2020 10:48:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 31 May 2020 10:48:21 +0900    

The documentation of REINDEX includes a complete description of  
CONCURRENTLY and its advantages as well as its disadvantages, but  
reindexdb was not really clear about all that.  
  
From discussion with Tom Lane, based on a report from Andrey Klychkov.  
  
Discussion: https://postgr.es/m/1590486572.205117372@f500.i.mail.ru  
Backpatch-through: 12  

commit   : 92f9468657f0916ce8589e13d5ebda60c7973c31    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 29 May 2020 17:14:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 29 May 2020 17:14:33 +0900    

This commit updates the "Viewing Statistics" section more like  
the existing catalogs chapter.  
  
- Change its layout so that an introductory paragrap is put above  
   the table for each statistics view. Previously the explanations  
   were below the tables.  
  
- Separate each view to different section and add index terms for them.  
  
Author: Fujii Masao  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com  

commit   : 6a4a335b841520739b7b2f0e608acdf3b814daad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2020 15:08:12 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2020 15:08:12 -0700    

LLVM has removed this header, in the branch that will become llvm  
11. But as it turns out we didn't actually need it, so just remove it.  
  
Author: Jesse Zhang <sbjesse@gmail.com>  
Discussion: https://postgr.es/m/CAGf+fX7bvtP0YXMu7pOsu_NwhxW6dArTkxb=jt7M2-UJkyJ_3g@mail.gmail.com  
Backpatch: 11, where JIT support using llvm was introduced.  

commit   : 9003b76e169e8524f8d7c7547aded4749b9c39a1    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:44:54 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:44:54 -0400    

Two of the members of rconn were left uninitialized. When  
dblink_open() is called without an outer transaction it  
handles the initialization for us, but with an outer  
transaction it does not. Arrange for initialization  
in all cases. Backpatch to all supported versions.  
  
Reported-by: Alexander Lakhin  
Discussion: https://www.postgresql.org/message-id/flat/9bd0744f-5f04-c778-c5b3-809efe9c30c7%40joeconway.com#c545909a41664991aca60c4d70a10ce7  

commit   : 887cdff4dcbdfbfdbf9a29dfad0edc09c6ec3398    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:16:47 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:16:47 -0400    

The repeat() function loops for potentially a long time without  
ever checking for interrupts. This prevents, for example, a query  
cancel from interrupting until the work is all done. Fix by  
inserting a CHECK_FOR_INTERRUPTS() into the loop.  
  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/flat/8692553c-7fe8-17d9-cbc1-7cddb758f4c6%40joeconway.com  

commit   : 5b1c61e8b8f98f4a1c42856819b6dea600669f47    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:37:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:37:00 +0300    

ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE was used in an ereport with the  
same message but different errdetail a few lines earlier, so use that  
here as well.  
  
Backpatch-through: 11  

commit   : 0099db4ce1a19038d0d837bf82a35c989332cc58    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:35:18 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:35:18 +0300    

The same comment was copied to a few different places, with the same typo.  
Backpatch down to v11, where this typo was introduced.  

commit   : f93bb0ce64005c84e1d1d431eed31e0da4835078    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 16:40:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 16:40:07 +0900    

segment_open and segment_close were mentioned with incorrect names.  
  
Discussion: https://postgr.es/m/20200525234944.GA1573@paquier.xyz  

commit   : 55ca50deb8ffaec3b81d83c9f54c94f7e519f3a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 15:39:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 15:39:05 +0900    

The default unit for max_slot_wal_keep_size is megabytes.  While on it,  
also change temp_file_limit to use a more consistent wording.  
  
Reported-by: Jeff Janes, Fujii Masao  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAMkU=1wWZhhjpwRFKJ9waQGxxROeC0P6UqPvb90fAaGz7dhoHA@mail.gmail.com  

commit   : 0a737be03cf7708e8e27f9596be3406275ec3d49    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 May 2020 16:07:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 May 2020 16:07:55 +0200    

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

commit   : 896ddf9b3cd7dcf70e43f733ae8fec5dfe6e31af    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 26 May 2020 16:06:30 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 26 May 2020 16:06:30 -0700    

Disk-based HashAgg relies on writing to multiple tapes  
concurrently. Avoid fragmentation of the tapes' blocks by  
preallocating many blocks for a tape at once. No file operations are  
performed during preallocation; only the block numbers are reserved.  
  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20200519151202.u2p2gpiawoaznsv2%40development  

commit   : 49223e106b0a43452d64b4e52719532012c81e25    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 15:58:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 15:58:39 +0200    

Make the wording of new libpq messages more similar to existing  
messages in the backend.  

commit   : add4211600bfece1efb3d62befbc55b521790d76    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 14:09:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 14:09:36 +0200    

This was done for all scanners in  
421167362242ce1fb46d6d720798787e7cd65aad but not added to the new one.  

commit   : d9101e9806e446a413bcef16d3ab65602ed028ad    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 21:53:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 21:53:53 -0400    

Reported-by: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/54F7560D-498A-4E51-BAA4-17D4AAB2AA57@yesql.se  
  
Backpatch-through: master  

commit   : ac5852fb3042a4562e8a8bab26aaa00fa8183068    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 20:19:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 20:19:28 -0400    

These were missed when these were added to pg_hba.conf in PG 12;  
updates docs and pg_hba.conf.sample.  
  
Reported-by: Arthur Nascimento  
  
Bug: 16380  
  
Discussion: https://postgr.es/m/20200421182736.GG19613@momjian.us  
  
Backpatch-through: 12  

commit   : 587322de36921557fcfcfdd40291669c8ee46968    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:23:48 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:23:48 -0700    

The stmt_len changes do not affect behavior.  LimitPath has no other  
support functions, so that part changes only debugging output.  

commit   : 650eac8d7b6df7147ff4bb29b354510fe1929671    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:21:04 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:21:04 -0700    

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

commit   : 5832396432b1ce8349a0028b52295a9874014416    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 May 2020 15:18:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 May 2020 15:18:11 +0900    

pg_shmem_allocations was in the wrong position with pg_stats.  
  
Author: Ian Barwick  
Discussion: https://postgr.es/m/de7279d4-7ea0-037f-d7d2-1161682339db@2ndquadrant.com  

commit   : a995b371ae29de2d38c4b7881cf414b1560e9746    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 23 May 2020 14:03:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 23 May 2020 14:03:04 +0900    

The following commands have been missing calls to object access hooks  
InvokeObjectPost{Create|Alter}Hook normally applied to all commands:  
- ALTER RULE RENAME TO  
- ALTER USER MAPPING  
- CREATE ACCESS METHOD  
- CREATE STATISTICS  
  
Thanks also to Robert Haas for the discussion.  
  
Author: Mark Dilger  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/435CD295-F409-44E0-91EC-DF32C7AFCD76@enterprisedb.com  

commit   : c99cec96b8b1e067744b8a70961a3447a2293de0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 May 2020 17:39:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 May 2020 17:39:16 -0400    

They were introduced in 898e5e3290a7; backpatch to 12.  

commit   : eaae947e2b99a84c8f321fe084d87daff0f77d02    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 22 May 2020 23:33:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 22 May 2020 23:33:58 +0900    

Explain that the followings are tracked only when track_io_timing GUC  
is enabled.  
  
- blk_read_time and blk_write_time in pg_stat_database  
- time spent reading and writing data file blocks in EXPLAIN output  
   with BUFFERS option  
  
Whther track_io_timing is enabled affects also blk_read_time and  
blk_write_time in pg_stat_statements, but which was already documented.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CACZ0uYHo_NwbxpLH76OGF-O=13tkR0ZM0zeyGEhZ+JEXZVRyCA@mail.gmail.com  

commit   : 574925bfd0a8175f6e161936ea11d9695677ba09    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 22 May 2020 10:36:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 22 May 2020 10:36:49 +0200    

Probably copied from nearby calls where it is necessary.  But this one  
also casts away constness, so it was doubly annoying.  

commit   : bb2ae6fa47e5d84b6c5a9e3845021e7df031ec32    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 22 May 2020 15:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 22 May 2020 15:45:00 +0900    

The previous indentation of optimizer functions was unclear; adjust the  
indentation dashes so that a deeper level of indentation indicates that  
the outer optimizer function calls the inner one.  
  
Author: Richard Guo, with additional change by me  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAMbWs4-U-ogzpchGsP2BBMufCss1hktm%2B%2BeTJK_dUC196pw0cQ%40mail.gmail.com  

commit   : 10e1521f5c29da2dbe331462feb5408d5ef16915    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 22:07:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 22:07:17 -0400    

Reported-by: Erwin Brandstetter  
  
Discussion: https://postgr.es/m/CAGHENJ4X626ZfYhondXSP4sQgC5zDtsp_LNg1QaD+U7vfgYXQQ@mail.gmail.com  
  
Backpatch-through: head  

commit   : 6ed02e6ac3aac86e8f527e111064012e7911cf43    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:34:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:34:37 -0400    

Reported-by: Erwin Brandstetter  
  
Discussion: https://postgr.es/m/CAGHENJ4X626ZfYhondXSP4sQgC5zDtsp_LNg1QaD+U7vfgYXQQ@mail.gmail.com  
  
Backpatch-through: head  

commit   : 1c2ff3ef07d25ca4d291d35f8a31fe513fde58ab    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:28:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:28:38 -0400    

Reported-by: yigong hu  
  
Discussion: https://postgr.es/m/CAOxFffcourucFqSk+tZA13ErS3XRYkDy6EeaPff4AvHGiEEuug@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : c20fd088f1c5fb5e492f40d427c45b8de38c879c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 19:49:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 19:49:30 -0400    

Discussion: https://postgr.es/m/2304.1586532634@sss.pgh.pa.us  
  
Backpatch-through: 9.5  

commit   : 449e14a5618432f01066c33055229b96666bd925    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 21 May 2020 13:36:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 21 May 2020 13:36:45 -0700    

The B-Tree index deduplication strategy used during CREATE INDEX and  
REINDEX differs from the lazy strategy used by retail inserts.  Make  
that clear by adding a new paragraph to the B-Tree implementation  
section of the documentation.  
  
In passing, do some copy-editing of nearby deduplication documentation.  

commit   : 3350fb5d1f9d73de15428e9bfa83dce96421fc14    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 21 May 2020 08:31:16 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 21 May 2020 08:31:16 -0700    

commit   : e4db972ed5f12c09403ff0be24e12e5d4032aaaa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 15:49:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 15:49:20 +0900    

Since 74a308c, any security-sensitive information gets cleared from  
memory this way.  This was forgotten in 4dc6355.  
  
Author: Daniel Gustafsson  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/935443BA-D42E-4CE0-B181-1AD79E6DD45A@yesql.se  

commit   : d2a9959907a03682f4fe182086f9936aca6b2a4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 14:41:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 14:41:15 +0900    

When installing binaries and libraries using the MSVC installation  
routines, the operation gets done after moving to the root folder, whose  
location is detected by checking if "configure" exists two times in a  
row.  So, calling the installation script from src/tools/msvc/ with an  
extra "configure" file four levels up the root path of the code tree  
causes the execution to go further up, leading to a failure in finding  
the builds.  This commit fixes the issue by moving to the root folder of  
the code tree only once, when necessary.  
  
Author: Arnold Müller  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/16343-f638f67e7e52b86c@postgresql.org  
Backpatch-through: 9.5  

commit   : e1218f59ea4c0605e72298fa121d5aef4c66def2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 May 2020 14:35:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 May 2020 14:35:39 -0400    

This doc update was missed in 898e5e3290a7.  Backpatch to 12.  
  
Pointed out by Pavel Luzanov  
Discussion: https://postgr.es/m/642e9fbc-b832-698b-9a8f-d626afd7014d@postgrespro.ru  

commit   : 39cb2ee09cf900454c1bf14f56048b40c840a490    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 14:20:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 14:20:50 +0900    

The description missed a comma and lacked an explanation of what happens  
with REPLICA IDENTITY USING INDEX when the dependent index is dropped.  
  
Author: Marina Polyakova  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/ad1a0badc32658b1bbb07aa312346a1d@postgrespro.ru  
Backpatch-through: 9.5  

commit   : a56e7046d6f2a2ad23ffb9083eba9bc822f18881    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 09:12:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 09:12:52 +0900    

Oversight in 2c8dd05d, where the view's column has been renamed.  
  
Reported-by: Fujii Masao  
Discussion: https://postgr.es/m/c049ffcf-d2fe-90f7-c8ba-0741035aa6a7@oss.nttdata.com  

commit   : c7d65a252cdb7219deb48899fa643c5fd2cc3877    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2020 20:09:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2020 20:09:59 -0400    

This should be plain old ColId.  Making it so makes the grammar less  
complicated, and makes the compiled tables a kilobyte or so smaller  
(likely because they don't have to deal with a keyword classification  
that's not used anyplace else).  

commit   : 67b0b2dbf947c2308050e49b4591a4bb0e9650fd    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 19 May 2020 15:04:34 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 19 May 2020 15:04:34 -0700    

Commit 624686abcf8 added an assertion that verified that _bt_search  
successfully relocated the leaf page undergoing deletion.  Page deletion  
cannot deal with the case where the descent stack is to the right of the  
page, so this seemed critical (deletion can only handle the case where  
the descent stack is to the left of the leaf/target page).  However, the  
assertion went a bit too far.  
  
Since only a buffer pin is held on the leaf page throughout the call to  
_bt_search, nothing guarantees that it can't have split during this  
small window.  And if does actually split, _bt_search may end up  
"relocating" a page to the right of the original target leaf page.  This  
scenario seems extremely unlikely, but it must still be considered.  
Remove the assertion, and document how we cope in this scenario.  

commit   : c301c2e739c642199f9e4c62d867dc7bd5ef0fd1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 May 2020 19:28:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 May 2020 19:28:46 -0400    

FETCH FIRST .. ONLY implements this correctly, but we missed to include  
it for FETCH FIRST .. WITH TIES in commit 357889eb17bb.  
  
Author: Vik Fearing  
Discussion: https://postgr.es/m/6aa690ef-551d-e24f-2690-c38c2442947c@postgresfriends.org  

commit   : 7966b7980138ebcee7ae986ebcc393aea38a35c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 16:09:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 16:09:19 -0400    

commit   : fe0062c900efa5618197a8e3c88b027e93248db4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 13:21:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 13:21:36 -0400    

g_comment_start and g_comment_end have been unused since commit  
30ab5bd43d8f2082659191de8ae19be98c960ad7.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/2CA1BA9F-CDF9-41BE-96A1-2EFD2A3EA6CA@yesql.se  

commit   : b31d6efe3d06ca5983bbe63084322b5494b7c3ef    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 May 2020 10:20:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 May 2020 10:20:09 -0400    

Reported-by: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/0A9D816E-F49C-470B-A23F-8B4AF999382B@yesql.se  

commit   : ac449d88016080663dbc1cd48004b5a481c034ce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 18 May 2020 12:49:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 18 May 2020 12:49:30 +0200    

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

commit   : a01debe3db3d7f09797460500f217530b502c2de    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 18 May 2020 11:55:11 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 18 May 2020 11:55:11 +0200    

Author: Daniel Gustafsson  

commit   : 7e041b0c1d13b243b595d0b00145cb1116e4c327    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 May 2020 07:53:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 May 2020 07:53:26 +0530    

Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CA+fd4k4Ws7M7YQ8PqSym5WB1y75dZeBTd1sZJUQdfe0KJQ-iSA@mail.gmail.com  

commit   : 18b9d22cef988c4a67d440f6cafc160d9c05871b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 13:02:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 13:02:16 +0300    

 * Rename column "Opfamily Name" to "Operator family" for uniformity.  
 * Rename column alias from "t1" to "t".  

commit   : 29b6ddd38d0914340c3c4bb4bb4bd5c4a3c02dca    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:53:34 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:53:34 +0300    

Make number of translate_columns elements match the number of output columns.  
The only "true" value, which was previously specified, seems to be intended  
for opfamily operator "purpose" column.  But that column has already translated  
values substituted.  So, all elements in translate_columns[] should be "false".  

commit   : b1953e67e4c481f8d3844dcdd8fdd4054d7e7604    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:41:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:41:19 +0300    

This commit changes ORDER BY clause for \dAo and \dAp psql commands in  
the following way.  
 * Operators for the same types are grouped together.  
 * Same-class operators and procedures are listed before cross-class operators  
   and procedures.  
  
Modification of ORDER BY clause for \dAp required removing DISTINCT clause,  
which doesn't seem to affect anything.  
  
Discussion: https://postgr.es/m/20200511210856.GA18368%40alvherre.pgsql  
Author: Alvaro Herrera revised by me  
Reviewed-by: Alexander Korotkov, Nikita Glukhov  

commit   : eeba6c7e4366057a09c53efe11f144db55e68c5e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 22:19:02 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 22:19:02 -0400    

Author: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/508f2fb1764c3bd518ee96a4f2247d6f@xs4all.nl  

commit   : 3048898e73c75f54bb259323382e0e7f6368cb6f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 21:00:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 21:00:05 -0400    

Synchronize the event names for parallel hash join waits with other  
event names, by getting rid of the slashes and dropping "-ing"  
suffixes.  Rename ClogGroupUpdate to XactGroupUpdate, to match the  
new SLRU name.  Move the ProcSignalBarrier event to the IPC category;  
it doesn't belong under IO.  
  
Also a bit more wordsmithing in the wait event documentation tables.  
  
Discussion: https://postgr.es/m/4505.1589640417@sss.pgh.pa.us  

commit   : 2c8dd05d6cbc86b7ad21cfd7010e041bb4c3950b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 17 May 2020 09:22:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 17 May 2020 09:22:07 +0900    

d140f2f3 has renamed receivedUpto to flushedUpto, and has added  
writtenUpto to the WAL receiver's shared memory information, but  
pg_stat_wal_receiver was not consistent with that.  This commit renames  
received_lsn to flushed_lsn, and adds a new column called written_lsn.  
  
Bump catalog version.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20200515090817.GA212736@paquier.xyz  

commit   : e78b93094518b1e262cba8115470f252dde6f446    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 19:44:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 19:44:49 -0400    

libpq's exports.txt was overlooked in commit 36d108761, which the  
buildfarm is quite unhappy about.  
  
Also, I'd gathered that the plan included renaming PQgetSSLKeyPassHook  
to PQgetSSLKeyPassHook_OpenSSL, but that didn't happen in the patch  
as committed.  I'm taking it on my own authority to do so now, since  
the window before beta1 is closing fast.  

commit   : 36d1087611bf96b0cd716666fc8c4a2d168fa501    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 16 May 2020 16:20:43 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 16 May 2020 16:20:43 -0400    

4dc6355210 provided a way for libraries and clients to modify how libpq  
handles client certificate passphrases, by installing a hook. However,  
these routines are quite specific to how OpenSSL works, so it's  
misleading and not future-proof to have these names not refer to OpenSSL.  
Change all the names to add "_OpenSSL" after "Hook", and fix the docs  
accordingly.  
  
Author: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/981DE552-E399-45C2-9F60-3F0E3770CC61@yesql.se  

commit   : 1cbc143f06113cbd1b94790c0781aa4b410cffc2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 15:10:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 15:10:36 -0400    

Reported privately by Justin Pryzby  

commit   : fa27dd40d5c5f56a1ee837a75c97549e992e32a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:54:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:54:51 -0400    

Thomas Munro fixed a longstanding annoyance in pg_bsd_indent, that  
it would misformat lines containing IsA() macros on the assumption  
that the IsA() call should be treated like a cast.  This improves  
some other cases involving field/variable names that match typedefs,  
too.  The only places that get worse are a couple of uses of the  
OpenSSL macro STACK_OF(); we'll gladly take that trade-off.  
  
Discussion: https://postgr.es/m/20200114221814.GA19630@alvherre.pgsql  

commit   : e02ad575d8ab6b44500d2a3fd8c3212345e3aa2b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:49:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:49:14 -0400    

This is just to provide a clean basis for comparison of the results  
of the new version.  I did fix a typo that crept into 242dfcbaf.  
  
Discussion: https://postgr.es/m/20200114221814.GA19630@alvherre.pgsql  

commit   : 7ccb2f54d9f3f3c5b4ac092d62c846b02a47f8d5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 16 May 2020 18:15:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 16 May 2020 18:15:18 +0900    

In a logical replication subscriber, a table using REPLICA IDENTITY FULL  
which has a primary key would try to use the primary key's index  
available to scan for a tuple, but an assertion only assumed as correct  
the case of an index associated to REPLICA IDENTITY USING INDEX.  This  
commit corrects the assertion so as the use of a primary key index is a  
valid case.  
  
Reported-by: Dilip Kumar  
Analyzed-by: Dilip Kumar  
Author: Euler Taveira  
Reviewed-by: Michael Paquier, Masahiko Sawada  
Discussion: https://postgr.es/m/CAFiTN-u64S5bUiPL1q5kwpHNd0hRnf1OE-bzxNiOs5zo84i51w@mail.gmail.com  
Backpatch-through: 10  

commit   : 474e7da6485687425d216eda1685d7e530b24fd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 21:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 21:47:21 -0400    

It's just weird that this name wasn't chosen to look like an  
identifier.  The suspicion that it wasn't thought about too  
hard is reinforced by the fact that it wasn't documented in  
the pg_locks view (until I did so, a day or two back).  
  
Update, and add a comment reminding future adjusters of this  
array to fix the docs too.  
  
Do some desultory wordsmithing on various entries in the wait  
events tables.  
  
Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us  

commit   : 1d3743023ef8fa665902e791b0d52e9a1ab419cb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 19:59:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 19:59:29 -0400    

In commit 850196b610d2 I (Álvaro) failed to handle the case of walsender  
shutting down on an error before setting up its 'xlogreader' pointer;  
the error handling code dereferences the pointer, causing a crash.  
Fix by testing the pointer before trying to dereference it.  
  
Kyotaro authored the code fix; I adopted Nathan's test case to be used  
by the TAP tests and added the necessary PostgresNode change.  
  
Reported-by: Nathan Bossart <bossartn@amazon.com>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/C04FC24E-903D-4423-B312-6910E4D846E5@amazon.com  

commit   : 14a91010912632cae322b06fce0425faedcf7353    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:55:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:55:56 -0400    

This was mostly confusing, especially since some wait events in  
this class had the suffix and some did not.  
  
While at it, stop exposing MainLWLockNames[] as a globally visible  
name; any code using that directly is almost certainly wrong, as  
its name has been misleading for some time.  
(GetLWLockIdentifier() is what to use instead.)  
  
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us  

commit   : 8048404939bb0fcef80b0ab57910b6e10d4289a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:05:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:05:39 -0400    

The previous coding zeroed out offsetof(ReplicationStateCtl, states)  
more bytes than it was entitled to, as a consequence of starting the  
zeroing from the wrong pointer (or, if you prefer, using the wrong  
calculation of how much to zero).  
  
It's unsurprising that this has not caused any reported problems,  
since it can be expected that the newly-allocated block is at the end  
of what we've used in shared memory, and we always make the shmem  
block substantially bigger than minimally necessary.  Nonetheless,  
this is wrong and it could bite us someday; plus it's a dangerous  
model for somebody to copy.  
  
This dates back to the introduction of this code (commit 5aa235042),  
so back-patch to all supported branches.  

commit   : 36ac359d3621578cefc2156a3917024cdd3b1829    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 18:11:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 18:11:03 -0400    

Choose names that fit into the conventions for wait event names  
(particularly, that multi-word names are in the style MultiWordName)  
and hopefully convey more information to non-hacker users than the  
previous names did.  
  
Also rename SerializablePredicateLockListLock to  
SerializablePredicateListLock; the old name was long enough to cause  
table formatting problems, plus the double occurrence of "Lock" seems  
confusing/error-prone.  
  
Also change a couple of particularly opaque LWLock field names.  
  
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us  

commit   : a0ab4f4909a3f52e8b8243d2ae2dbb6f5027136c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 18:05:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 18:05:34 -0400    

commit   : 242dfcbafac592a3f097ec2e4e36fe1b739f7f29    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 16:50:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 16:50:34 -0400    

_bt_killitems marks btree items dead when a scan leaves the page where  
they live, but it does so with only share lock (to improve concurrency).  
This was historicall okay, since killing a dead item has no  
consequences.  However, with the advent of data checksums and  
wal_log_hints, this action incurs a WAL full-page-image record of the  
page.  Multiple concurrent processes would write the same page several  
times, leading to WAL bloat.  The probability of this happening can be  
reduced by only killing items if they're not already dead, so change the  
code to do that.  
  
The problem could eliminated completely by having _bt_killitems upgrade  
to exclusive lock upon seeing a killable item, but that would reduce  
concurrency so it's considered a cure worse than the disease.  
  
Backpatch all the way back to 9.5, since wal_log_hints was introduced in  
9.4.  
  
Author: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://postgr.es/m/CA+fd4k6PeRj2CkzapWNrERkja5G0-6D-YQiKfbukJV+qZGFZ_Q@mail.gmail.com  

commit   : 5da14938f7bfb96b648ee3c47e7ea2afca5bcc4a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 14:28:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 14:28:19 -0400    

Originally, the names assigned to SLRUs had no purpose other than  
being shmem lookup keys, so not a lot of thought went into them.  
As of v13, though, we're exposing them in the pg_stat_slru view and  
the pg_stat_reset_slru function, so it seems advisable to take a bit  
more care.  Rename them to names based on the associated on-disk  
storage directories (which fortunately we *did* think about, to some  
extent; since those are also visible to DBAs, consistency seems like  
a good thing).  Also rename the associated LWLocks, since those names  
are likewise user-exposed now as wait event names.  
  
For the most part I only touched symbols used in the respective modules'  
SimpleLruInit() calls, not the names of other related objects.  This  
renaming could have been taken further, and maybe someday we will do so.  
But for now it seems undesirable to change the names of any globally  
visible functions or structs, so some inconsistency is unavoidable.  
  
(But I *did* terminate "oldserxid" with prejudice, as I found that  
name both unreadable and not descriptive of the SLRU's contents.)  
  
Table 27.12 needs re-alphabetization now, but I'll leave that till  
after the other LWLock renamings I have in mind.  
  
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us  

commit   : 756abe2bc7608b38c579c510eb66f2bd80d10785    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 13:24:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 13:24:22 -0400    

Add some more terms, clarify some definitions, remove redundant terms,  
move a couple of terms to keep alphabetical order.  
  
Co-authored-by: Jürgen Purtz <juergen@purtz.de>  
Co-authored-by: Erik Rijkers <er@xs4all.nl>  
Co-authored-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/7b9b469e804777ac9df4d37716db935e@xs4all.nl  

commit   : 6755b618997424b9e651126f59bf4109d680fffe    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:47:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:47:07 -0400    

This avoids using <link> and supplied text.  

commit   : 85af628da5e8dfea068559d076ad26b9a3378bfc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:38:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:38:40 -0400    

This is for use by the PG 13 release notes, but might be used for minor  
release notes in the future.  
  
Backpatch-through: 9.5  

commit   : 75fcdd2ae2174c49a56acb4d10c920a6a45570f7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:05:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:05:43 -0400    

Add missing xreflabels for index types, geqo, libpq, spi, server-side  
languages, ecpg, and vaacuumlo.  
  
Backpatch-through: 9.5  

commit   : bc1c1de2cc30411bc5551ce1c7443914efa1fb86    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 11:21:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 11:21:43 -0400    

commit   : 065ea0c30d2c8290af368721708bd369b5020996    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:57:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:57:14 -0400    

commit   : e90807085c7f398c52a1567daf9cacff578031cf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:40:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:40:09 -0400    

commit   : e936fcb54d22561ad49c6c18f91dcb7566a58da1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 09:55:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 09:55:43 -0400    

Backpatch-through: 9.5  

commit   : 8d4b23fcae1f368122eb900489d6d24df75cff13    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:52:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:52:24 -0400    

commit   : ec5afb0a4e050616fe6953e597fd1f61d47edc3a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:29:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:29:57 -0400    

commit   : a9cf48a4cf0c878684a2f52a3a88e29399b2065e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 15 May 2020 08:10:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 15 May 2020 08:10:00 +0530    

COPY TO released the ACCESS SHARE lock immediately when it was done rather  
than holding on to it until the end of the transaction.  
  
This breaks the case where a REPEATABLE READ transaction could see an  
empty table if it repeats a COPY statement and somebody truncated the  
table in the meantime.  
  
Before 4dded12faad the lock was also released after COPY FROM, but the  
commit failed to notice the irregularity in COPY TO.  
  
This is old behavior but doesn't seem important enough to backpatch.  
  
Author: Laurenz Albe, based on suggestion by Robert Haas and Tom Lane  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/7bcfc39d4176faf85ab317d0c26786953646a411.camel@cybertec.at  

commit   : 39e7bcbbff82e25441529349134bf41fc336169b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 22:36:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 22:36:21 -0400    

commit   : ff87fabef20ef40c8438e25fe28e9159f874183d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 May 2020 08:19:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 May 2020 08:19:30 +0900    

The reasons why event triggers are disabled in standalone mode are  
documented in the code path of ddl_command_start, and other places  
checking if standalone mode is enabled or not mention to refer to the  
comment for ddl_command_start, except for table_rewrite that duplicated  
the same explanation.  
  
Reported-by: David G. Johnston  
Discussion: https://postgr.es/m/CAKFQuwYqHtXpvr2mBJRwH9f+Y5y1GXw3rhbaAu0Dk2MoNevsmA@mail.gmail.com  

commit   : 2e619f86a96c32a710a09a4ff555952746813ba8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:44:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:44:18 -0400    

I abbreviated the heck out of the column headings, and made a few  
small wording changes, to get it to build warning-free.  I can't  
say that the result is pretty, but it's probably better than  
removing this table entirely.  
  
As of this commit, we have zero "exceed the available area" warnings  
in a US-letter PDF build, and one such warning (about an 863-millipoint  
overrun) in an A4 build.  I expect to get rid of that one by renaming  
wait events, so I'm not doing anything about it at the formatting  
level.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : 3d14c174cbbb6f83d8ac63fa7d0e1f42e0ae8d30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:13:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:13:08 -0400    

In one or two places it seemed reasonable to modify the example so as  
to shorten its output slightly; but for the most part I just added a  
&zwsp; after 67 characters, which is the most we can fit on a line  
of monospace text in A4 format.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : 5cbfce562f7cd2aab0cdc4694ce298ec3567930e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 13:06:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 13:06:38 -0400    

Includes some manual cleanup of places that pgindent messed up,  
most of which weren't per project style anyway.  
  
Notably, it seems some people didn't absorb the style rules of  
commit c9d297751, because there were a bunch of new occurrences  
of function calls with a newline just after the left paren, all  
with faulty expectations about how the rest of the call would get  
indented.  

commit   : 1255466f8358ecac29581aa5ecec76628dc2e33c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 11:51:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 11:51:09 -0400    

commit   : 29c3e2dd5a6aeaf1a23d7d83d665501e2dcc6955    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 11:10:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 11:10:31 -0400    

There is little point in using the LWLockRegisterTranche mechanism for  
built-in tranche names.  It wastes cycles, it creates opportunities for  
bugs (since failing to register a tranche name is a very hard-to-detect  
problem), and the lack of any centralized list of names encourages  
sloppy nonconformity in name choices.  Moreover, since we have a  
centralized list of the tranches anyway in enum BuiltinTrancheIds, we're  
certainly not buying any flexibility in return for these disadvantages.  
  
Hence, nuke all the backend-internal LWLockRegisterTranche calls,  
and instead provide a const array of the builtin tranche names.  
  
(I have in mind to change a bunch of these names shortly, but this  
patch is just about getting them into one place.)  
  
Discussion: https://postgr.es/m/9056.1589419765@sss.pgh.pa.us  

commit   : 07451e1f1adc4ff832196f1f47def13e49d2ed38    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 May 2020 20:14:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 May 2020 20:14:58 +0900    

This addresses some whitespace issues with programlisting, and corrects  
the spelling of "Enter PEM pass phrase" to be consistent with the code.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/401F9024-20EA-4239-83C4-6B7AD35F94BD@yesql.se  

commit   : 267cc6ed29668fcf2e527f514f0fbbeaa73c388e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 13:53:16 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 13:53:16 +0300    

The type is called "pem_password_cb", not "pem_passwd_cb".  
  
Author: Daniel Gustafsson  
Discussion: https://www.postgresql.org/message-id/22108CF6-228B-45CF-9CDA-5C5F658DCC22@yesql.se  

commit   : 34dae902ca1c7d32a24b711131911e3045c0097d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 14 May 2020 12:44:44 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 14 May 2020 12:44:44 +0300    

amcheck expects at least hikey to always exist on leaf page even if it is  
deleted page.  But replica reinitializes page during replay of page deletion,  
causing deleted page to have no items.  Thus, replay of page deletion can  
cause an error in concurrent amcheck run.  
  
This commit relaxes amcheck expectation making it tolerate deleted page with  
no items.  
  
Reported-by: Konstantin Knizhnik  
Discussion: https://postgr.es/m/CAPpHfdt_OTyQpXaPJcWzV2N-LNeNJseNB-K_A66qG%3DL518VTFw%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  
Backpatch-through: 11  

commit   : e8abf585ab453ca9c2f66f2138baf6d3c9c8fbf0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 08:39:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 08:39:26 +0300    

Commit 3eb77eba5a moved the loop and refactored it, and inadvertently  
changed the effect of fsync=off so that it also skipped removing entries  
from the pendingOps table. That was not intentional, and leads to an  
assertion failure if you turn fsync on while the server is running and  
reload the config.  
  
Backpatch-through: 12-  
Reviewed-By: Thomas Munro  
Discussion: https://www.postgresql.org/message-id/3cbc7f4b-a5fa-56e9-9591-c886deb07513%40iki.fi  

commit   : a169155453e3d1c40c729a5318fd5298a990e5b0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 14 May 2020 09:23:56 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 14 May 2020 09:23:56 +0530    

Visual Studio 2015 and later versions should still be able to do the same  
as Visual Studio 2012, but the declaration of locale_name is missing in  
_locale_t, causing the code compilation to fail, hence this falls back  
instead on to enumerating all system locales by using EnumSystemLocalesEx  
to find the required locale name.  If the input argument is in Unix-style  
then we can get ISO Locale name directly by using GetLocaleInfoEx() with  
LCType as LOCALE_SNAME.  
  
In passing, change the documentation references of the now obsolete links.  
  
Note that this problem occurs only with NLS enabled builds.  
  
Author: Juan José Santamaría Flecha, Davinder Singh and Amit Kapila  
Reviewed-by: Ranier Vilela and Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CAHzhFSFoJEWezR96um4-rg5W6m2Rj9Ud2CNZvV4NWc9tXV7aXQ@mail.gmail.com  

commit   : cee9cadb592fed6a6cb126f02002aba029544bd8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    

The defect suppressed a Standby Status Update message when bytes flushed  
to disk had changed but bytes received had not changed.  If  
pg_recvlogical then exited with no intervening Standby Status Update,  
the next pg_recvlogical repeated already-flushed records.  The defect  
could also cause superfluous messages, which are functionally harmless.  
Back-patch to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/20200502221647.GA3941274@rfd.leadboat.com  

commit   : 8222a9d9a12356349114ec275b01a1a58da2b941    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    

pg_recvlogical merely called PQfinish(), so the backend sent messages  
after the disconnect.  When that caused EPIPE in internal_flush(),  
before a LogicalConfirmReceivedLocation(), the next pg_recvlogical would  
repeat already-acknowledged records.  Whether or not the defect causes  
EPIPE, post-disconnect messages could contain an ErrorResponse that the  
user should see.  One properly ends PGRES_COPY_OUT by repeating  
PQgetCopyData() until it returns a negative value.  Augment one of the  
tests to cover the case of WAL past --endpos.  Back-patch to v10, where  
commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 first appeared.  Before  
that commit, pg_recvlogical never reached PGRES_COPY_OUT.  
  
Reported by Thomas Munro.  
  
Discussion: https://postgr.es/m/CAEepm=1MzM2Z_xNe4foGwZ1a+MO_2S9oYDq3M5D11=JDU_+0Nw@mail.gmail.com  

commit   : 4fa8bd392d02637b4e4f27b79c06079e47765cbc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:36:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:36:58 -0400    

The previous design for this table didn't really work in narrow views,  
such as PDF output; besides which its reliance on large morerows  
values made it a pain to maintain (cf ab3e4fbd5, for example).  
  
I experimented with a couple of ways to fix it, but the best and  
simplest is to split it up into a separate table for each event  
type category.  
  
I also rearranged the event ordering to be strictly alphabetical,  
as nobody would ever be able to find entries otherwise.  
  
There is work afoot to revise the set of event names described  
in this table, but this commit just changes the layout, not the  
contents.  
  
In passing, add a missing entry to pg_locks.locktype,  
and cross-reference that to the related wait event list.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : a042750646db7ea28ff722855cf163401761937f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:03:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:03:39 -0400    

This changes our catalog and view descriptions to use a style inspired  
by the new format for function/operator tables: each table entry is  
formatted roughly like a <varlistentry>, with the column name and type  
on the first line and then an indented description.  This provides much  
more room for expansive descriptions than we had before, and thereby  
eliminates a passel of PDF build warnings.  
  
Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us  

commit   : 7fd89f4d7a51af77175a876613cffb490b9e5df1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 22:48:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 22:48:09 -0400    

Previously, AsyncShmemInit forcibly initialized the first page of the  
async SLRU, to save dealing with that case in asyncQueueAddEntries.  
But this is a poor tradeoff, since many installations do not ever use  
NOTIFY; for them, expending those cycles in AsyncShmemInit is a  
complete waste.  Besides, this only saves a couple of instructions  
in asyncQueueAddEntries, which hardly seems likely to be measurable.  
  
The real reason to change this now, though, is that now that we track  
SLRU access stats, the existing code is causing the postmaster to  
accumulate some access counts, which then get inherited into child  
processes by fork(), messing up the statistics.  Delaying the  
initialization into the first child that does a NOTIFY fixes that.  
  
Hence, we can revert f3d23d83e, which was an incorrect attempt at  
fixing that issue.  Also, add an Assert to pgstat.c that should  
catch any future errors of the same sort.  
  
Discussion: https://postgr.es/m/8367.1589391884@sss.pgh.pa.us  

commit   : d82a5058fdb5905abc9867da302000c39aa30f01    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 May 2020 22:48:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 May 2020 22:48:11 -0400    

commit   : 17cc133f017cb13737e23ce0da4415daf2c34cc3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 15:31:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 15:31:14 -0400    

The additional pain from level 4 is excessive for the gain.  
  
Also revert all the source annotation changes to their original  
wordings, to avoid back-patching pain.  
  
Discussion: https://postgr.es/m/31166.1589378554@sss.pgh.pa.us  

commit   : 81ca8686305c4c62d723ab224ad5c414f350a3a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 13:08:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 13:08:12 -0400    

Instead of re-identifying which statistics bucket to use for a given  
SLRU on every counter increment, do it once during shmem initialization.  
This saves a fair number of cycles, and there's no real cost because  
we could not have a bucket assignment that varies over time or across  
backends anyway.  
  
Also, get rid of the ill-considered decision to let pgstat.c pry  
directly into SLRU's shared state; it's cleaner just to have slru.c  
pass the stats bucket number.  
  
In consequence of these changes, there's no longer any need to store  
an SLRU's LWLock tranche info in shared memory, so get rid of that,  
making this a net reduction in shmem consumption.  (That partly  
reverts fe702a7b3.)  
  
This is basically code review for 28cac71bd, so I also cleaned up  
some comments, removed a dangling extern declaration, fixed some  
things that should be static and/or const, etc.  
  
Discussion: https://postgr.es/m/3618.1589313035@sss.pgh.pa.us  

commit   : 850196b610d2a1802b4ed7f9f608153a949eda34    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 12:17:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 12:17:08 -0400    

* Have both physical and logical walsender share a 'xlogreader' state  
  struct for tracking state.  This replaces the existing globals sendSeg  
  and sendCxt.  
  
* Change WALRead not to receive XLogReaderState->seg and ->segcxt as  
  separate arguments anymore; just use the ones from 'state'.  This is  
  made possible by the above change.  
  
* have the XLogReader segment_open contract require the callbacks to  
  install the file descriptor in the state struct themselves instead of  
  returning it.  xlogreader was already ignoring any possible failed  
  return from the callbacks, relying solely on them never returning.  
  
  (This point is not altogether excellent, as it means the callbacks  
  have to know more of XLogReaderState; but to really improve on that  
  we would have to pass back error info from the callbacks to  
  xlogreader.  And the complexity would not be saved but instead just  
  transferred to the callers of WALRead, which would have to learn how  
  to throw errors from the open_segment callback in addition of, as  
  currently, from pg_pread.)  
  
* segment_open no longer receives the 'segcxt' as a separate argument,  
  since it's part of the XLogReaderState argument.  
  
Per comments from Kyotaro Horiguchi.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200511203336.GA9913@alvherre.pgsql  

commit   : 043e3e04016077735f986726a3a74192c295ace7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:20:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:20:37 +0900    

This commit changes pg_stat_get_slru() so that it uses  
TimestampTzGetDatum() for stats_reset field because that field  
stores the timestamp with time zone value. Previously  
Int64GetDatum() was used.  
  
Author: Fujii Masao  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/b8784fe6-1401-ab35-aa14-d57b5bb8e312@oss.nttdata.com  

commit   : f3d23d83ef9a33344391acbaa92a6235a4350791    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:19:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:19:25 +0900    

Previously since SLRUStats was not initialized, SLRU stats counters  
could begin with non-zero value. Which could lead to incorrect results  
in pg_stat_slru view.  
  
Author: Fujii Masao  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/976bbb73-a112-de3c-c488-b34b64609793@oss.nttdata.com  

commit   : ac3a4866c0bf1d7a14009f18d3b42ffcb063a7e9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 12 May 2020 17:17:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 12 May 2020 17:17:12 -0400    

commit   : 87c291e29d6bf403c6adefd81ddafa134c254a3e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:15:55 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:15:55 -0400    

contrib/pgcrypto did contain an unedited fall-through marker after all.  

commit   : 3e9744465dbe51822c7d76baca1f934d54ba9452    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:01:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:01:52 -0400    

Use it at level 4, a bit more restrictive than the default level, and  
tweak our commanding comments to FALLTHROUGH.  
  
(However, leave zic.c alone, since it's external code; to avoid the  
warnings that would appear there, change CFLAGS for that file in the  
Makefile.)  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20200412081825.qyo5vwwco3fv4gdo@nol  
Discussion: https://postgr.es/m/flat/E1fDenm-0000C8-IJ@gemulon.postgresql.org  

commit   : 6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 20:04:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 20:04:39 +0200    

The explain format used by incremental sort was somewhat inconsistent  
with other nodes, making it harder to parse and understand. This commit  
addresses that by  
  
 - adding an extra space to better separate groups of values  
  
 - using colons instead of equal signs to separate key/value  
  
 - properly capitalizing first letter of a key  
  
 - using separate lines for full and pre-sorted groups  
  
These changes were proposed by Justin Pryzby and mostly copy the final  
explain format used to report WAL usage.  
  
Author: Justin Pryzby  
Reviewed-by: James Coleman  
Discussion: https://postgr.es/m/20200419023625.GP26953@telsasoft.com  

commit   : 1a40d37a9faff562a36bd255a993fd3503bdf2b1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 19:37:13 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 19:37:13 +0200    

Author: Justin Pryzby, James Coleman  
Discussion: https://postgr.es/m/20200419023625.GP26953@telsasoft.com  

commit   : 7b48f1b490978a8abca61e9a9380f8de2a56f266    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 May 2020 13:03:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 May 2020 13:03:43 -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=5032  
  
Also run reformat_dat_file.pl while I'm here.  
  
Renumbering recently-added types changed some results in the opr_sanity  
test.  To make those a bit easier to eyeball-verify, change the queries  
to show regtype not just bare type OIDs.  (I think we didn't have  
regtype when these queries were written.)  

commit   : 2793bbe75e276476877ff9af6bb7effe92eff782    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 12 May 2020 19:55:55 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 12 May 2020 19:55:55 +0900    

My oversight in commit c8434d64c.  

commit   : 078c9cd258e5ad8f54081c971b7b927f845e7505    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 May 2020 14:43:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 May 2020 14:43:57 +0900    

The existing callers of XLogReadDetermineTimeline() performing recovery  
need to check a replay LSN position when determining on which timeline  
to read a WAL page.  A portion of the comment describing this function  
said exactly that, while referring to a routine for fetching a write  
LSN, something not available in recovery.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200511.101619.2043820539323292957.horikyota.ntt@gmail.com  

commit   : 81ec990a23b9cbfaa5684e90091164f1d85f24d3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 May 2020 13:56:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 May 2020 13:56:19 +0900    

Commit 2eb34ac369 changed error messages emit when commands are  
rejected during recovery. But it forgot to update the standbycheck  
regression test output with those error message changes.  
  
Reported-by: Michail Nikolaev  
Author: Michail Nikolaev  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CANtu0ojFPgcspH=0nNZ+qmu0XD69sXKtVttuSoYKHawRADSQGg@mail.gmail.com  

commit   : b89d90b051a1da7a447b25dc749ce42ccb4dc5bd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 22:58:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 22:58:47 -0400    

Add section about function table reformatting.  

commit   : 57775e82b235b2c815d9fd85cea53d77373a9203    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:41:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:41:06 -0400    

I can't see any way to make this table fit in PDF column width  
without either a fundamental redesign or abbreviating EXCLUSIVE.  
So I did the latter.  
  
It'd be nicer if the abbreviating didn't leak into the HTML output  
as well; but the hackery required to make the output different  
seems like more trouble than it's really worth.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : aa976d3b9004bd2c275e4ad17fa897ce5fe5127e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:24:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:24:08 -0400    

commit   : ca4599b0dcc4ed44e24cc4f2cd39677a19356324    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:19:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:19:57 -0400    

commit   : 4d1563717fb1860168a40b852e1d61a33ecdd62f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:03:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:03:55 -0400    

Even after the tweaking I did in commit 5545b69ae, some of the  
longer keywords mentioned in the SQL standard don't fit the  
available space in PDF output.  
  
I experimented with various solutions like putting such keywords  
on their own table lines, but everything looked ugly or confusing  
or both; worse, the weirdness also appeared in the HTML version,  
which (normally) doesn't need it.  
  
The best answer seems to be to insert &zwsp; into long keywords  
so that they can be broken into two lines when, and only when,  
needed.  It doesn't look too awful if the break happens after  
an underscore --- and fortunately, all the problematic keywords  
have underscores.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : 60c90c16c1885bb9aa2047b66f958b865c5d397e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 14:15:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 14:15:49 -0400    

Use xreflabel attributes instead of endterm attributes to control the  
appearance of links to subsections of SQL command reference pages.  
This is simpler, it matches what we do elsewhere (e.g. for GUC variables),  
and it doesn't draw "Unresolved ID reference" warnings from the PDF  
toolchain.  
  
Fix some places where the text was absolutely dependent on an <xref>  
rendering exactly so, by using a <link> around the required text  
instead.  At least one of those spots had already been turned into  
bad grammar by subsequent changes, and the whole idea is just too  
fragile for my taste.  <xref> does NOT have fixed output, don't write  
as if it does.  
  
Consistently include a page-level link in cross-man-page references,  
because otherwise they are useless/nonsensical in man-page output.  
Likewise, be consistent about mentioning "below" or "above" in same-page  
references; we were doing that in about 90% of the cases, but now it's  
100%.  
  
Also get rid of another nonfunctional-in-PDF idea, of making  
cross-references to functions by sticking ID tags on <row> constructs.  
We can put the IDs on <indexterm>s instead --- which is probably not any  
more sensible in abstract terms, but it works where the other doesn't.  
(There is talk of attaching cross-reference IDs to most or all of  
the docs' function descriptions, but for now I just fixed the two  
that exist.)  
  
Discussion: https://postgr.es/m/14480.1589154358@sss.pgh.pa.us  

commit   : 624686abcf87d26fe7c03543c4a54aad2237cb93    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 11 May 2020 11:01:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 11 May 2020 11:01:07 -0700    

Restructure the function that locates the root of the to-be-deleted  
subtree during nbtree page deletion.  Handle the conditions that make  
page deletion unsafe in a slightly more uniform way, and acknowledge the  
fact that the behavior with incomplete splits on internal pages is  
different (as pointed out in the nbtree README as of commit 35bc0ec7).  
Also invent new terminology that avoids ambiguity around which pages are  
about to be deleted.  Consistently use the term "to-be-deleted subtree",  
not the ambiguous term "branch".  
  
We were calling the subtree parent page the "top parent page", but that  
was quite misleading.  The top parent page usually refers to a page  
unlinked from its siblings and marked deleted (during the second stage  
of page deletion).  There was one kind of top parent page that we merely  
removed a downlink from, and another kind of top parent page that we  
actually marked deleted.  Eliminate the ambiguity by inventing a new  
term ("subtree parent page") that refers to the former kind of page  
only.  

commit   : a8be5364ac1678e35029f547632d4002552f943c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 11 May 2020 12:46:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 11 May 2020 12:46:41 -0400    

The one in xlogreader.h was pointed out by Antonin Houska; I (Álvaro) noticed the  
others by grepping.  
  
Author: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/28250.1589186654@antos  

commit   : 7a9c9ce6411720c2bbeaf6e64855d4263c47ea80    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2020 13:14:32 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2020 13:14:32 +0200    

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

commit   : 336aa51b70e9cf7da3969a3f102ff4913717083d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 May 2020 16:20:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 May 2020 16:20:28 -0400    

This patch eliminates a few more "exceed the available area" warnings  
whose causes aren't particularly connected to anything else.  
  
The only one really worthy of comment is that I increased the space  
allowed for an <orderedlist>'s numbers, because the default of 1em  
doesn't quite work for more than one digit.  The rest are one-off  
insertions of &zwsp; and suchlike tweaks, in places where they  
shouldn't do any damage to the material.  (In particular, although  
I split some long identifiers with zwsp's, there are other nearby  
occurrences of each one; so those changes shouldn't hurt greppability  
of the document sources.)  

commit   : e111c9f90ab6090859127cbb22156f4858b6a40c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 May 2020 10:58:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 May 2020 10:58:54 +0900    

The last caller of this routine was removed in b416691, and as a wise  
man said one day, dead code tends to silently break.  
  
Per discussion between Fujii Masao, Peter Geoghegan, Vignesh C and me.  
  
Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wz=sg5H8-vG4d5UmAofdcRMpeTDt2K-NUWp4GSfhenRGAQ@mail.gmail.com  

commit   : 9356e43544287f1b727e6cb3350f98e35ecea752    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 19:09:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 19:09:44 -0400    

I made up a very crude hack to compare the docs with reality (as  
embodied in the system catalogs) ... and indeed they don't match  
everywhere.  Missing oid columns, wrong data types, wrong "references"  
links, columns listed in the wrong order.  None of this seems quite  
important enough to back-patch.  

commit   : 96d175e3e2ea1bbf734f21444126a711da12108b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 16:28:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 16:28:09 -0400    

Somehow we'd never noticed this oversight, even though it means  
that such basic columns as pg_proc.proargtypes were not being  
validated by the oidjoins test.  Correct the query and update  
the test script with the newly-found dependencies.  

commit   : ebeb3dea772652887b67a7549906f5a9ec8a487f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:42 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:42 +0200    

Incremental sort always processes at least one full group group before  
switching to prefix groups, so it's enough to check just the number of  
full groups. There was no risk of division by zero due to the extra  
condition, but it made the code harder to understand.  
  
Reported-by: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQAp+7qoS92-4V1vLChpdY3vEkLCbf+gye6P-4cirE-0z0A@mail.gmail.com  

commit   : 9155b4be9a13038d59a7a09a27b7fbce3819eb08    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:36 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:36 +0200    

ExecReScanIncrementalSort was resetting bounded=false, which means the  
optimization would be disabled on all rescans. This happens because  
ExecSetTupleBound is called before the rescan, not after it.  
  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20200414065336.GI1492@paquier.xyz  

commit   : c4427226483c78618ba45eff34917400a77718a5    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:18 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:18 +0200    

The executor flags were not handled entirely correctly, although the  
bugs were mostly harmless and it was mostly comment inaccuracy. We don't  
need to strip any of the flags for child nodes.  
  
Incremental sort does not support backward scans of mark/restore, so  
MARK/BACKWARDS flags should not be possible. So we simply ensure this  
using an assert, and we don't bother removing them when initializing  
the child node.  
  
With REWIND it's a bit less clear - incremental sort does not support  
REWIND, but there is no way to signal this - it's legal to just ignore  
the flag. We however continue passing the flag to child nodes, because  
they might be useful to leverage that.  
  
Reported-by: Michael Paquier  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20200414065336.GI1492@paquier.xyz  

commit   : 6c298881c20797ac424558b9ff68d9781e03f6c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 13:05:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 13:05:08 -0400    

We seem to have forgotten to do this in the v12 cycle, so add it as  
a task in the RELEASE_CHANGES list, in hopes we won't forget again.  
  
While here, fix findoidjoins.c so that it actually works in the  
new dispensation where OID is a regular column, and change it to only  
consider system relations (this avoids being fooled by the OID column  
in the brintest test table).  
  
Also tweak the largeobject test so that the somewhat-recently-added  
manual creation of a LO with an OID in the system range doesn't  
fool findoidjoins.c.  For the moment I just made that use an unused  
OID, but we might have to find a more robust solution someday.  

commit   : 89a7d21dfc9d891d2b3dcfea161b58d4ea458af6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 19:38:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 19:38:46 -0400    

Almost all error messages already include file name where relevant, but  
this one had been overlooked.  Repair.  
  
Backpatch to 9.5.  
  
Author: Euler Taveira <euler.taveira@2ndquadrant.com>  
Discussion: https://postgr.es/m/CAH503wA_VOrcKL_43p9atRejCDYmOZ8MzfK9S6TJrQqBqNeAXA@mail.gmail.com  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : b060dbe0001a1d6bf26cd294710f3cb203868d46    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 15:30:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 15:30:34 -0400    

Code review for 0dc8ead46363, prompted by a bug closed by 91c40548d5f7.  
  
XLogReader's system for opening and closing segments had gotten too  
complicated, with callbacks being passed at both the XLogReaderAllocate  
level (read_page) as well as at the WALRead level (segment_open).  This  
was confusing and hard to follow, so restructure things so that these  
callbacks are passed together at XLogReaderAllocate time, and add  
another callback to the set (segment_close) to make it a coherent whole.  
Also, ensure XLogReaderState is an argument to all the callbacks, so  
that they can grab at the ->private data if necessary.  
  
Document the whole arrangement more clearly.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20200422175754.GA19858@alvherre.pgsql  

commit   : 871696ba20e0251e86041576373809d1c7ca161d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 20:35:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 20:35:03 +0200    

*in* database, *in* cluster, *on* server; and some related fixes  

commit   : 7666ef313dcc22c8716ee74dfefab8e5ea628678    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 13:33:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 13:33:00 +0200    

There were a few different ways to line-wrap the error messages.  Make  
them all the same, and use placeholders for the actual program names,  
to save translation work.  

commit   : 086ffddf3656fb3d24d9a73ce36cb1102e42cc90    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 May 2020 16:25:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 May 2020 16:25:54 +0200    

Several combinations of generated columns and inheritance in CREATE  
TABLE were not handled correctly.  Specifically:  
  
- Disallow a child column specifying a generation expression if the  
  parent column is a generated column.  The child column definition  
  must be unadorned and the parent column's generation expression will  
  be copied.  
  
- Prohibit a child column of a generated parent column specifying  
  default values or identity.  
  
- Allow a child column of a not-generated parent column specifying  
  itself as a generated column.  This previously did not work, but it  
  was possible to arrive at the state via other means (involving ALTER  
  TABLE), so it seems sensible to support it.  
  
Add tests for each case.  Also add documentation about the rules  
involving generated columns and inheritance.  
  
Discussion:  
    https://www.postgresql.org/message-id/flat/15830.1575468847%40sss.pgh.pa.us  
    https://www.postgresql.org/message-id/flat/2678bad1-048f-519a-ef24-b12962f41807%40enterprisedb.com  
    https://www.postgresql.org/message-id/flat/CAJvUf_u4h0DxkCMCeEKAWCuzGUTnDP-G5iVmSwxLQSXn0_FWNQ%40mail.gmail.com  

commit   : 501e41dd3cb945287fdcfe25e8906e79872fcc44    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Apr 2020 14:10:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Apr 2020 14:10:01 +0200    

When creating a new index, the attstorage setting of the table column  
is copied to regular (non-expression) index columns.  But a later  
ALTER TABLE ... SET STORAGE is not propagated to indexes, thus  
creating an inconsistent and undumpable state.  
  
Discussion: https://www.postgresql.org/message-id/flat/9765d72b-37c0-06f5-e349-2a580aafd989%402ndquadrant.com  

commit   : f9463d2a903da930531d124ea8bbbff8c097d86b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 8 May 2020 08:33:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 8 May 2020 08:33:05 +0530    

Commit 6e654546fb avoids locking bufmgr partitions to make pg_buffercache  
less disruptive on production systems but forgot to update the docs.  
  
Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CA+fd4k6sD8oeP1qJbFAor=rCpYckU9DsywHiYx3x5Hz5Z8Ua_w@mail.gmail.com  

commit   : f2ff2035962cd2ddd56c1593709d48ca0d3a78c5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 8 May 2020 10:36:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 8 May 2020 10:36:40 +0900    

TimelineHistoryRead and TimelineHistoryWrite wait events are reported  
during waiting for a read and write of a timeline history file, respectively.  
However, previously, TimelineHistoryRead wait event was not reported  
while readTimeLineHistory() was reading a timeline history file. Also  
TimelineHistoryWrite was not reported while writeTimeLineHistory() was  
writing one line with the details of the timeline split, at the end.  
This commit fixes these issues.  
  
Back-patch to v10 where wait events for a timeline history file was added.  
  
Author: Masahiro Ikeda  
Reviewed-by: Michael Paquier, Fujii Masao  
Discussion: https://postgr.es/m/d11b0c910b63684424e06772eb844ab5@oss.nttdata.com  

commit   : cd8c73a38a23c364e71973d6832a585616d24756    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 7 May 2020 16:08:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 7 May 2020 16:08:54 -0700    

Factor out code common to _bt_lock_branch_parent() and _bt_pagedel()  
into a new utility function.  This new function is used to check that  
the left sibling of a deletion target page does not have the  
INCOMPLETE_SPLIT page flag set.  If it is set then deletion is unsafe;  
there won't be a usable pivot tuple (with a downlink) in the parent page  
that points to the deletion target page.  The page deletion algorithm is  
not prepared to deal with that.  Also restructure an existing, related  
utility function that checks if the right sibling of the target page has  
the ISHALFDEAD page flag set.  
  
This organization highlights the symmetry between the two cases.  The  
goal is to make the design of page deletion clearer.  Both functions  
involve a sibling page with a flag that indicates that there was an  
interrupted operation (a page split or a page deletion) that resulted in  
a page pointed to by sibling pages, but not pointed to in the parent.  
And, both functions indicate if page deletion is unsafe due to the  
absence of a particular downlink in the parent page.  

commit   : db89f0e3a45e98c1065355af75f41b5652333111    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 15:59:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 15:59:51 -0400    

checkcondition_str() failed to report multiple matches for a prefix  
pattern correctly: it would dutifully merge the match positions, but  
then after exiting that loop, if the last prefix-matching word had  
had no suitable positions, it would report there were no matches.  
The upshot would be failing to recognize a match that the query  
should match.  
  
It looks like you need all of these conditions to see the bug:  
* a phrase search (else we don't ask for match position details)  
* a prefix search item (else we don't get to this code)  
* a weight restriction (else checkclass_str won't fail)  
  
Noted while investigating a problem report from Pavel Borisov,  
though this is distinct from the issue he was on about.  
  
Back-patch to 9.6 where phrase search was added.  

commit   : b2fd8ebe239f726b99923f827e908a92f6f4f232    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 14:25:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 14:25:18 -0400    

This converts the contrib documentation to the new style, and mops up  
a couple of function tables that were outside chapter 9 in the main  
docs.  
  
A few contrib modules choose not to present their functions in the  
standard tabular format.  There might be room to rethink those decisions  
now that the standard format is more friendly to verbose descriptions.  
But I have not undertaken to do that here; I just converted existing  
tables.  

commit   : c265ed9b355fdd2a80e7af64e88cddabd3d39151    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 13:06:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 13:06:31 -0400    

Reported-by: Amit Langote  

commit   : db9e99da2c61f46bfe37032bab1ee602e5c8335c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 10:01:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 10:01:22 -0400    

commit   : 545a065880be8ccddfb116a0915bfdac0cd41902    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 09:00:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 09:00:24 -0400    

This merges three partition publication items into two.  

commit   : fb544735f11480a697fcab791c058adc166be1fa    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:34:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:34:22 -0400    

Reported-by: Andrey M. Borodin  
  
Discussion: https://postgr.es/m/D49B37B1-E2B9-4F67-8C6C-5CFD4015E8C5@yandex-team.ru  

commit   : c3d1fdb59891e78df9ffb89b3e8bea780bd90568    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:07:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:07:29 -0400    

Reported-by: Fabien COELHO  
  
Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2005051811320.2183756@pseudo  

commit   : 90be091480d439db6876f6cbebf9ea42ccb79496    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 15:58:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 15:58:23 -0400    

In the wake of commit f21599311, we don't need to set table columns'  
align specs retail.  Undo a few such settings I'd added in commit  
5545b69ae.  (The column width adjustments stay, though.)  

commit   : 5be594caf818e0b5e33f8dec191f2707394a6d95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 May 2020 12:29:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 May 2020 12:29:41 -0400    

We were acquiring object locks then deleting objects one by one, instead  
of acquiring all object locks first, ignoring those that did not exist,  
and then deleting all objects together.   The latter is the correct  
protocol to use, and what this commits changes to code to do.  Failing  
to follow that leads to "cache lookup failed for relation XYZ" error  
reports when DROP OWNED runs concurrently with other DDL -- for example,  
a session termination that removes some temp tables.  
  
Author: Álvaro Herrera  
Reported-by: Mithun Chicklore Yogendra (Mithun CY)  
Reviewed-by: Ahsan Hadi, Tom Lane  
Discussion: https://postgr.es/m/CADq3xVZTbzK4ZLKq+dn_vB4QafXXbmMgDP3trY-GuLnib2Ai1w@mail.gmail.com  

commit   : f21599311e50a43c90a3d33ef4f60193a774321a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 12:23:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 12:23:43 -0400    

I concluded that we really just ought to force all tables in PDF output  
to default to "left" alignment (instead of "justify"); that is what the  
HTML toolchain does and that's what most people have been designing the  
tables to look good with.  There are few if any places where "justify"  
produces better-looking output, and there are many where it looks  
horrible.  So change stylesheet-fo.xsl to make that true.  
  
Also tweak column widths in a few more tables to make them look better  
and avoid "exceed the available area" warnings.  This commit fixes  
basically everything that can be fixed through that approach.  The  
remaining tables that give warnings either are scheduled for redesign  
as per recent discussions, or need a fundamental rethink because they  
Just Don't Work in a narrow view.  

commit   : beb2516e961490723fb1a2f193406afb3d71ea9c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 May 2020 21:08:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 May 2020 21:08:15 +0900    

Attempting to use an installation path of Python that includes spaces  
caused the MSVC builds to fail.  This fixes the issue by using the same  
quoting method as ad7595b for OpenSSL.  
  
Author: Victor Wagner  
Discussion: https://postgr.es/m/20200430150608.6dc6b8c4@antares.wagner.home  
Backpatch-through: 9.5  

commit   : 7dc37ccea8599f460ec95b8a0208e2047a6fb4bf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:45:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:45:34 -0400    

commit   : d08ac7d85fc844bb5b2cb456a858e9f4d344722c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:43:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:43:27 -0400    

commit   : 0025a90f732b06027f6eaa6d35dbb303baffef10    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:42:10 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:42:10 -0700    

Oversight in commit bc3087b626d.  

commit   : 18c117cc56269f064d1b81674771d1559cf88b3d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:36:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:36:54 -0700    

Oversight in commit d114cc53.  

commit   : e0acac67da46951bf00d4d0df33a8020cac7308c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:21:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:21:57 -0400    

commit   : b0e02f47cdb0be44a229e261e932221575381269    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 16:31:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 16:31:44 -0400    

commit   : bb20f2c80d81377b036b1a673261ca842282ee10    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 16:06:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 16:06:49 -0400    

Moving this setting into the main configuration file was ill-considered,  
perhaps, because that typically causes it to be set before  
timezone_abbreviations has been set.  Which in turn means that zone  
abbreviations don't work, only full zone names.  
  
We could imagine hacking things so that such cases do work, but the  
stability of the hack would be questionable, and the value isn't really  
that high.  Instead just document that you should use a numeric zone  
offset or a full zone name.  
  
Per bug #16404 from Reijo Suhonen.  
Back-patch to v12 where this was changed.  
  
Discussion: https://postgr.es/m/16404-4603a99603fbd04c@postgresql.org  

commit   : 98c017c5760c1107a846c85eb20a1b3b80cad8c7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 14:40:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 14:40:27 -0400    

Reported-by: Justin Pryzby  

commit   : ab3f2f45d28235ee60ac2426f2282f401a0b0c12    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 13:18:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 13:18:05 -0400    

Reported-by: Justin Pryzby  

commit   : 46da7bf671c002659d48dad72d325167db8df84b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 13:10:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 13:10:09 -0400    

Both the backend and libpq leaked buffers containing encrypted data  
to be transmitted, so that the process size would grow roughly as  
the total amount of data sent.  
  
There were also far-less-critical leaks of the same sort in GSSAPI  
session establishment.  
  
Oversight in commit b0b39f72b, which I failed to notice while  
reviewing the code in 2c0cdc818.  
  
Per complaint from pmc@citylink.  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/20200504115649.GA77072@gate.oper.dinoex.org  

commit   : d4329a60d5708382957e61d1036a03929f75c9fc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 12:42:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 12:42:55 -0400    

commit   : 61dfa727494ffa337cadde51a01d3a1813c1f6d2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 11:42:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 11:42:28 -0400    

commit   : 3114d26bfb93962e503df19210086abe67f2044e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:33:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:33:50 -0400    

commit   : 41297fa7d86d0410efc90aebdd39f686b81bf09e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:32:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:32:50 -0400    

Minor corrections from individuals.  

commit   : d5627f3cd0ba191f1e647d66f6d5bb09ff95b786    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 5 May 2020 08:49:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 5 May 2020 08:49:52 +0200    

commit   : c5114e42fa1ddd2c44a03339ffa436e732477397    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 May 2020 14:16:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 May 2020 14:16:01 +0900    

The following docs are updated:  
- High-availaility section  
- pg_basebackup  
- pg_receivewal  
  
Per the principle of least privilege, we want to encourage users to  
interact with those areas using roles that have replication rights, but  
superusers were mentioned first.  
  
Author: Daniel Gustafsson  
Reviewed-by: Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/ECEBD212-7101-41EB-84F3-2F356E4B6401@yesql.se  

commit   : 849ac3581329bdcbcfdba4452fa9c1ec6e10c24c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 May 2020 23:09:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 May 2020 23:09:45 -0400    

This still needs markup, indenting, and word wrap.  

commit   : 69bfaf2e1de49de76d7dec1c45511932a5ef502b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 5 May 2020 08:00:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 5 May 2020 08:00:53 +0530    

In commit 33e05f89c5, we have added the option to display WAL usage  
statistics in Explain and auto_explain.  The display format used two spaces  
between each field which is inconsistent with Buffer usage statistics which  
is using one space between each field.  Change the format to make WAL usage  
statistics consistent with Buffer usage statistics.  
  
This commit also changed the usage of "full page writes" to  
"full page images" for WAL usage statistics to make it consistent with  
other parts of code and docs.  
  
Author: Julien Rouhaud, Amit Kapila  
Reviewed-by: Justin Pryzby, Kyotaro Horiguchi and Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : 5545b69ae65f27ba1f4ceaf24486e98c186e9412    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 16:16:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 16:16:42 -0400    

The PDF toolchain defaults to laying out all columns of a table with  
equal widths, in contrast to the HTML rendering which automatically  
varies the column widths to fit the data.  In many places, this  
results in very badly laid-out tables, with lots of useless whitespace  
in some places and text that overruns its cell in other places.  
  
For tables that have reasonably static content, we can improve  
matters by adding <colspec> entries to hand-assign the column widths.  
This commit does that for a few of the tables that were worst off;  
it eliminates close to 200 "contents ... exceed the available area"  
warnings in an A4 PDF build.  
  
I also forced align="left" in these tables, overriding the PDF  
toolchain's default which is evidently "justify".  (The HTML toolchain  
seems to default to that already.)  Anyplace where things are tight  
enough that we need to worry about this, forced justification tends to  
look truly awful.  

commit   : 20c6905dee43a8888090674cb3db9f953ae7f646    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 4 May 2020 11:23:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 4 May 2020 11:23:44 -0700    

Add a test case to contrib/amcheck that creates coverage of code paths  
that are used to verify posting list tuples (tuples created when  
deduplication merges together existing tuples to avoid a leaf page  
split).  

commit   : 47046763c3ed1f16b81a389df7e44be5f3dba83c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 13:48:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 13:48:30 -0400    

We had a mishmash of <replaceable>, <replaceable class="parameter">,  
and <parameter> markup for operator/function arguments.  Use <parameter>  
consistently for things that are in fact names of parameters (including  
OUT parameters), reserving <replaceable> for things that aren't.  The  
latter class includes some made-up-by-the-docs type class names, like  
"numeric_type", as well as placeholders for arguments that don't have  
well-defined types.  Possibly we could do better with those categories  
as well, but for the moment I'm content not to have parameter names  
marked up in different ways in different places.  
  
(This commit aligns the earlier sections of chapter 9 with a policy  
that I'd arrived at while working on commit 1ad23335f, which is why  
the last few sections need no changes.)  

commit   : 1ad23335f36b07f4574906a8dc66a3d62af7c40c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 12:18:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 12:18:06 -0400    

With the usual quota of minor and less-minor editorial changes.  

commit   : 9f87ae38eaffcc7f72c45bfeb79e09dd6e8c2f48    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 3 May 2020 12:19:31 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 3 May 2020 12:19:31 +0300    

Reported-by: Oleg Bartunov  

commit   : 7dd777938bbeae8113f73849920a5b19bef723d9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 3 May 2020 10:45:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 3 May 2020 10:45:52 +0200    

commit   : 9dc72514179d85e81ea594130ff0eb655188f225    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 2 May 2020 14:04:33 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 2 May 2020 14:04:33 -0700    

Remove one of the arguments to btvacuumpage(), and give up on the idea  
that it's a recursive function.  We now use the term "backtracking" to  
refer to the case where an earlier block must be visited to make sure no  
tuples that need to be removed were missed.  
  
Advertising btvacuumpage() as a recursive function was unhelpful.  In  
reality the function always simulates recursion with a loop (it doesn't  
actually call itself).  This wasn't just necessary as a precaution (per  
the comments mentioning tail recursion), though.  There is no reliable  
natural limit on the number of times we can backtrack.  
  
There are important behavioral difference when "recursing"/backtracking,  
mostly related to page deletion.  We don't perform page deletion when  
backtracking due to the extra complexity.  And when we recurse, we're  
not performing a physical order scan anymore, so we expect fairly  
different conditions to hold for the page.  Structuring the code like  
this makes it clearer how _bt_pagedel() cooperates with btvacuumpage()  
and btvacuumscan() (as established in commit b0229f26 and commit  
73a076b0).  
  
Author: Peter Geoghegan  
Reviewed-By: Masahiko Sawada  
Discussion: https://postgr.es/m/CAH2-WzmRGMDWiLMcb+zagG9652PboNN4Gfcq1Gc_wJL6A716MA@mail.gmail.com  

commit   : b68a560f8ebfc7eed679d09facdce5512a38c9c2    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 2 May 2020 11:39:26 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 2 May 2020 11:39:26 -0400    

If the client is compiled with GSSAPI support and tries to start up GSS  
with the server, but the server is not compiled with GSSAPI support, we  
would mistakenly end up falling through to call ProcessStartupPacket  
with secure_done = true, but the client might then try to perform SSL,  
which the backend wouldn't understand and we'd end up failing the  
connection with:  
  
FATAL:  unsupported frontend protocol 1234.5679: server supports 2.0 to 3.0  
  
Fix by arranging to track ssl_done independently from gss_done, instead  
of trying to use the same boolean for both.  
  
Author: Andrew Gierth  
Discussion: https://postgr.es/m/87h82kzwqn.fsf@news-spur.riddles.org.uk  
Backpatch: 12-, where GSSAPI encryption was added.  

commit   : d5d09692ea6b96944d24c44db1451f085b64ba09    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:30:10 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:30:10 +0200    

The extra memset meant pg_stat_reset_slru() always reset all the entries  
even when reset of a single entry was requested, but the timestamp was  
left uninitialized.  
  
Reported-by: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYFe16pjZxQYaTn53mspyM7dgMPYL3DJLjjPw69GMCC2Ow%40mail.gmail.com  

commit   : e685ca63ca4f5d6c9c27499d94fc71d2065b55d9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:26:47 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:26:47 +0200    

This should have been included in 2e08d314ed.  
  
Reported-by: Fujii Masao  
Discussion: https://postgr.es/m/20200119143707.gyinppnigokesjok@development  

commit   : 747134838870b842c5aae673065da7227517e5b5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 2 May 2020 10:33:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 2 May 2020 10:33:10 +0200    

commit   : 60fbb4d762506c352c1af1229288a0753742cd95    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 01:25:00 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 01:25:00 +0200    

Commit de0dc1a847 added code to cost_incremental_sort to handle varno 0.  
Explicitly removing the RelabelType is not really necessary, because the  
pull_varnos handles that just fine, which simplifies the code a bit.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs4_3_D2J5XxOuw68hvn0-gJsw9FXNSGcZka9aTymn9UJ8A%40mail.gmail.com  
Discussion: https://postgr.es/m/20200411214639.GK2228%40telsasoft.com  

commit   : 2e08d314ed07363636a5da65f2a3abf7135f8ba8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 00:36:25 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 00:36:25 +0200    

The "pg_xact" entry was duplicate with "clog" and was added by mistake.  
  
Reported-by: Fujii Masao  
Discussion: https://postgr.es/m/20200119143707.gyinppnigokesjok@development  

commit   : 0da06d9faf9e865c7d16a358a30ebe1a0014a709    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 17:28:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 17:28:00 -0400    

Writing a trailing semicolon in a macro is almost never the right thing,  
because you almost always want to write a semicolon after each macro  
call instead.  (Even if there was some reason to prefer not to, pgindent  
would probably make a hash of code formatted that way; so within PG the  
rule should basically be "don't do it".)  Thus, if we have a semi inside  
the macro, the compiler sees "something;;".  Much of the time the extra  
empty statement is harmless, but it could lead to mysterious syntax  
errors at call sites.  In perhaps an overabundance of neatnik-ism, let's  
run around and get rid of the excess semicolons whereever possible.  
  
The only thing worse than a mysterious syntax error is a mysterious  
syntax error that only happens in the back branches; therefore,  
backpatch these changes where relevant, which is most of them because  
most of these mistakes are old.  (The lack of reported problems shows  
that this is largely a hypothetical issue, but still, it could bite  
us in some future patch.)  
  
John Naylor and Tom Lane  
  
Discussion: https://postgr.es/m/CACPNZCs0qWTqJ2QUSGJ07B7uvAvzMb-KbG2q+oo+J3tsWN5cqw@mail.gmail.com  

commit   : d66935448f41b1e0af11a939b6c5aaa9a619524a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 16:16:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 16:16:28 -0400    

With the usual quota of minor editorial changes.  

commit   : 69cf853fe798c6d590db892d80677e45609e3395    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 12:19:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 12:19:44 -0700    

On further reflection, code comments added by commit b0229f26 slightly  
misrepresented how we determine the oldest bpto.xact for the index.  
btvacuumpage() does not treat the bpto.xact of a page that it put in the  
FSM as a candidate to be the oldest deleted page (the delete-marked page  
that has the oldest bpto.xact XID among all pages encountered).  
  
The definition of a deleted page for the purposes of the bpto.xact  
calculation is different from the definition used by the bulk delete  
statistics.  The bulk delete statistics don't distinguish between pages  
that were deleted by the current VACUUM, pages deleted by a previous  
VACUUM operation but not yet recyclable/reusable, and pages that are  
reusable (though reusable pages are counted separately).  
  
Backpatch: 11-, just like commit b0229f26.  

commit   : 4e21f8b63354323897fa2ab778bfe003c44df75b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 10:03:38 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 10:03:38 -0700    

commit   : 73a076b03f1cf0761329ace55ec3601d47f04075    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 09:51:09 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 09:51:09 -0700    

The logic for determining how many nbtree pages in an index are deleted  
pages sometimes undercounted pages.  Pages that were deleted by the  
current VACUUM operation (as opposed to some previous VACUUM operation  
whose deleted pages have yet to be reused) were sometimes overlooked.  
The final count is exposed to users through VACUUM VERBOSE's "%u index  
pages have been deleted" output.  
  
btvacuumpage() avoided double-counting when _bt_pagedel() deleted more  
than one page by assuming that only one page was deleted, and that the  
additional deleted pages would get picked up during a future call to  
btvacuumpage() by the same VACUUM operation.  _bt_pagedel() can  
legitimately delete pages that the btvacuumscan() scan will not visit  
again, though, so that assumption was slightly faulty.  
  
Fix the accounting by teaching _bt_pagedel() about its caller's  
requirements.  It now only reports on pages that it knows btvacuumscan()  
won't visit again (including the current btvacuumpage() page), so  
everything works out in the end.  
  
This bug has been around forever.  Only backpatch to v11, though, to  
keep _bt_pagedel() is sync on the branches that have today's bugfix  
commit b0229f26da.  Note that this commit changes the signature of  
_bt_pagedel(), just like commit b0229f26da.  
  
Author: Peter Geoghegan  
Reviewed-By: Masahiko Sawada  
Discussion: https://postgr.es/m/CAH2-WzkrXBcMQWAYUJMFTTvzx_r4q=pYSjDe07JnUXhe+OZnJA@mail.gmail.com  
Backpatch: 11-  

commit   : b0229f26da753688af586580707facc29616f97c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 08:39:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 08:39:52 -0700    

Commit 857f9c36cda (which taught nbtree VACUUM to skip a scan of the  
index from btcleanup in situations where it doesn't seem worth it) made  
VACUUM maintain the oldest btpo.xact among all deleted pages for the  
index as a whole.  It failed to handle all the details surrounding pages  
that are deleted by the current VACUUM operation correctly (though pages  
deleted by some previous VACUUM operation were processed correctly).  
  
The most immediate problem was that the special area of the page was  
examined without a buffer pin at one point.  More fundamentally, the  
handling failed to account for the full range of _bt_pagedel()  
behaviors.  For example, _bt_pagedel() sometimes deletes internal pages  
in passing, as part of deleting an entire subtree with btvacuumpage()  
caller's page as the leaf level page.  The original leaf page passed to  
_bt_pagedel() might not be the page that it deletes first in cases where  
deletion can take place.  
  
It's unclear how disruptive this bug may have been, or what symptoms  
users might want to look out for.  The issue was spotted during  
unrelated code review.  
  
To fix, push down the logic for maintaining the oldest btpo.xact to  
_bt_pagedel().  btvacuumpage() is now responsible for pages that were  
fully deleted by a previous VACUUM operation, while _bt_pagedel() is now  
responsible for pages that were deleted by the current VACUUM operation  
(this includes half-dead pages from a previous interrupted VACUUM  
operation that become fully deleted in _bt_pagedel()).  Note that  
_bt_pagedel() should never encounter an existing deleted page.  
  
This commit theoretically breaks the ABI of a stable release by changing  
the signature of _bt_pagedel().  However, if any third party extension  
is actually affected by this, then it must already be completely broken  
(since there are numerous assumptions made in _bt_pagedel() that cannot  
be met outside of VACUUM).  It seems highly unlikely that such an  
extension actually exists, in any case.  
  
Author: Peter Geoghegan  
Reviewed-By: Masahiko Sawada  
Discussion: https://postgr.es/m/CAH2-WzkrXBcMQWAYUJMFTTvzx_r4q=pYSjDe07JnUXhe+OZnJA@mail.gmail.com  
Backpatch: 11-, where the "skip full scan" feature was introduced.  

commit   : 3c800ae0b931c85f6ae949bc468fa3e51f9d5716    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 May 2020 11:49:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 May 2020 11:49:52 +0200