PostgreSQL 13.0 (upcoming) commit log

commit   : a645c08838d6d4ae55ac4df57cfd91f0b9e4f812    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 22:38:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 22:38:11 -0400    

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

commit   : 4747655111b0bae6e45729ee4b06156ea6c40a77    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 19:17:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 19:17:05 -0400    

Parallel execution changed the way bloom queries are executed, so update  
the EXPLAIN output, and restructure the docs to be clearer and more  
accurate.  
  
Reported-by: Daniel Westermann  
  
Discussion: https://postgr.es/m/ZR0P278MB0122119FAE78721A694C30C8D2340@ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM  
  
Author: Daniel Westermann and me  
  
Backpatch-through: 9.6  

commit   : d88d8ad28484a745fffe036a4085f4674b3064bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Oct 2020 13:57:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Oct 2020 13:57:46 -0400    

If the old row has any "missing" attributes that are supposed to  
be retrieved from an associated tuple descriptor, the wrong things  
happened because the trigger result is shoved directly into an  
executor slot that lacks the missing-attribute data.  Notably,  
CHECK-constraint verification would incorrectly see those columns  
as NULL, and so would RETURNING-list evaluation.  
  
Band-aid around this by forcibly expanding the tuple before passing  
it to the trigger function.  (IMO it was a fundamental misdesign to  
put the missing-attribute data into tuple constraints, which so  
much of the system considers to be optional.  But we're probably  
stuck with that now, and will have to continue to apply band-aids  
as we find other places with similar issues.)  
  
Back-patch to v12.  v11 would also have the issue, except that  
commit 920311ab1 already applied a similar band-aid.  That forced  
expansion in more cases than seem really necessary, though, so  
this isn't a directly equivalent fix.  
  
Amit Langote, with some cosmetic changes by me  
  
Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org  

commit   : 563973bf066893b9386c1d026433708797361575    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 25 Oct 2020 22:39:00 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 25 Oct 2020 22:39:00 +1300    

Author: Zhijie Hou  
Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local  
Backpatch-through: 12, where the mistake was introduced  

commit   : fd048e0cb5aa45ef67b5b2b0446f4b1b6bdefbf3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Oct 2020 13:12:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Oct 2020 13:12:08 -0400    

We must not set the "done" flag until after we've executed the  
initialization function.  Otherwise, other threads can fall through  
the initial unlocked test before initialization is really complete.  
  
This has been seen to cause rare failures of ecpg's thread/descriptor  
test, and it could presumably cause other sorts of misbehavior in  
threaded ECPG-using applications, since ecpglib relies on  
pthread_once() in several places.  
  
Diagnosis and patch by me, based on investigation by Alexander Lakhin.  
Back-patch to all supported branches (the bug dates to 2007).  
  
Discussion: https://postgr.es/m/16685-d6cd241872c101d3@postgresql.org  

commit   : e4538708d58400c8c0336ebabca0b7bdb72e0ff6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Oct 2020 11:32:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Oct 2020 11:32:33 -0400    

The ExplainCloseGroup arguments for incremental sort usage data  
didn't match the corresponding ExplainOpenGroup.  This only matters  
for XML-format output, which is probably why we'd not noticed.  
  
Daniel Gustafsson, per bug #16683 from Frits Jalvingh  
  
Discussion: https://postgr.es/m/16683-8005033324ad34e9@postgresql.org  

commit   : 96ed2ae9360d9b89f695f00c2b6417c4e4d9fcba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:23:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:23:47 -0400    

DST law changes in Palestine, with a whopping 120 hours' notice.  
Also some historical corrections for Palestine.  

commit   : 0e551533b46069ec3b909ce5159eed51b768ca52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:15:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:15:22 -0400    

There's no functional change at all here, but I'm curious to see  
whether this change successfully shuts up Coverity's warning about  
a useless strcmp(), which appeared with the previous update.  
  
Discussion: http://mm.icann.org/pipermail/tz/2020-October/029370.html  

commit   : 2e4af411075c10c5007eb09bcb67abf7f825572d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Oct 2020 16:18:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Oct 2020 16:18:40 -0400    

psql's \connect claims to be able to re-use previous connection  
parameters, but in fact it only re-uses the database name, user name,  
host name (and possibly hostaddr, depending on version), and port.  
This is problematic for assorted use cases.  Notably, pg_dump[all]  
emits "\connect databasename" commands which we would like to have  
re-use all other parameters.  If such a script is loaded in a psql run  
that initially had "-d connstring" with some non-default parameters,  
those other parameters would be lost, potentially causing connection  
failure.  (Thus, this is the same kind of bug addressed in commits  
a45bc8a4f and 8e5793ab6, although the details are much different.)  
  
To fix, redesign do_connect() so that it pulls out all properties  
of the old PGconn using PQconninfo(), and then replaces individual  
properties in that array.  In the case where we don't wish to re-use  
anything, get libpq's default settings using PQconndefaults() and  
replace entries in that, so that we don't need different code paths  
for the two cases.  
  
This does result in an additional behavioral change for cases where  
the original connection parameters allowed multiple hosts, say  
"psql -h host1,host2", and the \connect request allows re-use of the  
host setting.  Because the previous coding relied on PQhost(), it  
would only permit reconnection to the same host originally selected.  
Although one can think of scenarios where that's a good thing, there  
are others where it is not.  Moreover, that behavior doesn't seem to  
meet the principle of least surprise, nor was it documented; nor is  
it even clear it was intended, since that coding long pre-dates the  
addition of multi-host support to libpq.  Hence, this patch is content  
to drop it and re-use the host list as given.  
  
Per Peter Eisentraut's comments on bug #16604.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org  

commit   : ddc728d437a08c68638101ef01d742d6f4476675    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Oct 2020 14:37:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Oct 2020 14:37:26 -0300    

Should cause tests to be a bit faster  

commit   : 5f6463a20af183db10d372f16ddeb5690a92aa1b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Oct 2020 19:22:09 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Oct 2020 19:22:09 -0300    

More precisely, correctly handle the ONLY flag indicating not to  
recurse.  This was implemented in 86f575948c77 by recursing in  
trigger.c, but that's the wrong place; use ATSimpleRecursion instead,  
which behaves properly.  However, because legacy inheritance has never  
recursed in that situation, make sure to do that only for new-style  
partitioning.  
  
I noticed this problem while testing a fix for another bug in the  
vicinity.  
  
This has been wrong all along, so backpatch to 11.  
  
Discussion: https://postgr.es/m/20201016235925.GA29829@alvherre.pgsql  

commit   : 1f53d0b9f45521a85e85b6dcab7c15a7d8b4b973    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Oct 2020 08:52:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Oct 2020 08:52:25 +0200    

In shm_mq_receive(), a huge payload could trigger an unjustified  
"invalid memory alloc request size" error due to the way the buffer  
size is increased.  
  
Add error checks (documenting the upper limit) and avoid the error by  
limiting the allocation size to MaxAllocSize.  
  
Author: Markus Wanner <markus.wanner@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/3bb363e7-ac04-0ac4-9fe8-db1148755bfa%402ndquadrant.com  

commit   : 0a1377760bcdfe837ea5f602a800ea97c668bf16    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 20 Oct 2020 08:31:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 20 Oct 2020 08:31:43 +0530    

In v13, the id for max_parallel_maintenance_workers is defined differently  
as compared to HEAD in docs, so adjust the docs accordingly.  
  
Reported-by: Magnus Hagander and Tom Lane  
Discussion: https://postgr.es/m/CABUevEyAFQZ_jvjY_KtRUWbci4YMyQC1QAMzDQAbLs=XCo3m5Q@mail.gmail.com  

commit   : 1814f915b526d5022b3e2a6ce4ea3bcbe59abe2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 19:03:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 19:03:46 -0400    

When told to process all databases, clusterdb, reindexdb, and vacuumdb  
would reconnect by replacing their --maintenance-db parameter with the  
name of the target database.  If that parameter is a connstring (which  
has been allowed for a long time, though we failed to document that  
before this patch), we'd lose any other options it might specify, for  
example SSL or GSS parameters, possibly resulting in failure to connect.  
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and  
pg_restore.  We can fix it in the same way, by using libpq's rules for  
handling multiple "dbname" parameters to add the target database name  
separately.  I chose to apply the same refactoring approach as in that  
patch, with a struct to handle the command line parameters that need to  
be passed through to connectDatabase.  (Maybe someday we can unify the  
very similar functions here and in pg_dump/pg_restore.)  
  
Per Peter Eisentraut's comments on bug #16604.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org  

commit   : 25378db74fd97f2b10ad44d1f0b2e1f8b0a651f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 14:33:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 14:33:02 -0400    

Since commit 913bbd88d, check_sql_fn_retval() can either insert type  
coercion steps in-line in the Query that produces the SQL function's  
results, or generate a new top-level Query to perform the coercions,  
if modifying the Query's output in-place wouldn't be safe.  However,  
it appears that the latter case has never actually worked, because  
the code tried to inject the new Query back into the query list it was  
passed ... which is not the list that will be used for later processing  
when we execute the SQL function "normally" (without inlining it).  
So we ended up with no coercion happening at run-time, leading to  
wrong results or crashes depending on the datatypes involved.  
  
While the regression tests look like they cover this area well enough,  
through a huge bit of bad luck all the test cases that exercise the  
separate-Query path were checking either inline-able cases (which  
accidentally didn't have the bug) or cases that are no-ops at runtime  
(e.g., varchar to text), so that the failure to perform the coercion  
wasn't obvious.  The fact that the cases that don't work weren't  
allowed at all before v13 probably contributed to not noticing the  
problem sooner, too.  
  
To fix, get rid of the separate "flat" list of Query nodes and instead  
pass the real two-level list that is going to be used later.  I chose  
to make the same change in check_sql_fn_statements(), although that has  
no actual bug, just so that we don't need that data structure at all.  
  
This is an API change, as evidenced by the adjustments needed to  
callers outside functions.c.  That's a bit scary to be doing in a  
released branch, but so far as I can tell from a quick search,  
there are no outside callers of these functions (and they are  
sufficiently specific to our semantics for SQL-language functions that  
it's not apparent why any extension would need to call them).  In any  
case, v13 already changed the API of check_sql_fn_retval() compared to  
prior branches.  
  
Per report from pinker.  Back-patch to v13 where this code came in.  
  
Discussion: https://postgr.es/m/1603050466566-0.post@n3.nabble.com  

commit   : 33acc6bc8795d8e3c2802c78e17e57a75a143904    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:28:54 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:28:54 +0300    

- Misc grammar and punctuation fixes.  
  
- Stylistic cleanup: use spaces between function arguments and JSON fields  
  in examples. For example "foo(a,b)" -> "foo(a, b)". Add semicolon after  
  last END in a few PL/pgSQL examples that were missing them.  
  
- Make sentence that talked about "..." and ".." operators more clear,  
  by avoiding to end the sentence with "..". That makes it look the same  
  as "..."  
  
- Fix syntax description for HAVING: HAVING conditions cannot be repeated  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report. Backpatch to all  
supported versions, to the extent that the patch applies easily.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : 3b5bf7b893fc70d298881cff14f7f0c82d8fee34    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:02:25 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:02:25 +0300    

ALTER SEQUENCE RESTART was made transactional in commit 3d79013b97.  
Backpatch to v10, where that was introduced.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : f0b3d3bb89ae34281edc49de24f865af85671a37    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 18:50:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 18:50:33 +0300    

The output for this query changed in commit 4e2477b7b8. Backport to 9.6  
like that commit.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : d2074daebe1699f0d48fa63f6ba196b6426023ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 11:23:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 11:23:51 -0400    

The Windows documentation insists that every WSAStartup call should  
have a matching WSACleanup call.  However, if that ever had actual  
relevance, it wasn't in this century.  Every remotely-modern Windows  
kernel is capable of cleaning up when a process exits without doing  
that, and must be so to avoid resource leaks in case of a process  
crash.  Moreover, Postgres backends have done WSAStartup without  
WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any  
indication of a problem with that.  
  
libpq's habit of doing WSAStartup during connection start and  
WSACleanup during shutdown is also rather inefficient, since a  
series of non-overlapping connection requests leads to repeated,  
quite expensive DLL unload/reload cycles.  We document a workaround  
for that (having the application call WSAStartup for itself), but  
that's just a kluge.  It's also worth noting that it's far from  
uncommon for applications to exit without doing PQfinish, and  
we've not heard reports of trouble from that either.  
  
However, the real reason for acting on this is that recent  
experiments by Alexander Lakhin show that calling WSACleanup  
during PQfinish is triggering the symptom we occasionally see  
that a process using libpq fails to emit expected stdio output.  
  
Therefore, let's change libpq so that it calls WSAStartup only  
once per process, during the first connection attempt, and never  
calls WSACleanup at all.  
  
While at it, get rid of the only other WSACleanup call in our code  
tree, in pg_dump/parallel.c; that presumably is equally useless.  
  
Back-patch of HEAD commit 7d00a6b2d.  
  
Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru  

commit   : f2f03f9bb10b0749eddea5ad1dd730926421f090    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 17:58:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 17:58:38 +0300    

Commit 028350f619 changed its behavior from "at most" to "exactly", but  
forgot to update the documentation. Backpatch to 9.6.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : d49357c0dc51378aeded51ecb8a290d761ac5b8c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 19 Oct 2020 13:47:09 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 19 Oct 2020 13:47:09 +0200    

Author: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/A05874AE-8771-4C61-A24E-0B6249B8F3C2@yesql.se  

commit   : 33a332bc1cff27c5138fe117ae56b6a6f476f30c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Oct 2020 00:06:40 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Oct 2020 00:06:40 +1300    

In the planner, it was possible, given an extreme enough case containing a  
large number of joins for the number of estimated rows to become infinite.  
This could cause problems in initial_cost_mergejoin() where we perform  
some calculations based on those row estimates.  
  
A problem case, presented by Onder Kalaci showed an Assert failure from  
an Assert checking outerstartsel <= outerendsel.  In his test case this  
was effectively NaN <= Inf, which is false.  The NaN outerstartsel came  
from multiplying the infinite outer_path_rows by 0.0.  
  
In master, this problem was fixed by a90c950fc, however, that fix was too  
invasive for the backbranches.  Here we just relax the Asserts to allow  
them to pass.  The worst that appears to happen from this is that we show  
NaN cost values and infinite row estimates in EXPLAIN.  add_path() would  
have had a hard time doing anything useful with such costs, but that does  
not really matter as if the row estimates were even close to accurate,  
such plan would not complete this side of the heat death of the universe.  
  
Reported-by: Onder Kalaci  
Backpatch: 9.5 to 13  
Discussion: https://postgr.es/m/DM6PR21MB1211FF360183BCA901B27F04D80B0@DM6PR21MB1211.namprd21.prod.outlook.com  

commit   : 99ae342fc4ffe5f9a6ec7f540c5a31fb483b06e6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Oct 2020 09:34:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Oct 2020 09:34:04 +0530    

The rules to choose the number of parallel workers to perform parallel  
vacuum operation were not clearly specified.  
  
Reported-by: Peter Eisentraut  
Author: Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/36aa8aea-61b7-eb3c-263b-648e0cb117b7@2ndquadrant.com  

commit   : 1bd9b2b2369608de7763b3947af2f59292152268    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Oct 2020 09:37:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Oct 2020 09:37:50 +0900    

When allocating a EVP context, it would have been possible to leak some  
memory allocated directly by OpenSSL, that PostgreSQL lost track of if  
the initialization of the context allocated failed.  The cleanup can be  
done with EVP_MD_CTX_destroy().  
  
Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree  
equivalent implementations for older versions since ce9b75d (code  
removed with 9b7cd59a as of 10~).  However, in 9.5 and 9.6, the existing  
code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without  
an equivalent implementation when building the tree with OpenSSL 0.9.6  
or older, meaning that this code is in reality broken with such versions  
since it got introduced in e2838c5.  As we have heard no complains about  
that, it does not seem worth bothering with in 9.5 and 9.6, so I have  
left that out for simplicity.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20201015072212.GC2305@paquier.xyz  
Backpatch-through: 9.5  

commit   : d317fd7570ca69553eef9a9ec1825967c2680927    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Oct 2020 16:02:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Oct 2020 16:02:47 -0400    

Section 8.5.1.4, which defines these literals, made only a vague  
reference to the fact that they might be evaluated too soon to be  
safe in non-interactive contexts.  Provide a more explicit caution  
against misuse.  Also, generalize the wording in the related tip in  
section 9.9.4: while it clearly described this problem, it implied  
(or really, stated outright) that the problem only applies to table  
DEFAULT clauses.  
  
Per gripe from Tijs van Dam.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com  

commit   : 3f26dca76343d2e4aca5e2070875c93057925dca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:53:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:53:33 -0400    

DST law changes in Morocco, Canadian Yukon, Fiji, Macquarie Island,  
Casey Station (Antarctica).  Historical corrections for France,  
Hungary, Monaco.  

commit   : e0cf5e9b226aae3df8ab8df7f5f7c8fe295be24e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:40:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:40:16 -0400    

This changes zic's default output format from "-b fat" to "-b slim".  
We were already using "slim" in v13/HEAD, so those branches drop  
the explicit -b switch in the Makefiles.  Instead, add an explicit  
"-b fat" in v12 and before, so that we don't change the output file  
format in those branches.  (This is perhaps excessively conservative,  
but we decided not to do so in a12079109, and I'll stick with that.)  
  
Other non-cosmetic changes are to drop support for zic's long-obsolete  
"-y" switch, and to ensure that strftime() does not change errno  
unless it fails.  
  
As usual with tzcode changes, back-patch to all supported branches.  

commit   : 3d338a46a4c342fa1a4e276e0c84532141f4264b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:59:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:59:13 -0400    

In theory, the second px_find_digest call in px_crypt_md5 could fail  
even though the first one succeeded, since resource allocation is  
required.  Don't skip testing for a failure.  (If one did happen,  
the likely result would be a crash rather than clean recovery from  
an OOM failure.)  
  
The code's been like this all along, so back-patch to all supported  
branches.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/AA8D6FE9-4AB2-41B4-98CB-AE64BA668C03@yesql.se  

commit   : 2cde0fd6fcaf70a8cf59972c36e86c00cc97e90c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:36:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:36:34 -0400    

Commit a97e85f2b caused "exceed the available area" warnings in PDF  
builds.  Fine-tune colwidth values to avoid that.  
  
Back-patch to 9.6, like the prior patch.  (This is of dubious value  
before v13, since we were far from free of such warnings in older  
branches.  But we might as well keep the SGML looking the same in all  
branches.)  
  
Per buildfarm.  

commit   : efc9a8e9800cc04ff7460c3c78f9dc2120f3aea6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 17:38:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 17:38:00 -0700    

Unfortunately in LLVM 3.9 LLVMGetAttributeCountAtIndex(func, index)  
crashes when called with an index that has 0 attributes. Since there's  
no way to work around this in the C API, add a small C++ wrapper doing  
so.  
  
The only reason this didn't fail before 72559438f92 is that there  
always are function attributes...  
  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20201016001254.w2nfj7gd74jmb5in@alap3.anarazel.de  
Backpatch: 11-, like 72559438f92  

commit   : 79fe23465d56e7a3e649fd95bdb4e8b0af27a376    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 20:37:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 20:37:20 -0400    

This commit required support for inline variable definition, which is  
not a requirement.  
  
RELEASE NOTE AUTHOR:  the author of commit 3c0471b5fd  
(pg_upgrade/tablespaces) was Justin Pryzby, not me.  
  
Reported-by: Andres Freund  
  
Discussion: https://postgr.es/m/20201016001959.h24fkywfubkv2pc5@alap3.anarazel.de  
  
Backpatch-through: 9.5  

commit   : 59cfff65b10036b637a3f6e50d8f654e855d3b69    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 19:33:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 19:33:36 -0400    

Previously, if pg_upgrade failed, and the user recreated the cluster but  
did not remove the new cluster tablespace directory, a later pg_upgrade  
would fail since the new tablespace directory would already exists.  
This adds error reporting for this during check.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20200925005531.GJ23631@telsasoft.com  
  
Backpatch-through: 9.5  

commit   : ae3e75abab222519aef90eb130d93c1ea745ac2e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 13:39:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 13:39:41 -0700    

Previously we only copied the function attributes. That caused problems at  
least on s390x: Because we didn't copy the 'zeroext' attribute for  
ExecAggTransReparent()'s *IsNull parameters, expressions invoking it didn't  
ensure that the upper bytes of the registers were zeroed. In the - relatively  
rare - cases where not, ExecAggTransReparent() wrongly ended up in the  
newValueIsNull branch due to the register not being zero. Subsequently causing  
a crash.  
  
It's quite possible that this would cause problems on other platforms, and in  
other places than just ExecAggTransReparent() on s390x.  
  
Thanks to Christoph (and the Debian project) for providing me with access to a  
s390x machine, allowing me to debug this.  
  
Reported-By: Christoph Berg  
Author: Andres Freund  
Discussion: https://postgr.es/m/20201015083246.kie5726xerdt3ael@alap3.anarazel.de  
Backpatch: 11-, where JIT was added  

commit   : 264e517e68190767de7cd50734956db02c6dbef1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 15:15:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 15:15:29 -0400    

Previously it wasn't clear exactly what each of the synchronous_commit  
modes accomplished.  This clarifies that, and adds a table describing it.  
Only backpatched through 9.6 since 9.5 doesn't have all the options.  
  
Reported-by: kghost0@gmail.com  
  
Discussion: https://postgr.es/m/159741195522.14321.13812604195366728976@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 9f783aea669f56c2e7c875ee1391949f234a2257    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Oct 2020 09:48:36 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Oct 2020 09:48:36 -0300    

Rather than looking for tablesync workers, it is more reliable to see  
the sync state of the tables.  
  
Per note from Amit Kapila.  
Discussion: https://postgr.es/m/CAA4eK1JSSD7FVwq+_rOme86jUZTQFzjsNU06hQ4-LiRt1xFmSg@mail.gmail.com  

commit   : 47522ee00ddbe77280e4c063605b443ec1de3881    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 18:23:30 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 18:23:30 +1300    

While registering for postmaster exit events, we have to handle a couple  
of edge cases where the postmaster is already gone.  Commit 815c2f09  
missed one: EACCES must surely imply that PostmasterPid no longer  
belongs to our postmaster process (or alternatively an unexpected  
permissions model has been imposed on us).  Like ESRCH, this should be  
treated as a WL_POSTMASTER_DEATH event, rather than being raised with  
ereport().  
  
No known problems reported in the wild.  Per code review from Tom Lane.  
Back-patch to 13.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3624029.1602701929%40sss.pgh.pa.us  

commit   : 53c07dbbf36855a4f5b11654106654b18e00ee15    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 15 Oct 2020 11:04:07 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 15 Oct 2020 11:04:07 +0900    

Previously it was documented that toast_tuple_target affected column  
marked as only External or Extended. But this description is not correct  
and toast_tuple_target affects also column marked as Main.  
  
Back-patch to v11 where toast_tuple_target reloption was introduced.  
  
Author: Shinya Okano  
Reviewed-by: Tatsuhito Kasahara, Fujii Masao  
Discussion: https://postgr.es/m/93f46e311a67422e89e770d236059817@oss.nttdata.com  

commit   : 72e43fc313e93c95704c574bcf98805805668063    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Oct 2020 20:12:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Oct 2020 20:12:26 -0300    

I removed the duplicate command tags for START_REPLICATION inadvertently  
in commit 07082b08cc5d, but the replication protocol requires them.  The  
fact that the replication protocol was broken was not noticed because  
all our test cases use an optimized code path that exits early, failing  
to verify that the behavior is correct for non-optimized cases.  Put  
them back.  
  
Also document this protocol quirk.  
  
Add a test case that shows the failure.  It might still succeed even  
without the patch when run on a fast enough server, but it suffices to  
show the bug in enough cases that it would be noticed in buildfarm.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Henry Hinze <henry.hinze@gmail.com>  
Reviewed-by: Petr Jelínek <petr.jelinek@2ndquadrant.com>  
Discussion: https://postgr.es/m/16643-eaadeb2a1a58d28c@postgresql.org  

commit   : e0950135ae5d50140feecc7bc87c018019c6e406    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 11:31:20 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 11:31:20 +1300    

If WaitEventSetWait() reports that the postmaster has gone away, later  
calls to WaitEventSetWait() should continue to report that.  Otherwise  
further waits that occur in the proc_exit() path after we already  
noticed the postmaster's demise could block forever.  
  
Back-patch to 13, where the kqueue support landed.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3624029.1602701929%40sss.pgh.pa.us  

commit   : 855b6f287100f3eab24df0a83998db251ac4fd09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Oct 2020 17:44:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Oct 2020 17:44:56 -0400    

Our infinite_recurse() test to verify sane stack-overrun behavior  
is affected by a bug of the Linux kernel on PPC64: it will get SIGSEGV  
if it receives a signal when the stack depth is (a) over 1MB and  
(b) within a few kB of filling the current physical stack allocation.  
See https://bugzilla.kernel.org/show_bug.cgi?id=205183.  
  
Since this test is a bit time-consuming and we run it in parallel with  
test scripts that do a lot of DDL, it can be expected to get an sinval  
catchup interrupt at some point, leading to failure if the timing is  
wrong.  This has caused more than 100 buildfarm failures over the  
past year or so.  
  
While a fix exists for the kernel bug, it might be years before that  
propagates into all production kernels, particularly in some of the  
older distros we have in the buildfarm.  For now, let's just back off  
and not run this test on Linux PPC64; that loses nothing in test  
coverage so far as our own code is concerned.  
  
To do that, split this test into a new script infinite_recurse.sql  
and skip the test when the platform name is powerpc64...-linux-gnu.  
  
Back-patch to v12.  Branches before that have not been seen to get  
this failure.  No doubt that's because the "errors" test was not  
run in parallel with other tests before commit 798070ec0, greatly  
reducing the odds of an sinval catchup being necessary.  
  
I also back-patched 3c8553547 into v12, just so the new regression  
script would look the same in all branches having it.  
  
Discussion: https://postgr.es/m/3479046.1602607848@sss.pgh.pa.us  
Discussion: https://postgr.es/m/20190723162703.GM22387%40telsasoft.com  

commit   : 962ab473ec3d4c1090ba75fa677167126956c1ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 18:01:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 18:01:34 -0400    

gistRelocateBuildBuffersOnSplit did not get the memo about which  
attribute count to use.  This could lead to a crash if there were  
included columns and buffering build was chosen.  (Because there  
are random page-split decisions elsewhere in GiST index build,  
the crashes are not entirely deterministic.)  
  
Back-patch to v12 where GiST gained support for included columns.  
  
Pavel Borisov  
  
Discussion: https://postgr.es/m/CALT9ZEECCV5m7wvxg46PC-7x-EybUmnpupBGhSFMoAAay+r6HQ@mail.gmail.com  

commit   : 9343bfefa4514e5623cfc2610c44e3d93d776e64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 13:31:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 13:31:24 -0400    

The prohibitValueChange code paths in set_config_option(), which  
are executed whenever we re-read a PGC_POSTMASTER variable from  
postgresql.conf, neglected to free anything before exiting.  Thus  
we'd leak the proposed new value of a PGC_STRING variable, as noted  
by BoChen in bug #16666.  For all variable types, if the check hook  
creates an "extra" chunk, we'd also leak that.  
  
These are malloc not palloc chunks, so there is no mechanism for  
recovering the leaks before process exit.  Fortunately, the values  
are typically not very large, meaning you'd have to go through an  
awful lot of SIGHUP configuration-reload cycles to make the leakage  
amount to anything.  Still, for a long-lived postmaster process it  
could potentially be a problem.  
  
Oversight in commit 2594cf0e8.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16666-2c41a4eec61b03e1@postgresql.org  

commit   : 5efa788e1d070dd14cb94a8e087184dda36dc3ea    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    

The implementation uses smaller code when the "expected" operand is a  
small constant, but the implementation needlessly defined the set of  
acceptable constants more narrowly than the ABI does.  Core PostgreSQL  
and PGXN don't use the constant path at all, so this is future-proofing.  
Back-patch to v13, where commit 30ee5d17c20dbb282a9952b3048d6ad52d56c371  
introduced this code.  
  
Reviewed by Tom Lane.  Reported by Christoph Berg.  
  
Discussion: https://postgr.es/m/20201009092825.GD889580@msg.df7cb.de  

commit   : d41cb63ff4d114d856837fbf61ba2872c5076ac2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    

While xlc defines __64BIT__, gcc does not.  Due to this oversight in  
commit 30ee5d17c20dbb282a9952b3048d6ad52d56c371, gcc builds continued  
implementing 64-bit atomics by way of intrinsics.  Back-patch to v13,  
where that commit first appeared.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20201011051043.GA1724101@rfd.leadboat.com  

commit   : dc14aa038e20d0287a569c36498da9469fe9d4e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 18:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 18:41:39 -0400    

It appears that commit cf63c641c, which intended to prevent  
misoptimization of the result-building step in makeOrderedSetArgs,  
didn't go far enough: buildfarm member hornet's version of xlc  
is now optimizing back to the old, broken behavior in which  
list_length(directargs) is fetched only after list_concat() has  
changed that value.  I'm not entirely convinced whether that's  
an undeniable compiler bug or whether it can be justified by a  
sufficiently aggressive interpretation of C sequence points.  
So let's just change the code to make it harder to misinterpret.  
  
Back-patch to all supported versions, just in case.  
  
Discussion: https://postgr.es/m/1830491.1601944935@sss.pgh.pa.us  

commit   : 5ed20a689e3d5d47a70b971f388e9da2a996dea9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 17:10:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 17:10:26 -0400    

The date-vs-timestamp, date-vs-timestamptz, and timestamp-vs-timestamptz  
comparators all worked by promoting the first type to the second and  
then doing a simple same-type comparison.  This works fine, except  
when the conversion result is out of range, in which case we throw an  
entirely avoidable error.  The sources of such failures are  
(a) type date can represent dates much farther in the future than  
the timestamp types can;  
(b) timezone rotation might cause a just-in-range timestamp value to  
become a just-out-of-range timestamptz value.  
  
Up to now we just ignored these corner-case issues, but now we have  
an actual user complaint (bug #16657 from Huss EL-Sheikh), so let's  
do something about it.  
  
It turns out that commit 52ad1e659 already built all the necessary  
infrastructure to support error-free comparisons, but neglected to  
actually use it in the main-line code paths.  Fix that, do a little  
bit of code style review, and remove the now-duplicate logic in  
jsonpath_exec.c.  
  
Back-patch to v13 where 52ad1e659 came in.  We could take this back  
further by back-patching said infrastructure, but given the small  
number of complaints so far, I don't feel a great need to.  
  
Discussion: https://postgr.es/m/16657-cde2f876d8cc7971@postgresql.org  

commit   : 2ea624b4b51caa0e82a4084d2499f5fc72cbe418    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 12:50:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 12:50:54 -0400    

Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly  
set the table's "interesting" flag when deciding to dump the data of  
an extension config table, it was not correct to clear that flag  
if we concluded we shouldn't dump the data.  This led to the crash  
reported in bug #16655, because in fact we'll traverse dumpTableSchema  
anyway for all extension tables (to see if they have user-added  
seclabels or RLS policies).  
  
The right thing to do is to force "interesting" true in makeTableDataInfo,  
and otherwise leave the flag alone.  (Doing it there is more future-proof  
in case additional calls are added, and it also avoids setting the flag  
unnecessarily if that function decides the table is non-dumpable.)  
  
This investigation also showed that while only the --inserts code path  
had an obvious failure in the case considered by 3eb3d3e78, the COPY  
code path also has a problem with not having loaded table subsidiary  
data.  That causes fmtCopyColumnList to silently return an empty string  
instead of the correct column list.  That accidentally mostly works,  
which perhaps is why we didn't notice this before.  It would only fail  
if the restore column order is different from the dump column order,  
which only happens in weird inheritance cases, so it's not surprising  
nobody had hit the case with an extension config table.  Nonetheless,  
it's a bug, and it goes a long way back, not just to v12 where the  
--inserts code path started to have a problem with this.  
  
In hopes of catching such cases a bit sooner in future, add some  
Asserts that "interesting" has been set in both dumpTableData and  
dumpTableSchema.  Adjust the test case added by 3eb3d3e78 so that it  
checks the COPY rather than INSERT form of that bug, allowing it to  
detect the longer-standing symptom.  
  
Per bug #16655 from Cameron Daniel.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/16655-5c92d6b3a9438137@postgresql.org  
Discussion: https://postgr.es/m/18048b44-3414-b983-8c7c-9165b177900d@2ndQuadrant.com  

commit   : be304cf9f5665e1c19d02f1144d4f0affa0034c7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 14:31:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 14:31:22 -0400    

We only support upgrading from >= 8.4 so no need for this code or tests.  
  
Reported-by: Magnus Hagander  
  
Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493MJt-x6sppbUxA@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : 2cb4b8e0ae16e7091a7bd5cf94f21d2719b108e0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 12:12:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 12:12:09 -0400    

This makes checking for older major versions more consistent.  
  
Backpatch-through: 9.5  

commit   : b7f166efade004ba293f52b672961ae064d202cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Oct 2020 11:43:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Oct 2020 11:43:53 -0400    

This patch prevents crashes or wrong plans when partition-wise joins  
are considered during GEQO planning, as a consequence of the  
EquivalenceClass data structures becoming corrupt after a GEQO  
context reset.  
  
A remaining problem is that successive GEQO cycles will make multiple  
copies of the required EC members, since add_child_join_rel_equivalences  
has no idea that such members might exist already.  For now we'll just  
live with that.  The lack of field complaints of crashes suggests that  
this is a mighty little-used situation.  
  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/1683100.1601860653@sss.pgh.pa.us  

commit   : 96423711918f44600c9ef91f4342984624f053bb    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:50:03 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:50:03 +0200    

Ian submitted an updated patch just as I was pushing the previous one,  
so use this newer wording instead.  
  
Author: Ian Barwick  

commit   : 0639f9b8c251d152695a968c3978edca844c3cad    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:46:36 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:46:36 +0200    

The behavior is different for different types of objects, so make that  
more clear.  
  
Author: Ian Barwick  

commit   : e9703ce6e7ac263e0e5a6fca9266e09284195dc7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:27:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:27:33 -0400    

Previously it was unclear exactly how ROWS FROM behaved and how to cast  
the data types of columns returned by FROM functions.  Also document  
that only non-OUT record functions can have their columns cast to data  
types.  
  
Reported-by: guyren@gmail.com  
  
Discussion: https://postgr.es/m/158638264419.662.2482095087061084020@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : ef40ab77d5143385d15dcfd08c5a7d66719ef7a3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:07:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:07:15 -0400    

This is the first paragraph change of master-only commit 253f1025da.  
  
Backpatch-through: PG 12-13 only  

commit   : d1c23d726d50e10179235b6cee6b34543a879b19    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 13:15:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 13:15:39 -0400    

get_eclass_for_sort_expr() computes expr_relids and nullable_relids  
early on, even though they won't be needed unless we make a new  
EquivalenceClass, which we often don't.  Aside from the probably-minor  
inefficiency, there's a memory management problem: these bitmapsets will  
be built in the caller's context, leading to dangling pointers if that  
is shorter-lived than root->planner_cxt.  This would be a live bug if  
get_eclass_for_sort_expr() could be called with create_it = true during  
GEQO join planning.  So far as I can find, the core code never does  
that, but it's hard to be sure that no extensions do, especially since  
the comments make it clear that that's supposed to be a supported case.  
Fix by not computing these values until we've switched into planner_cxt  
to build the new EquivalenceClass.  
  
generate_join_implied_equalities() uses inner_rel->relids to look up  
relevant eclasses, but it ought to be using nominal_inner_relids.  
This is presently harmless because a child RelOptInfo will always have  
exactly the same eclass_indexes as its topmost parent; but that might  
not be true forever, and anyway it makes the code confusing.  
  
The first of these is old (introduced by me in f3b3b8d5b), so back-patch  
to all supported branches.  The second only dates to v13, but we might  
as well back-patch it to keep the code looking similar across branches.  
  
Discussion: https://postgr.es/m/1508010.1601832581@sss.pgh.pa.us  

commit   : 019eb962fb869b55ac8db173c4424a5de6cfee61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 11:42:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 11:42:33 -0400    

The descriptions of make_interval() and pg_options_to_table()  
were randomly different from the reality embedded in pg_proc.  
  
(These are not all the discrepancies I found in a quick search,  
but the others perhaps require more discussion, since there's  
at least a case to be made for changing pg_proc not the docs.)  
  
make_interval issue noted by Thomas Kellerer.  
  
Discussion: https://postgr.es/m/7b154ef0-9f22-90b9-7734-4bf23686695b@gmx.net  

commit   : e01e339560ea7d8716924f3b014e902ef646729c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2020 20:45:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2020 20:45:06 -0400    

I noticed while trying to run the regression tests under a low  
geqo_threshold that one query on information_schema.columns had  
unstable (as in, variable from one run to the next) output order.  
This is pretty unsurprising given the complexity of the underlying  
plan.  Interestingly, of this test's three nigh-identical queries on  
information_schema.columns, the other two already had ORDER BY clauses  
guaranteeing stable output.  Let's make this one look the same.  
  
Back-patch to v10 where this test was added.  We've not heard field  
reports of the test failing, but this experience shows that it can  
happen when testing under even slightly unusual conditions.  

commit   : d2c9ef1c80b6adfbeee49507445c1b2eb3d08783    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 22:19:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 22:19:31 -0400    

Reported-by: Alexander Lakhin  
  
Discussion: https://postgr.es/m/16486-b9c93d71c02c4907@postgresql.org  
  
Backpatch-through: 9.5  

commit   : 566c6d4fd8bb76a761ae144a33514428ab048880    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 21:39:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 21:39:33 -0400    

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

commit   : 6731f1ef19fdf912cfbf2686a4d344a022b7704b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2020 10:59:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2020 10:59:20 -0400    

Commit 151c0c5f7 neglected the possibility that a TEMP_CONFIG file  
would explicitly set max_wal_senders=0; as indeed buildfarm member  
thorntail does, so that it can test wal_level=minimal in other test  
suites.  Hence, rather than assuming that max_wal_senders=10 will  
prevail if we say nothing, set it explicitly.  
  
Set max_replication_slots=10 explicitly too, just to be safe.  
  
Back-patch to v10, like the previous patch.  
  
Discussion: https://postgr.es/m/723911.1601417626@sss.pgh.pa.us  

commit   : 3c85489ec9cd08ce43976afa75f613f939635cb9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Oct 2020 11:48:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Oct 2020 11:48:48 +0300    

This has been wrong ever since the support for multi-dimensional  
arrays as PL/python function arguments and return values was  
introduced in commit 94aceed317.  
  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/61647b8e-961c-0362-d5d3-c8a18f4a7ec6%40iki.fi  

commit   : 49433744ff65d8d799572cd616aecaf3074bcda5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 30 Sep 2020 18:25:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 30 Sep 2020 18:25:22 -0300    

The error message about columns in the primary key not including all of  
the partition key was unclear; reword it.  
  
Backpatch all the way to pg11, where it appeared.  
  
Reported-by: Nagaraj Raj <nagaraj.sf@yahoo.com>  
Discussion: https://postgr.es/m/64062533.78364.1601415362244@mail.yahoo.com  

commit   : 99fd38c02299acdc2282ac2dea8057a7a8f5f807    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Sep 2020 15:40:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Sep 2020 15:40:23 -0400    

Previously, a conversion such as  
	to_date('-44-02-01','YYYY-MM-DD')  
would result in '0045-02-01 BC', as the code attempted to interpret  
the negative year as BC, but failed to apply the correction needed  
for our internal handling of BC years.  Fix the off-by-one problem.  
  
Also, arrange for the combination of a negative year and an  
explicit "BC" marker to cancel out and produce AD.  This is how  
the negative-century case works, so it seems sane to do likewise.  
  
Continue to read "year 0000" as 1 BC.  Oracle would throw an error,  
but we've accepted that case for a long time so I'm hesitant to  
change it in a back-patch.  
  
Per bug #16419 from Saeed Hubaishan.  Back-patch to all supported  
branches.  
  
Dar Alathar-Yemen and Tom Lane  
  
Discussion: https://postgr.es/m/16419-d8d9db0a7553f01b@postgresql.org  

commit   : db8e60b82d6af88a4c8e1f9572abd5f5d84906b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 20:02:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 20:02:58 -0400    

PostgresNode.pm set "max_wal_senders = 5" for replication testing,  
but this seems to be slightly too low for our current test suite.  
Slower buildfarm members frequently report "number of requested standby  
connections exceeds max_wal_senders" failures, due to old walsenders  
not exiting instantaneously.  Usually, the test does not fail overall  
because of automatic walreceiver restart, but sometimes the failure  
becomes visible; and in any case such retries slow down the test.  
  
That value came in with commit 89ac7004d, but was soon obsoleted by  
f6d6d2920, which raised the built-in default from zero to 10; so that  
PostgresNode.pm is actually setting it to less than the conservative  
built-in default.  That seems pretty pointless, so let's remove the  
special setting and let the default prevail, in hopes of making  
the TAP tests more robust.  
  
Likewise, the setting "max_replication_slots = 5" is obsolete and  
can be removed.  
  
While here, reverse-engineer a comment about why we're choosing  
less-than-default values for some other settings.  
  
(Note: before v12, max_wal_senders counted against max_connections  
so that the latter setting also needs some fiddling with.)  
  
Back-patch to v10 where the subscription tests were added.  
It's likely that the older branches aren't pushing the boundaries  
of max_wal_senders, but I'm disinclined to spend time trying to  
figure out exactly when it started to be a problem.  
  
Discussion: https://postgr.es/m/723911.1601417626@sss.pgh.pa.us  

commit   : 5610ffaf00a53877ec973881b9b0b7a1acad689a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Sep 2020 13:03:01 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Sep 2020 13:03:01 +1300    

Explicitly mention that primary key constraints are also included in the  
limitation that the constraint columns must be a superset of the partition key  
columns.  
  
Wording suggestion from Tom Lane.  
  
Discussion: https://postgr.es/m/64062533.78364.1601415362244@mail.yahoo.com  
Backpatch-through: 11, where unique constraints on partitioned tables were added  

commit   : f0e4ec74e452f55922b52f50da4ba4834771a268    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 11:18:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 11:18:30 -0400    

When executing a CALL or DO in a non-atomic context (i.e., not inside  
a function or query), plpgsql creates a new plan each time through,  
as a rather hacky solution to some resource management issues.  But  
it failed to free this plan until exit of the current procedure or DO  
block, resulting in serious memory bloat in procedures that called  
other procedures many times.  Fix by remembering to free the plan,  
and by being more honest about restoring the previous state (otherwise,  
recursive procedure calls have a problem).  
  
There was also a smaller leak associated with recalculation of the  
"target" list of output variables.  Fix that by using the statement-  
lifespan context to hold non-permanent values.  
  
Back-patch to v11 where procedures were introduced.  
  
Pavel Stehule and Tom Lane  
  
Discussion: https://postgr.es/m/CAFj8pRDiiU1dqym+_P4_GuTWm76knJu7z9opWayBJTC0nQGUUA@mail.gmail.com  

commit   : 651bdbc811652638e1205440c3181a18feb8f967    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:41:46 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:41:46 +0300    

The SQL standard doesn't require jsonpath .datetime() method to support the  
ISO 8601 format.  But our to_json[b]() functions convert timestamps to text in  
the ISO 8601 format in the sake of compatibility with javascript.  So, we add  
support of the  ISO 8601 to the jsonpath .datetime() in the sake compatibility  
with to_json[b]().  
  
The standard mode of datetime parsing currently supports just template patterns  
and separators in the format string.  In order to implement ISO 8601, we have to  
add support of the format string double quotes to the standard parsing mode.  
  
Discussion: https://postgr.es/m/94321be0-cc96-1a81-b6df-796f437f7c66%40postgrespro.ru  
Author: Nikita Glukhov, revised by me  
Backpatch-through: 13  

commit   : abcc0ab163003d2ab7c82a1e810ba257ebbec15f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:00:22 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:00:22 +0300    

bffe1bd684 has introduced jsonpath .datetime() method, but default formats  
for time and timestamp contain excess space between time and timezone.  This  
commit removes this excess space making behavior of .datetime() method  
standard-compliant.  
  
Discussion: https://postgr.es/m/94321be0-cc96-1a81-b6df-796f437f7c66%40postgrespro.ru  
Author: Nikita Glukhov  
Backpatch-through: 13  

commit   : 059caf36c3074afd998b6e5f36ea9da460dcaee8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 29 Sep 2020 16:21:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 29 Sep 2020 16:21:46 +0900    

Previously the standby server didn't archive timeline history files  
streamed from the primary even when archive_mode is set to "always",  
while it archives the streamed WAL files. This could cause the PITR to  
fail because there was no required timeline history file in the archive.  
The cause of this issue was that walreceiver didn't mark those files as  
ready for archiving.  
  
This commit makes walreceiver mark those streamed timeline history  
files as ready for archiving if archive_mode=always. Then the archiver  
process archives the marked timeline history files.  
  
Back-patch to all supported versions.  
  
Reported-by: Grigory Smolkin  
Author: Grigory Smolkin, Fujii Masao  
Reviewed-by: David Zhang, Anastasia Lubennikova  
Discussion: https://postgr.es/m/54b059d4-2b48-13a4-6f43-95a087c92367@postgrespro.ru  

commit   : 1aedaba78aa8617b24b7a703abd1359f9d78f62a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Sep 2020 14:16:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Sep 2020 14:16:12 +0900    

This addresses a couple of issues with the so-said subject:  
- Report the correct parent relation with the index actually being  
rebuilt or validated.  Previously, the command status remained set to  
the last index created for the progress of the index build and  
validation, which would be incorrect when working on a table that has  
more than one index.  
- Use the correct phase when waiting before the drop of the old  
indexes.  Previously, this was reported with the same status as when  
waiting before the old indexes are marked as dead.  
  
Author: Matthias van de Meent, Michael Paquier  
Discussion: https://postgr.es/m/CAEze2WhqFgcwe1_tv=sFYhLWV2AdpfukumotJ6JNcAOQs3jufg@mail.gmail.com  
Backpatch-through: 12  

commit   : 67b2ceea01576933a1dc881ef6a65403e03483ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 20:32:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 20:32:53 -0400    

We have a dozen or so places that need to iterate over all but the  
first cell of a List.  Prior to v13 this was typically written as  
	for_each_cell(lc, lnext(list_head(list)))  
Commit 1cff1b95a changed these to  
	for_each_cell(lc, list, list_second_cell(list))  
This patch introduces a new macro for_each_from() which expresses  
the start point as a list index, allowing these to be written as  
	for_each_from(lc, list, 1)  
This is marginally more efficient, since ForEachState.i can be  
initialized directly instead of backing into it from a ListCell  
address.  It also seems clearer and less typo-prone.  
  
Some of the remaining uses of for_each_cell() look like they could  
profitably be changed to for_each_from(), but here I confined myself  
to changing uses of list_second_cell().  
  
Also, fix for_each_cell_setup() and for_both_cell_setup() to  
const-ify their arguments; that's a simple oversight in 1cff1b95a.  
  
Back-patch into v13, on the grounds that (1) the const-ification  
is a minor bug fix, and (2) it's better for back-patching purposes  
if we only have two ways to write these loops rather than three.  
  
In HEAD, also remove list_third_cell() and list_fourth_cell(),  
which were also introduced in 1cff1b95a, and are unused as of  
cc99baa43.  It seems unlikely that any third-party code would  
have started to use them already; anyone who has can be directed  
to list_nth_cell instead.  
  
Discussion: https://postgr.es/m/CAApHDvpo1zj9KhEpU2cCRZfSM3Q6XGdhzuAS2v79PH7WJBkYVA@mail.gmail.com  

commit   : 61a78c71a656593bf4121e624348a990ba5b91da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 14:12:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 14:12:38 -0400    

Failure to do this can result in errors during evaluation of  
the bound expression, as illustrated by the new regression test.  
  
Back-patch to v12 where the ability for partition bounds to be  
expressions was added.  
  
Discussion: https://postgr.es/m/CAJV4CdrZ5mKuaEsRSbLf2URQ3h6iMtKD=hik8MaF5WwdmC9uZw@mail.gmail.com  

commit   : f7873900f353ff210ef2ef2aa587e39196b8bf5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Sep 2020 16:04:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Sep 2020 16:04:06 -0400    

This function leaked some memory while loading qual clauses for  
an RLS policy.  While ordinarily negligible, that could build up  
in some repeated-reload cases, as reported by Konstantin Knizhnik.  
We can improve matters by borrowing the coding long used in  
RelationBuildRuleLock: build stringToNode's result directly in  
the target context, and remember to explicitly pfree the  
input string.  
  
This patch by no means completely guarantees zero leaks within  
this function, since we have no real guarantee that the catalog-  
reading subroutines it calls don't leak anything.  However,  
practical tests suggest that this is enough to resolve the issue.  
In any case, any remaining leaks are similar to those risked by  
RelationBuildRuleLock and other relcache-loading subroutines.  
If we need to fix them, we should adopt a more global approach  
such as that used by the RECOVER_RELATION_BUILD_MEMORY hack.  
  
While here, let's remove the need for an expensive PG_TRY block by  
using MemoryContextSetParent to reparent an initially-short-lived  
context for the RLS data.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/21356c12-8917-8249-b35f-1c447231922b@postgrespro.ru  

commit   : cb8885ac49697eb2568c4764ae3565cea52be92b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2020 18:19:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2020 18:19:38 -0400    

Parallel pg_dump failed if its -d parameter was a connection string  
containing any essential information other than host, port, or username.  
The same was true for pg_restore with --create.  
  
The reason is that these scenarios failed to preserve the connection  
string from the command line; the code felt free to replace that with  
just the database name when reconnecting from a pg_dump parallel worker  
or after creating the target database.  By chance, parallel pg_restore  
did not suffer this defect, as long as you didn't say --create.  
  
In practice it seems that the error would be obvious only if the  
connstring included essential, non-default SSL or GSS parameters.  
This may explain why it took us so long to notice.  (It also makes  
it very difficult to craft a regression test case illustrating the  
problem, since the test would fail in builds without those options.)  
  
Fix by refactoring so that ConnectDatabase always receives all the  
relevant options directly from the command line, rather than  
reconstructed values.  Inject a different database name, when necessary,  
by relying on libpq's rules for handling multiple "dbname" parameters.  
  
While here, let's get rid of the essentially duplicate _connectDB  
function, as well as some obsolete nearby cruft.  
  
Per bug #16604 from Zsolt Ero.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org  

commit   : 052014a2066827cb96dbc9ef464ce44293585601    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 24 Sep 2020 09:26:09 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 24 Sep 2020 09:26:09 +1200    

Harmonize behavior by moving reponsibility for fsyncing directories down  
into slru.c.  In 10 and later, only the multixact directories were  
missed (see commit 1b02be21), and in older branches all SLRUs were  
missed.  
  
Back-patch to all supported releases.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CA%2BhUKGLtsTUOScnNoSMZ-2ZLv%2BwGh01J6kAo_DM8mTRq1sKdSQ%40mail.gmail.com  

commit   : 569f6a89a9153ee05ab429522e835b00b11ad7f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Sep 2020 11:36:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Sep 2020 11:36:13 -0400    

tsearch_readline() saves the string pointer it returns to the caller  
for possible use in the associated error context callback.  However,  
the caller will usually pfree that string sometime before it next  
calls tsearch_readline(), so that there is a window where an ereport  
will try to print an already-freed string.  
  
The built-in users of tsearch_readline() happen to all do that pfree  
at the bottoms of their loops, so that the window is effectively  
empty for them.  However, this is not documented as a requirement,  
and contrib/dict_xsyn doesn't do it like that, so it seems likely  
that third-party dictionaries might have live bugs here.  
  
The practical consequences of this seem pretty limited in any case,  
since production builds wouldn't clobber the freed string immediately,  
besides which you'd not expect syntax errors in dictionary files  
being used in production.  Still, it's clearly a bug waiting to bite  
somebody.  
  
Fix by pstrdup'ing the string to be saved for the error callback,  
and then pfree'ing it next time through.  It's been like this for  
a long time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se  

commit   : 29be9983a64c011eac0b9ee29895cce71e15ea77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 16:47:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 16:47:36 -0400    

commit   : 4406364e2bf421459be7bd21503da093d910e0c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 13:30:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 13:30:18 -0400    

The previous text was confusing, per off-list discussion with  
Bruce Momjian.  

commit   : e62c5ea22c12f63d8d5ca3b228a458dfc10ae314    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 12:43:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 12:43:42 -0400    

99% of this is docs, but also a couple of comments.  No code changes.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20200919175804.GE30557@telsasoft.com  

commit   : d83268ae10cdeb2aa88e32286e94a8a8f59653a0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 10:06:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 10:06:30 +0200    

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

commit   : f6727f29d52072bd0e87fbc9ed7af0d880db0d5c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 09:05:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 09:05:13 +0200    

commit   : 9ab5ed4194f3863ff744e195027da747d4db4106    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Sep 2020 18:03:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Sep 2020 18:03:44 -0400    

These two SQL functions are aliases for the same C function, so this  
change has no semantic effect.  However, because we dropped the  
numeric_fac alias in HEAD (commit 76f412ab3), operator definitions  
based on that one don't port forward, causing problems for cross-version  
upgrade tests based on the regression database.  
  
Patch all active back branches to dodge the problem.  
  
Discussion: https://postgr.es/m/449144.1600439950@sss.pgh.pa.us  

commit   : f083afac9df707778288b9ab448be169a25e3ea6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 18 Sep 2020 09:40:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 18 Sep 2020 09:40:04 +0530    

After commits 85f6b49c2c and 3ba59ccc89, we can allow parallel inserts  
which was earlier not possible as parallel group members won't conflict  
for relation extension and page lock.  In those commits, we forgot to  
update comments at few places.  
  
Author: Amit Kapila  
Reviewed-by: Robert Haas and Dilip Kumar  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAFiTN-tMrQh5FFMPx5aWJ+1gi1H6JxktEhq5mDwCHgnEO5oBkA@mail.gmail.com  

commit   : 0abd9cd2f3a1cad201ca28767aa0a720cc341179    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Sep 2020 15:16:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Sep 2020 15:16:46 +0530    

For parallel btree scan to work for array of scan keys, it should reach  
BTPARALLEL_DONE state once for every distinct combination of array keys.  
This is required to ensure that the parallel workers don't try to seize  
blocks at the same time for different scan keys. We missed to update this  
state when we discovered that the scan keys can't be satisfied.  
  
Author: James Hunter  
Reviewed-by: Amit Kapila  
Tested-by: Justin Pryzby  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/4248CABC-25E3-4809-B4D0-128E1BAABC3C@amazon.com  

commit   : bfb12cd2b59da2ce51a9c86bf2c468202d8f96ee    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 16 Sep 2020 13:04:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 16 Sep 2020 13:04:38 -0300    

Since commit fd5942c18f97 (2012, 9.3-era), walsender has been sending  
completion tags for certain replication commands twice -- and they're  
not even consistent.  Apparently neither libpq nor JDBC have a problem  
with it, but it's not kosher.  Fix by remove the EndCommand() call in  
the common code path for them all, and inserting specific calls to  
EndReplicationCommand() specifically in those places where it's needed.  
  
EndReplicationCommand() is a new simple function to send the completion  
tag for replication commands.  Do this instead of sending a generic  
SELECT completion tag for them all, which was also pretty bogus (if  
innocuous).  While at it, change StartReplication() to use  
EndReplicationCommand() instead of pg_puttextmessage().  
  
In commit 2f9661311b83, I failed to realize that replication commands  
are not close-enough kin of regular SQL commands, so the  
DROP_REPLICATION_SLOT tag I added is undeserved and a type pun.  Take it  
out.  
  
Backpatch to 13, where the latter commit appeared.  The duplicate tag  
has been sent since 9.3, but since nothing is broken, it doesn't seem  
worth fixing.  
  
Per complaints from Tom Lane.  
  
Discussion: https://postgr.es/m/1347966.1600195735@sss.pgh.pa.us  

commit   : c287f585865b81c96602db995dacf2c006c79d58    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 16 Sep 2020 10:42:28 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 16 Sep 2020 10:42:28 -0700    

Commit d114cc53 overlooked the fact that pg_upgrade'd B-Tree indexes  
have leaf page high keys whose offset numbers do not match the one from  
the copy of the tuple one level up (the copy stored with a downlink for  
leaf page's right sibling page).  This led to false positive reports of  
corruption from bt_index_parent_check() when it was called to verify a  
pg_upgrade'd index.  
  
To fix, skip comparing the offset number on pg_upgrade'd B-Tree indexes.  
  
Author: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Andrew Bille <andrewbille@gmail.com>  
Diagnosed-By: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Bug: #16619  
Discussion: https://postgr.es/m/16619-aaba10f83fdc1c3c@postgresql.org  
Backpatch: 13-, where child check was enhanced.  

commit   : 17280b31c2f218f1b1f0c1fbacae7e781010a01b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 13:38:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 13:38:26 -0400    

If a partitioned table's column is already marked NOT NULL, there is  
no need to examine its partitions, because we can rely on previous  
DDL to have enforced that the child columns are NOT NULL as well.  
(Unfortunately, the same cannot be said for traditional inheritance,  
so for now we have to restrict the optimization to partitioned tables.)  
Hence, we may skip recursing to child tables in this situation.  
  
The reason this case is worth worrying about is that when pg_dump dumps  
a partitioned table having a primary key, it will include the requisite  
NOT NULL markings in the CREATE TABLE commands, and then add the  
primary key as a separate step.  The primary key addition generates a  
SET NOT NULL as a subcommand, just to be sure.  So the situation where  
a SET NOT NULL is redundant does arise in the real world.  
  
Skipping the recursion does more than just save a few cycles: it means  
that a command such as "ALTER TABLE ONLY partition_parent ADD PRIMARY  
KEY" will take locks only on the partition parent table, not on the  
partitions.  It turns out that parallel pg_restore is effectively  
assuming that that's true, and has little choice but to do so because  
the dependencies listed for such a TOC entry don't include the  
partitions.  pg_restore could thus issue this ALTER while data restores  
on the partitions are still in progress.  Taking unnecessary locks on  
the partitions not only hurts concurrency, but can lead to actual  
deadlock failures, as reported by Domagoj Smoljanovic.  
  
(A contributing factor in the deadlock is that TRUNCATE on a child  
partition wants a non-exclusive lock on the parent.  This seems  
likewise unnecessary, but the fix for it is more invasive so we  
won't consider back-patching it.  Fortunately, getting rid of one  
of these two poor behaviors is enough to remove the deadlock.)  
  
Although support for partitioned primary keys came in with v11,  
this patch is dependent on the SET NOT NULL refactoring done by  
commit f4a3fdfbd, so we can only patch back to v12.  
  
Patch by me; thanks to Alvaro Herrera and Amit Langote for review.  
  
Discussion: https://postgr.es/m/VI1PR03MB31670CA1BD9625C3A8C5DD05EB230@VI1PR03MB3167.eurprd03.prod.outlook.com  

commit   : 3e3f8f20206cbbb8d30be528d2a640d14a95c25c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 12:07:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 12:07:31 -0400    

The code recorded cache invalidation events by zeroing the "localreloid"  
field of affected cache entries.  However, it's possible for an inval  
event to occur even while we have the entry open and locked.  So an  
ill-timed inval could result in "cache lookup failed for relation 0"  
errors, if the worker's code tried to use the cleared field.  We can  
fix that by creating a separate bool field to record whether the entry  
needs to be revalidated.  (In the back branches, cram the bool into  
what had been padding space, to avoid an ABI break in the somewhat  
unlikely event that any extension is looking at this struct.)  
  
Also, rearrange the logic in logicalrep_rel_open so that it  
does the right thing in cases where table_open would fail.  
We should retry the lookup by name in that case, but we didn't.  
  
The real-world impact of this is probably small.  In the first place,  
the error conditions are very low probability, and in the second place,  
the worker would just exit and get restarted.  We only noticed because  
in a CLOBBER_CACHE_ALWAYS build, the failure can occur repeatedly,  
preventing the worker from making progress.  Nonetheless, it's clearly  
a bug, and it impedes a useful type of testing; so back-patch to v10  
where this code was introduced.  
  
Discussion: https://postgr.es/m/1032727.1600096803@sss.pgh.pa.us  

commit   : 6e146a663536f86c8421ac6ed08c4eb9a69979fd    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:34:05 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:34:05 -0700    

Previously, it was based on nBlocksAllocated to account for tapes with  
open write buffers that may not have made it to the BufFile yet.  
  
That was unnecessary, because callers do not need to get the number of  
blocks while a tape has an open write buffer; and it also conflicted  
with the preallocation logic added for HashAgg.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/ce5af05900fdbd0e9185747825a7423c48501964.camel@j-davis.com  
Backpatch-through: 13  

commit   : 42a46f5a76ecb435ac3a29fc3a0d03f1cfff17ab    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:16:31 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:16:31 -0700    

This was an oversight. The purpose of 7fdd919ae7 was to avoid keeping  
tape buffers around unnecessisarily, but HashAgg didn't rewind early  
enough.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/1fb1151c2cddf8747d14e0532da283c3f97e2685.camel@j-davis.com  
Backpatch-through: 13  

commit   : 873cb8fca9b14bde3e1d5577fcbb7b76d303076d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Sep 2020 21:03:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Sep 2020 21:03:14 -0300    

ALTER TABLE commands in an extension script are added to an event  
trigger command list; but starting with commit b5810de3f4 they do so in  
a memory context that's too short-lived, so when execution ends and time  
comes to use the entries, they've already been freed.  
  
(This would also be a problem with ALTER TABLE commands in a  
multi-command query string, but these serendipitously end in  
PortalContext -- which probably explains why it took so long for this to  
be reported.)  
  
Fix by using the memory context specifically set for that, instead.  
  
Backpatch to 13, where the aforementioned commit appeared.  
  
Reported-by: Philippe Beaudoin  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://postgr.es/m/20200902193715.6e0269d4@firost  

commit   : d42c6176446440b185fcb95c214b7e40d5758b60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 14:29:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 14:29:43 -0400    

Per gripe from Jonathan Katz.  
  
Discussion: https://postgr.es/m/e0a4d177-d003-8ebb-5296-5a445472b66f@postgresql.org  

commit   : 001d2c5f15bf8d554a7fe28af033d82c24de4e44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 10:58:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 10:58:37 -0400    

Parallel vacuuming isn't restricted to b-tree indexes.  
Noted by Peter Eisentraut.  
  
Discussion: https://postgr.es/m/f1c43223-3987-a23f-2063-18fd0aa4f0d4@2ndquadrant.com  

commit   : efea2b85fa2c3dec1c8039f1c97fcfe53ee5e82c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Sep 2020 16:08:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Sep 2020 16:08:07 -0400    

commit   : bab6f77f24407e0924dac292af9e65016fce99bf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 13:14:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 13:14:53 +0200    

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

commit   : 6fb1c5b528267918a88c4143985a08a3c997e528    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 13 Sep 2020 23:29:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 13 Sep 2020 23:29:51 -0700    

A pre-commit review had reported the problem, but the fix reached only  
v10 and earlier.  Back-patch to v11.  
  
Discussion: https://postgr.es/m/20200423.140546.1055476118690602079.horikyota.ntt@gmail.com  

commit   : b1b53f15bbac106e241b14ae1bc13f2708fe74c8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 06:42:07 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 06:42:07 +0200    

commit   : b380484a850b6bf7d9fc0d85c555a2366e38451f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Sep 2020 12:51:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Sep 2020 12:51:21 -0400    

transformCreateStmt() adjusts the transformed statement's RangeVar  
to specify the target schema explicitly, for the express reason  
of making sure that auxiliary statements derived by parse  
transformation operate on the right table.  But the refactoring  
I did in commit 502898192 got this wrong and passed the untransformed  
RangeVar to expandTableLikeClause().  This could lead to assertion  
failures or weird misbehavior if the wrong table was accessed.  
  
Per report from Alexander Lakhin.  Like the previous patch, back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/05051f9d-b32b-cb35-6735-0e9f2ab86b5f@gmail.com  

commit   : e6bbe07deec9824eb62fbbf38c4bfe7aaf674d37    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 6 Sep 2020 16:46:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 6 Sep 2020 16:46:13 +0200    

The original stylesheets seemed to think this was a good idea, but our  
users find it confusing and unhelpful, so undo that logic.  
  
Reported-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.22.394.2006210914370.859381%40pseudo  

commit   : 93106d71a18afdda2b9bf6e6b8e6c7f9cea2d0ef    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 11 Sep 2020 17:10:02 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 11 Sep 2020 17:10:02 -0700    

The preallocation logic is only useful for HashAgg, so disable it when  
sorting.  
  
Also, adjust an out-of-date comment.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wzn_o7tE2+hRVvwSFghRb75AJ5g-nqGzDUqLYMexjOAe=g@mail.gmail.com  
Backpatch-through: 13  

commit   : aeb781107a7ca0cfe109c188534ecbf9c392f6ba    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 16:15:47 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 16:15:47 -0300    

The stats target can be set since commit d06215d03, but wasn't shown by  
psql.  
  
Author: Justin Pryzby <justin@telsasoft.com>  
Discussion: https://postgr.es/m/20200831050047.GG5450@telsasoft.com  
Reviewed-by: Georgios Kokolatos <gkokolatos@protonmail.com>  
Reviewed-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>  

commit   : 6dcec8fe13b41b0773e9122168a1b53f3e458206    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 12:53:25 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 12:53:25 -0300    

Thinko in 40b3e2c201af.  
  
Reported-by: "Wang, Shenhao" <wangsh.fnst@cn.fujitsu.com>  
Discussion: https://postgr.es/m/ed98706b82694b57a8c0d339a10732aa@G08CNEXMBPEKD06.g08.fujitsu.local  

commit   : 9892564121d425291c4fd06ff083147dd70b9156    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 18:42:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 18:42:57 -0400    

Justin Pryzby  
  
Discussion: https://postgr.es/m/20200910222705.GJ18552@telsasoft.com  

commit   : 3965de54e718600a4703233936e56a3202caf73f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 17:43:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 17:43:16 -0400    

Also set the release date ... hopefully we won't have to change that.  

commit   : 3d92252d7d8bf7080ba61f1bda3d27bd8a3617e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 13:14:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 13:14:09 -0400    

Jonathan S. Katz, minor tweaks by me  
  
Discussion: https://postgr.es/m/448a382b-ae07-3126-5a08-aacda9aa28ea@postgresql.org  

commit   : 3f29aa48b6df318e43d0efe5735f61175ef38574    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 12:06:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 12:06:26 -0400    

Bring the signal handling for startup-packet collection into line  
with the policy established in commits bedadc732 and 8e19a8264,  
namely don't risk running atexit callbacks when handling SIGQUIT.  
  
Ideally, we'd not do so for SIGTERM or timeout interrupts either,  
but that change seems a bit too risky for the back branches.  
For now, just improve the comments in this area to describe the risk.  
  
Also relocate where BackendInitialize re-disables these interrupts,  
to minimize the code span where they're active.  This doesn't buy  
a whole lot of safety, but it can't hurt.  
  
In passing, rename startup_die() to remove confusion about whether  
it is for the startup process.  
  
Like the previous commits, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1850884.1599601164@sss.pgh.pa.us  

commit   : 9f358c5ef31327f7a67af783f5f37468bbac3aed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Sep 2020 15:31:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Sep 2020 15:31:09 +0200    

We have had multiple reports that point to the  
'@colReorder=latn-digit' collation customization being buggy.  We have  
reported this to ICU and are waiting for a fix.  In the meantime,  
remove references to this from the documentation and replace it by  
another reordering example.  Apparently, many users have been picking  
up this example specifically from the documentation.  
  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://www.postgresql.org/message-id/flat/153201618542.1404.3611626898935613264%40wrigleys.postgresql.org  

commit   : 727f6fb8f71f7ed64e6883164765bbf6cb7684ec    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 Sep 2020 14:15:26 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 Sep 2020 14:15:26 +0200    

Reported-by: Robert Kahlert  
Author: Daniel Gustafsson  

commit   : d601a930756b96fe05beb75a1b624a8155c98cc8    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 18:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 18:00:01 +0900    

Do some minor cleanup for commit c8434d64c: 1) remove a useless  
assignment (in normal builds) and 2) improve comments a little.  
  
Back-patch to v13 where the aforementioned commit went in.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/CAPmGK16yCd2R4=bQ4g8N2dT9TtA5ZU+qNmJ3LPc_nypbNy4_2A@mail.gmail.com  

commit   : 32a433455a0a6918b9c8f300d6c0be73ef06e9f9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 16:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 16:15:00 +0900    

Standardize Japanese names as given-name-first.  
  
Author: Etsuro Fujita  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/CAPmGK14S5frHWzsKS14R2LeMjKkjr5PeqRGiKZ0os0A+o8BWuQ@mail.gmail.com  

commit   : b3d89b7a889614a5ad549bae49b8a6fdda3a6bdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Sep 2020 15:50:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Sep 2020 15:50:42 +0900    

Some comments are fixed while on it.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200818171702.GK17022@telsasoft.com  
Backpatch-through: 9.6  

commit   : 6f15be5bedfc423b8a8f2f0282e2a0eb20a16663    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 9 Sep 2020 18:50:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 9 Sep 2020 18:50:24 -0700    

Move applicable code out of RelationBuildDesc(), which nailed relations  
bypass.  Non-assert builds experienced no known problems.  Back-patch to  
v13, where commit c6b92041d38512a4176ed76ad06f713d2e6c01a8 introduced  
rd_firstRelfilenodeSubid.  
  
Kyotaro Horiguchi.  Reported by Justin Pryzby.  
  
Discussion: https://postgr.es/m/20200907023737.GA7158@telsasoft.com  

commit   : 35e59398abbb562f1e831af206f1d1cc8c3cb7db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 15:32:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 15:32:34 -0400    

Commit 8e19a8264 changed the SIGQUIT handlers of almost all server  
processes not to run atexit callbacks.  The archiver process was  
skipped, perhaps because it's not connected to shared memory; but  
it's just as true here that running atexit callbacks in a signal  
handler is unsafe.  So let's make it work like the rest.  
  
In HEAD and v13, we can use the common SignalHandlerForCrashExit  
handler.  Before that, just tweak pgarch_exit to use _exit(2)  
explicitly.  
  
Like the previous commit, back-patch to all supported branches.  
  
Kyotaro Horiguchi, back-patching by me  
  
Discussion: https://postgr.es/m/1850884.1599601164@sss.pgh.pa.us  

commit   : 6b473ab4f23736d67c420909ab65c55228dcd6e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 12:00:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 12:00:49 -0400    

Commit 15cb2bd27 neglected to make the running text match the  
tables, leaving the reader with the strong impression that  
we cannot count.  Also, don't drop an unrelated para between  
a table and the para describing it.  

commit   : aa33187164e1d8571f1568f0470aaace8f791876    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 11:53:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 11:53:39 -0400    

Alexander Lakhin  
  
Discussion: https://postgr.es/m/ce7debdd-c943-d7a7-9b41-687107b27831@gmail.com  

commit   : 1bf0b9c5f58c61c160519a77a8f9dd24cea68b32    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 9 Sep 2020 12:20:53 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 9 Sep 2020 12:20:53 +0200    

Mistake in commit 68b603e1a9.  
  
Reported-by: Ian Barwick  

commit   : d0230a43fcae6f923fcedfe6f27db7fca8760d95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Sep 2020 19:35:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Sep 2020 19:35:15 -0300    

Partitioning tuple route code assumes that the partition chosen while  
descending the partition hierarchy is always the correct one.  This is  
true except when the partition is the default partition and another  
partition has been added concurrently: the partition constraint changes  
and we don't recheck it.  This can lead to tuples mistakenly being added  
to the default partition that should have been rejected.  
  
Fix by rechecking the default partition constraint while descending the  
hierarchy.  
  
An isolation test based on the reproduction steps described by Hao Wu  
(with tweaks for extra coverage) is included.  
  
Backpatch to 12, where this bug came in with 898e5e3290a7.  
  
Reported by: Hao Wu <hawu@vmware.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/CA+HiwqFqBmcSSap4sFnCBUEL_VfOMmEKaQ3gwUhyfa4c7J_-nA@mail.gmail.com  
Discussion: https://postgr.es/m/DM5PR0501MB3910E97A9EDFB4C775CF3D75A42F0@DM5PR0501MB3910.namprd05.prod.outlook.com  

commit   : b61d048e0d480f4311c62bf3026879c83ba9aaad    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 7 Sep 2020 13:31:59 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 7 Sep 2020 13:31:59 -0700    

Tomas Vondra observed that the IO behavior for HashAgg tends to be  
worse than for Sort. Penalize HashAgg IO costs accordingly.  
  
Also, account for the CPU effort of spilling the tuples and reading  
them back.  
  
Discussion: https://postgr.es/m/20200906212112.nzoy5ytrzjjodpfh@development  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  

commit   : e02c99bff6fcf7a14292cf99b16e4810ea89a2de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Sep 2020 14:52:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Sep 2020 14:52:33 -0400    

Some of the pre-existing comments were vague about whether they  
referred to all polymorphic types or only the old-style ones.  
  
Also be more consistent about using the "family 1" vs "family 2"  
terminology.  
  
Himanshu Upadhyaya and Tom Lane  
  
Discussion: https://postgr.es/m/CAPF61jBUg9XoMPNuLpoZ+h6UZ2VxKdNt3rQL1xw1GOBwjWzAXQ@mail.gmail.com  

commit   : 1e83138da14d61d572b0b58a9da6a2cf535ea198    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Sep 2020 09:08:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Sep 2020 09:08:58 +0200    

current through b7cf9e42ac2d4b153eb781195ebf369d4b8b566e  

commit   : b7cf9e42ac2d4b153eb781195ebf369d4b8b566e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Sep 2020 14:35:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Sep 2020 14:35:13 +0900    

The previous version of the docs mentioned that files are rewritten,  
implying that a second copy of each file gets created, but each file is  
updated in-place.  
  
Author: Michael Banck  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/858086b6a42fb7d17995b6175856f7e7ec44d0a2.camel@credativ.de  
Backpatch-through: 12  

commit   : a82919afe26ad93a135aa5f017a3f31ec5a6547a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 6 Sep 2020 19:28:32 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 6 Sep 2020 19:28:32 +0200    

It's better to use a relative path into the data directory, than to a  
hardcoded home directory of user 'josh'.  
  
Discussion: https://postgr.es/m/CABUevEyuf67Yu_r9gpDMs5MKifK7+-+pe=ZjKzya4JEn9kUk1w@mail.gmail.com  

commit   : f04203ab7e683bc3e961a40b002cf3c8d1d12100    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 12:55:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 12:55:13 -0400    

We reported the wrong types when complaining that an aggregate's  
moving-aggregate implementation is inconsistent with its regular  
implementation.  
  
This was wrong since the feature was introduced, so back-patch  
to all supported branches.  
  
Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1x808LH=LPhZp9mNSP0Xd1xDqEd+XeGcvEe48dfE6xV=A@mail.gmail.com  

commit   : e7f06ea60a3c07128176b294ce3fb0555edd15a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 11:50:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 11:50:40 -0400    

This is duplicative of an lstat that was just done by the calling  
function (traverse_datadir), besides which we weren't really doing  
anything with the results.  There's not much point in checking to  
see if someone removed the file since the previous lstat, since the  
FILE_ACTION_REMOVE code would have to deal with missing-file cases  
anyway.  Moreover, the "exists = false" assignment was a dead store;  
nothing was done with that value later.  
  
A syscall saved is a syscall earned, so back-patch to 9.5  
where this code was introduced.  
  
Discussion: https://postgr.es/m/1221796.1599329320@sss.pgh.pa.us  

commit   : 8df601bd4067ecdf373ebe43bdf03159a12e2e9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 21:01:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 21:01:59 -0400    

I happened to notice that the new test case I added in b55b4dad9  
falls over if one runs "make check" repeatedly; though not in branches  
after v10.  That's because it was assuming that tmp_check/pgpass  
wouldn't exist already.  However, it's only been since v11 that the  
Makefiles forcibly remove all of tmp_check/ before starting a TAP run.  
This fix to unlink the file is therefore strictly necessary only in  
v10 ... but it seems wisest to do it across the board, rather than  
let the test rely on external logic to get the conditions right.  

commit   : 9b81a30f924cf30e6bf3abb3366706440351e163    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 20:20:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 20:20:05 -0400    

Commit 3f60f690f only partially fixed the broken-status-tracking  
issue in LogicalRepApplyLoop: we need ping_sent to have the same  
lifetime as last_recv_timestamp.  The effects are much less serious  
than what that commit fixed, though.  AFAICS this would just lead to  
extra ping requests being sent, once per second until the sender  
responds.  Still, it's a bug, so backpatch to v10 as before.  
  
Discussion: https://postgr.es/m/959627.1599248476@sss.pgh.pa.us  

commit   : 4a4f3bf983b4abd908585a8d752eee0e47627034    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 4 Sep 2020 12:01:58 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 4 Sep 2020 12:01:58 -0700    

Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0PiB-G6QpxHXZOjuvFAzPdZw@mail.gmail.com  
Backpatch-through: 13  

commit   : 72857482c135677703111855f33550c442108eaa    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 Sep 2020 13:53:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 Sep 2020 13:53:09 -0400    

If this data is not collected, pg_dump segfaults if asked for column  
inserts.  
  
Fix by Fabrízio de Royes Mello  
  
Backpatch to release 12 where the bug was introduced.  

commit   : 7574af1e1b94a4de7a6f63f3a7854a508ab7b0e0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 4 Sep 2020 13:27:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 4 Sep 2020 13:27:52 -0400    

Reported-by: Kelly Min  
  
Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=DqFA9g@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : afec6ba0bae0258835b81fcc0eeed3ff9c455427    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 12:40:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 12:40:28 -0400    

The "DROP ACCESS METHOD gist2" test will require locking the index  
to be dropped and then its table; while most ordinary operations  
lock a table first then its index.  While no concurrent test scripts  
should be touching fast_emp4000, autovacuum might chance to be  
processing that table when the DROP runs, resulting in a deadlock  
failure.  This is pretty rare but we see it in the buildfarm from  
time to time.  
  
To fix, acquire a lock on fast_emp4000 before issuing the DROP.  
  
Since the point of the exercise is mostly to prevent buildfarm  
failures, back-patch to 9.6 where this test was introduced.  
  
Discussion: https://postgr.es/m/839004.1599185607@sss.pgh.pa.us  

commit   : 17424e79d9794b00bdb6653185fc27ba423d8d81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 16:52:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 16:52:09 -0400    

Because sigsetjmp() will restore the initial state with signals blocked,  
the code path in bgworker.c for reporting an error and exiting would  
execute that way.  Usually this is fairly harmless; but if a parallel  
worker had an error message exceeding the shared-memory communication  
buffer size (16K) it would lock up, because it would wait for a  
resume-sending signal from its parallel leader which it would never  
detect.  
  
To fix, just unblock signals at the appropriate point.  
  
This can be shown to fail back to 9.6.  The lack of parallel query  
infrastructure makes it difficult to provide a simple test case for  
9.5; but I'm pretty sure the issue exists in some form there as well,  
so apply the code change there too.  
  
Vignesh C, reviewed by Bharath Rupireddy, Robert Haas, and myself  
  
Discussion: https://postgr.es/m/CALDaNm1d1hHPZUg3xU4XjtWBOLCrA+-2cJcLpw-cePZ=GgDVfA@mail.gmail.com  

commit   : 214bc9038e39e209924514b77db4ee491f95509a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 11:45:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 11:45:26 -0400    

The majority of our audience is probably using a pre-packaged Postgres  
build rather than raw sources.  For them, much of runtime.sgml is not  
too relevant, and they should be reading the packager's docs instead.  
Add some notes pointing that way in appropriate places.  
  
Text by me; thanks to Daniel Gustafsson for review and discussion,  
and to Laurenz Albe for an earlier version.  
  
Discussion: https://postgr.es/m/159430831443.16535.11360317280100947016@wrigleys.postgresql.org  

commit   : 352b8cf59f400e69a80db12f920adf12a1b0607c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 20:43:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 20:43:23 -0400    

Introduced by 8b08f7d4820f; backpatch to 11.  
  
Discussion: https://postgr.es/m/20200812214918.GA30353@alvherre.pgsql  

commit   : 2c7db50ce83ec375ad6ddeba498f07c78bc10e97    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Sep 2020 17:00:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Sep 2020 17:00:10 -0400    

Previous wording was "between".  
  
Reported-by: Pavel Luzanov  
  
Discussion: https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024694@postgrespro.ru  
  
Backpatch-through: 9.5  

commit   : 15dad5776578e884ee7857abb278a116c0c3e578    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 13:40:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 13:40:43 -0400    

We were already raising an error for DROP INDEX CONCURRENTLY on a  
partitioned table, albeit a different and confusing one:  
  ERROR:  DROP INDEX CONCURRENTLY must be first action in transaction  
  
Change that to throw a more comprehensible error:  
  ERROR:  cannot drop partitioned index \"%s\" concurrently  
  
Michael Paquier authored the test case for indexes on temporary  
partitioned tables.  
  
Backpatch to 11, where indexes on partitioned tables were added.  
  
Reported-by: Jan Mussler <jan.mussler@zalando.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/16594-d2956ca909585067@postgresql.org  

commit   : 4178b749963cbf28d438b81e38dedcf885ccdda3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2020 13:14:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2020 13:14:44 -0400    

Historically there's been a hard-wired assumption here that no line of  
a .pgpass file could be as long as NAMEDATALEN*5 bytes.  That's a bit  
shaky to start off with, because (a) there's no reason to suppose that  
host names fit in NAMEDATALEN, and (b) this figure fails to allow for  
backslash escape characters.  However, it fails completely if someone  
wants to use a very long password, and we're now hearing reports of  
people wanting to use "security tokens" that can run up to several  
hundred bytes.  Another angle is that the file is specified to allow  
comment lines, but there's no reason to assume that long comment lines  
aren't possible.  
  
Rather than guessing at what might be a more suitable limit, let's  
replace the fixed-size buffer with an expansible PQExpBuffer.  That  
adds one malloc/free cycle to the typical use-case, but that's surely  
pretty cheap relative to the I/O this code has to do.  
  
Also, add TAP test cases to exercise this code, because there was no  
test coverage before.  
  
This reverts most of commit 2eb3bc588, as there's no longer a need for  
a warning message about overlength .pgpass lines.  (I kept the explicit  
check for comment lines, though.)  
  
In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not  
much point in explicit_bzero'ing the line buffer if we only do so in two  
of the three exit paths.  
  
Back-patch to all supported branches, except that the test case only  
goes back to v10 where src/test/authentication/ was added.  
  
Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us  

commit   : 73018f564af91b135e541b28133369c5e3de975d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:48:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:48:38 -0400    

Reported-by: Bernd Helmle  
  
Discussion: https://postgr.es/m/31acf8b0f1f701d53245e0cae38abdf5c3a0d559.camel@oopsware.de  
  
Backpatch-through: 13  

commit   : 1d3ff89ecfbbdd8bf56d4773d8f2749156eeb7c1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:33:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:33:37 -0400    

This follows the American format,  
https://jakubmarian.com/comma-after-i-e-and-e-g/. There is no intention  
of requiring this format for future text, but making existing text  
consistent every few years makes sense.  
  
Discussion: https://postgr.es/m/20200825183619.GA22369@momjian.us  
  
Backpatch-through: 9.5  

commit   : 787ccf5a5fc92698e8cc8ebfb6fe1a0bf28981a4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:51:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:51:31 -0400    

Reported-by: Antonin Houska  
  
Discussion: https://postgr.es/m/21643.1595353537@antos  
  
Backpatch-through: 9.5  

commit   : cef30b66fdf619a1b7aa0c2605719e64e980c6f2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:36:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:36:23 -0400    

Also mention files included by postgresql.conf.  
  
Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/08AD4526-75AB-457B-B2DD-099663F28040@yesql.se  
  
Backpatch-through: 9.5  

commit   : 97dc0d1d58916e2f063ce8a7eec6bd4d3bc29197    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 31 Aug 2020 17:04:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 31 Aug 2020 17:04:40 -0400    

Reported-by: Erwin Brandstetter <brsaweda@gmail.com>  
Discussion: https://postgr.es/m/CAGHENJ6Le7S3qJJx2TvWvTwRNS3N=BtoNeb7AF2rZvfNBMeQcg@mail.gmail.com  

commit   : bef7b917a76af659b4d6bce813702764e2c749db    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:05:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:05:53 -0400    

It is an int64.  
  
Reported-by: ajulien@shaktiware.fr  
  
Discussion: https://postgr.es/m/159845038271.24995.15682121015698255155@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 9bb4f98bb7745b7339fb7d102cdc36d66c002f67    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:59:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:59:59 -0400    

There is an file-fdw example that reads the server config file, so cross  
link them.  
  
Reported-by: Oleg Samoilov  
  
Discussion: https://postgr.es/m/159800192078.2886.10431506404995508950@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 8924ca865b18cac0b655170989bcd9507991d06f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:21:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:21:03 -0400    

Specifically, explain the v3_ca openssl specification.  
  
Discussion: https://postgr.es/m/20200824175653.GA32411@momjian.us  
  
Backpatch-through: 9.5  

commit   : 1bb41c6ad795e018e396eb3e216b2d21fadc865a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 15:23:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 15:23:19 -0400    

For PG, "durable storage" has a clear meaning, while "stable storage"  
does not, so use the former.  
  
Discussion: https://postgr.es/m/20200817165222.GA31806@momjian.us  
  
Backpatch-through: 9.5  

commit   : 8006ac1c5117a56fcd138d663a3fe3709c8f9988    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:49:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:49:17 -0400    

It wasn't clear the non-integers are cast to integers for subscripting,  
rather than throwing an error.  
  
Reported-by: sean@materialize.io  
  
Discussion: https://postgr.es/m/159538675800.624.7728794628229799531@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 64fd65008c62ec011ba2d0673ca09849ae2b07c8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:43:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:43:04 -0400    

Adds constraints and improves wording.  
  
Reported-by: 2552891@gmail.com  
  
Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 785affc1d653bac43b7d4fad93f22e9e51aefcc1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:20:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:20:04 -0400    

This was not clearly documented when procedures were added in PG 11.  
  
Reported-by: Robin Abbi  
  
Discussion: https://postgr.es/m/CAGmg_NX327KKVuJmbWZD=pGutYFxzZjX1rU+3ji8UuX=8ONn9Q@mail.gmail.com  
  
Backpatch-through: 11  

commit   : 3a1f6a2581e41ee2c724e8422675942d30a52ff7    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 31 Aug 2020 13:03:54 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 31 Aug 2020 13:03:54 +0200    

It has always (since the first commit) worked with relative paths, so  
use the same wording as other parts of the documentation.  
  
Author: Bruce Momjian  
Discussion: https://postgr.es/m/CABUevExx-hm=cit+A9LeKBH39srvk8Y2tEZeEAj5mP8YfzNKUg@mail.gmail.com  

commit   : 845cfe012fd15300cd090b05fb4029a26b848a67    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Aug 2020 14:37:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Aug 2020 14:37:24 -0400    

Per discussion, we're planning to remove parser support for postfix  
operators in order to simplify the grammar.  So it behooves us to  
put out a deprecation notice at least one release before that.  
  
There is only one built-in postfix operator, ! for factorial.  
Label it deprecated in the docs and in pg_description, and adjust  
some examples that formerly relied on it.  (The sister prefix  
operator !! is also deprecated.  We don't really have to remove  
that one, but since we're suggesting that people use factorial()  
instead, it seems better to remove both operators.)  
  
Also state in the CREATE OPERATOR ref page that postfix operators  
in general are going away.  
  
Although this changes the initial contents of pg_description,  
I did not force a catversion bump; it doesn't seem essential.  
  
In v13, also back-patch 4c5cf5431, so that there's someplace for  
the <link>s to point to.  
  
Mark Dilger and John Naylor, with some adjustments by me  
  
Discussion: https://postgr.es/m/BE2DF53D-251A-4E26-972F-930E523580E9@enterprisedb.com  

commit   : 1df14a5669428c0060ebdcebed8c1f807b659893    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Aug 2020 17:36:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Aug 2020 17:36:13 -0400    

collectMatchBitmap() needs to re-find the index tuple it was previously  
looking at, after transiently dropping lock on the index page it's on.  
The tuple should still exist and be at its prior position or somewhere  
to the right of that, since ginvacuum never removes tuples but  
concurrent insertions could add one.  However, there was a thinko in  
that logic, to the effect of expecting any inserted tuples to have the  
same index "attnum" as what we'd been scanning.  Since there's no  
physical separation of tuples with different attnums, it's not terribly  
hard to devise scenarios where this fails, leading to transient "lost  
saved point in index" errors.  (While I've duplicated this with manual  
testing, it seems impossible to make a reproducible test case with our  
available testing technology.)  
  
Fix by just continuing the scan when the attnum doesn't match.  
  
While here, improve the error message used if we do fail, so that it  
matches the wording used in btree for a similar case.  
  
collectMatchBitmap()'s posting-tree code path was previously not  
exercised at all by our regression tests.  While I can't make  
a regression test that exhibits the bug, I can at least improve  
the code coverage here, so do that.  The test case I made for this  
is an extension of one added by 4b754d6c1, so it only works in  
HEAD and v13; didn't seem worth trying hard to back-patch it.  
  
Per bug #16595 from Jesse Kinkead.  This has been broken since  
multicolumn capability was added to GIN (commit 27cb66fdf),  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16595-633118be8eef9ce2@postgresql.org  

commit   : 32c42b815ad2377c0bddc4f55b7bf32a5204a87d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 25 Aug 2020 09:53:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 25 Aug 2020 09:53:12 -0400    

They are not "requested" by the server.  
  
Reported-by: Kyotaro Horiguchi  
  
Discussion: https://postgr.es/m/20200825.155320.986648039251743210.horikyota.ntt@gmail.com  
  
Backpatch-through: 9.5  

commit   : 62340f8eca4c9d4e49097eaf0a341aca8450b56b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 Aug 2020 07:29:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 Aug 2020 07:29:05 +0200    

This fixes some instances that were missed in earlier processings and  
that now look a bit strange because they are inconsistent with nearby  
titles.  

commit   : b4ef5ac0b7bfa734ad908bb5577cf4ee65ce2974    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 24 Aug 2020 08:22:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 24 Aug 2020 08:22:54 +0530    

We were displaying the wrong phase information for 'info' message in the  
index clean up phase because we were switching to the previous phase a bit  
early. We were also not displaying context information for heap phase  
unless the block number is valid which is fine for error cases but for  
messages at 'info' or lower error level it appears to be inconsistent with  
index phase information.  
  
Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CA+fd4k4HcbhPnCs7paRTw1K-AHin8y4xKomB9Ru0ATw0UeTy2w@mail.gmail.com  

commit   : de627adaad3a161b3ae0cafeb76c20519845799b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Aug 2020 14:46:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Aug 2020 14:46:40 -0400    

The trouble with doing this is that an apparently-constant subquery  
output column isn't really constant if it is a grouping column that  
appears in only some of the grouping sets.  A qual using such a  
column would be subject to incorrect const-folding after push-down,  
as seen in bug #16585 from Paul Sivash.  
  
To fix, just disable qual pushdown altogether if the sub-query has  
nonempty groupingSets.  While we could imagine far less restrictive  
solutions, there is not much point in working harder right now,  
because subquery_planner() won't move HAVING clauses to WHERE within  
such a subquery.  If the qual stays in HAVING it's not going to be  
a lot more useful than if we'd kept it at the outer level.  
  
Having said that, this restriction could be removed if we used a  
parsetree representation that distinguished such outputs from actual  
constants, which is something I hope to do in future.  Hence, make  
the patch a minimal addition rather than integrating it more tightly  
(e.g. by renumbering the existing items in subquery_is_pushdown_safe's  
comment).  
  
Back-patch to 9.5 where grouping sets were introduced.  
  
Discussion: https://postgr.es/m/16585-9d8c340d23ade8c1@postgresql.org  

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

Commit 1281a5c90 rearranged the logic in this area rather drastically,  
and it broke the case of adding a foreign key constraint in the same  
ALTER that adds the pkey or unique constraint it depends on.  While  
self-referential fkeys are surely a pretty niche case, this used to  
work so we shouldn't break it.  
  
To fix, reorganize the scheduling rules in ATParseTransformCmd so  
that a transformed AT_AddConstraint subcommand will be delayed into  
a later pass in all cases, not only when it's been spit out as a  
side-effect of parsing some other command type.  
  
Also tweak the logic so that we won't run ATParseTransformCmd twice  
while doing this.  It seems to work even without that, but it's  
surely wasting cycles to do so.  
  
Per bug #16589 from Jeremy Evans.  Back-patch to v13 where the new  
code was introduced.  
  
Discussion: https://postgr.es/m/16589-31c8d981ca503896@postgresql.org  

commit   : 610394c7b876bc841464aad38f8abed09d63924e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 22 Aug 2020 22:26:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 22 Aug 2020 22:26:18 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/a2345841-10a5-4eef-257c-02302347cf39@gmail.com  
Backpatch-through: 13  

commit   : 3669792934593a7b682c5b32dea41c9e3b48e6cc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 20:23:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 20:23:09 -0400    

This is a redesign of the intro to the managing databases chapter.  
  
Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org  
  
Author: David G. Johnston  
  
Backpatch-through: 9.5  

commit   : 35f2d22ba909735448606fefc126b73e4fb3c627    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 18:29:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 18:29:37 -0400    

Reported-by: Jürgen Purtz  
  
Discussion: https://postgr.es/m/15ec5428-d46a-1725-f38d-44986a977abb@purtz.de  
  
Author: Jürgen Purtz  
  
Backpatch-through: 11  

commit   : 894f5dea76e1a59fa2f3e1905c6a44f254d9d08b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2020 15:00:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2020 15:00:42 -0400    

If a CREATE TABLE command uses both LIKE and traditional inheritance,  
Vars in CHECK constraints and expression indexes that are absorbed  
from a LIKE parent table tended to get mis-numbered, resulting in  
wrong answers and/or bizarre error messages (though probably not any  
actual crashes, thanks to validation occurring in the executor).  
  
In v12 and up, the same could happen to Vars in GENERATED expressions,  
even in cases with no LIKE clause but multiple traditional-inheritance  
parents.  
  
The cause of the problem for LIKE is that parse_utilcmd.c supposed  
it could renumber such Vars correctly during transformCreateStmt(),  
which it cannot since we have not yet accounted for columns added via  
inheritance.  Fix that by postponing processing of LIKE INCLUDING  
CONSTRAINTS, DEFAULTS, GENERATED, INDEXES till after we've performed  
DefineRelation().  
  
The error with GENERATED and multiple inheritance is a simple oversight  
in MergeAttributes(); it knows it has to renumber Vars in inherited  
CHECK constraints, but forgot to apply the same processing to inherited  
GENERATED expressions (a/k/a defaults).  
  
Per bug #16272 from Tom Gottfried.  The non-GENERATED variants of the  
issue are ancient, presumably dating right back to the addition of  
CREATE TABLE LIKE; hence back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16272-6e32da020e9a9381@postgresql.org  

commit   : bc2ebf3acfd287247cd9ee286c44e969af1c81de    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 22 Aug 2020 01:22:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 22 Aug 2020 01:22:55 +0900    

Commit 9d701e624f caused the regression test for EXPLAIN to fail on  
the buildfarm member prion. This happened because of instability of  
test output, i.e., in text format, whether "Planning:" line is output  
varies depending on the system state.  
  
This commit updated the regression test so that it ignores that  
"Planning:" line to produce more stable test output and get rid of  
the test failure.  
  
Back-patch to v13.  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/1803897.1598021621@sss.pgh.pa.us  

commit   : 674899ae02c375b03411c0676e7cfb4bafeebac9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Aug 2020 20:48:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Aug 2020 20:48:59 +0900    

Commit ce77abe63c allowed EXPLAIN (BUFFERS) to report the information  
on buffer usage during planning phase. However three issues were  
reported regarding this feature.  
  
(1) Previously, EXPLAIN option BUFFERS required ANALYZE. So the query  
    had to be actually executed by specifying ANALYZE even when we  
    want to see only the planner's buffer usage. This was inconvenient  
    especially when the query was write one like DELETE.  
  
(2) EXPLAIN included the planner's buffer usage in summary  
    information. So SUMMARY option had to be enabled to report that.  
    Also this format was confusing.  
  
(3) The output structure for planning information was not consistent  
    between TEXT format and the others. For example, "Planning" tag  
    was output in JSON format, but not in TEXT format.  
  
For (1), this commit allows us to perform EXPLAIN (BUFFERS) without  
ANALYZE to report the planner's buffer usage.  
  
For (2), this commit changed EXPLAIN output so that the planner's  
buffer usage is reported before summary information.  
  
For (3), this commit made the output structure for planning  
information more consistent between the formats.  
  
Back-patch to v13 where the planner's buffer usage was allowed to  
be reported in EXPLAIN.  
  
Reported-by: Pierre Giraud, David Rowley  
Author: Fujii Masao  
Reviewed-by: David Rowley, Julien Rouhaud, Pierre Giraud  
Discussion: https://postgr.es/m/07b226e6-fa49-687f-b110-b7c37572f69e@dalibo.com  

commit   : 0d7437de73b68b0105d00ff4fed3e7894b02f6d5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Aug 2020 09:34:47 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Aug 2020 09:34:47 +1200    

Reviewed-by: Abhijit Menon-Sen  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com  
Backpatch-through: 11, where JIT was added  

commit   : 2a9f042c47053e3ce73f634cce9622fa0151f63c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 20 Aug 2020 13:49:04 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 20 Aug 2020 13:49:04 -0400    

When the leftover invalid index is "ccold", there's no need to re-run  
the command.  Reword the instructions to make that explicit.  
  
Backpatch to 12, where REINDEX CONCURRENTLY appeared.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/20200819211312.GA15497@alvherre.pgsql  

commit   : 69ffc2f838990fb2c802087091ce7c2ff1b735eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Aug 2020 14:07:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Aug 2020 14:07:49 -0400    

Commit a477bfc1d fixed eval_const_expressions() to ensure that it  
didn't generate unnecessary RelabelType nodes, but I failed to notice  
that some other places in the planner had the same issue.  Really  
noplace in the planner should be using plain makeRelabelType(), for  
fear of generating expressions that should be equal() to semantically  
equivalent trees, but aren't.  
  
An example is that because canonicalize_ec_expression() failed  
to be careful about this, we could end up with an equivalence class  
containing both a plain Const, and a Const-with-RelabelType  
representing exactly the same value.  So far as I can tell this led to  
no visible misbehavior, but we did waste a bunch of cycles generating  
and evaluating "Const = Const-with-RelabelType" to prove such entries  
are redundant.  
  
Hence, move the support function added by a477bfc1d to where it can  
be more generally useful, and use it in the places where planner code  
previously used makeRelabelType.  
  
Back-patch to v12, like the previous patch.  While I have no concrete  
evidence of any real misbehavior here, it's certainly possible that  
I overlooked a case where equivalent expressions that aren't equal()  
could cause a user-visible problem.  In any case carrying extra  
RelabelType nodes through planning to execution isn't very desirable.  
  
Discussion: https://postgr.es/m/1311836.1597781384@sss.pgh.pa.us  

commit   : bff41b2b8938f5e3e7d536da6d7a14a1648b4dec    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 18 Aug 2020 13:13:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 18 Aug 2020 13:13:09 +0300    

As Tom Lane pointed out, it could defeat the compiler's printf() format  
string verification.  
  
Backpatch to v12, like that patch that introduced it.  
  
Discussion: https://www.postgresql.org/message-id/1069283.1597672779%40sss.pgh.pa.us  

commit   : b83f1bcca0bb460413da4ce856b030502b4f71c5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Aug 2020 16:20:06 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Aug 2020 16:20:06 -0400    

This should improve stability in the tests.  
  
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.  
  
Discussion: https://postgr.es/m/871534.1597503261@sss.pgh.pa.us  

commit   : 8216a1d3ed27364c7b2a9e6db76f15202a6070c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Aug 2020 15:40:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Aug 2020 15:40:07 -0400    

The description of what select_common_type() does was not terribly  
accurate.  Improve it.  
  
David Johnston and Tom Lane  
  
Discussion: https://postgr.es/m/1019930.1597613200@sss.pgh.pa.us  

commit   : 5ca1798f32b7fe730fef7ccd8d69e785a50134b8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Aug 2020 09:27:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Aug 2020 09:27:29 +0300    

A number of client programs have a "--progress" option that when printing  
to a TTY, updates the current line by printing a '\r' and overwriting it.  
After the last line, '\n' needs to be printed to move the cursor to the  
next line. pg_basebackup and pgbench got this right, but pg_rewind and  
pg_checksums were slightly wrong. pg_rewind printed the newline to stdout  
instead of stderr, and pg_checksums printed the newline even when not  
printing to a TTY. Fix them, and also add a 'finished' argument to  
pg_basebackup's progress_report() function, to keep it consistent with  
the other programs.  
  
Backpatch to v12. pg_rewind's newline was broken with the logging changes  
in commit cc8d415117 in v12, and pg_checksums was introduced in v12.  
  
Discussion: https://www.postgresql.org/message-id/82b539e5-ae33-34b0-1aee-22b3379fd3eb@iki.fi  

commit   : 3424c6bef0b897f9c6800f55d34a162a07319795    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Aug 2020 10:24:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Aug 2020 10:24:24 +0900    

Since 806a2ae, the work of the bgwriter is split the checkpointer, but a  
portion of the documentation did not get the message.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CA+fd4k6jXxjAtjMVC=wG3=QGpauZBtcgN3Jhw+oV7zXGKVLKzQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 277e49eca73a719695d0b74360b54124e76c6833    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2020 15:43:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2020 15:43:34 -0400    

Put the -r option in the right section (it certainly isn't an  
option controlling "the location and format of the output").  
  
Clarify the behavior of the tablespace and waldir options  
(that part per gripe from robert@interactive.co.uk).  
  
Make a large number of small copy-editing fixes in text that  
visibly wasn't written by native speakers, and try to avoid  
grammatical inconsistencies between the descriptions of  
the different options.  
  
Back-patch to v13, since HEAD hasn't meaningfully diverged yet.  
  
Discussion: https://postgr.es/m/159749418850.14322.216503677134569752@wrigleys.postgresql.org  

commit   : 592a589a04bd456410b853d86bd05faa9432cbbb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 15 Aug 2020 10:15:53 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 15 Aug 2020 10:15:53 -0700    

The SimpleLruTruncate() header comment states the new coding rule.  To  
achieve this, add locktype "frozenid" and two LWLocks.  This closes a  
rare opportunity for data loss, which manifested as "apparent  
wraparound" or "could not access status of transaction" errors.  Data  
loss is more likely in pg_multixact, due to released branches' thin  
margin between multiStopLimit and multiWrapLimit.  If a user's physical  
replication primary logged ":  apparent wraparound" messages, the user  
should rebuild standbys of that primary regardless of symptoms.  At less  
risk is a cluster having emitted "not accepting commands" errors or  
"must be vacuumed" warnings at some point.  One can test a cluster for  
this data loss by running VACUUM FREEZE in every database.  Back-patch  
to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/20190218073103.GA1434723@rfd.leadboat.com  

commit   : b538e83f17e36fd0fe0686815da0ff5866ce8a64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 22:14:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 22:14:03 -0400    

nodeSubplan.c expects that the testexpr for a hashable ANY SubPlan  
has the form of one or more OpExprs whose LHS is an expression of the  
outer query's, while the RHS is an expression over Params representing  
output columns of the subquery.  However, the planner only went as far  
as verifying that the clauses were all binary OpExprs.  This works  
99.99% of the time, because the clauses have the right shape when  
emitted by the parser --- but it's possible for function inlining to  
break that, as reported by PegoraroF10.  To fix, teach the planner  
to check that the LHS and RHS contain the right things, or more  
accurately don't contain the wrong things.  Given that this has been  
broken for years without anyone noticing, it seems sufficient to just  
give up hashing when it happens, rather than go to the trouble of  
commuting the clauses back again (which wouldn't necessarily work  
anyway).  
  
While poking at that, I also noticed that nodeSubplan.c had a baked-in  
assumption that the number of hash clauses is identical to the number  
of subquery output columns.  Again, that's fine as far as parser output  
goes, but it's not hard to break it via function inlining.  There seems  
little reason for that assumption though --- AFAICS, the only thing  
it's buying us is not having to store the number of hash clauses  
explicitly.  Adding code to the planner to reject such cases would take  
more code than getting nodeSubplan.c to cope, so I fixed it that way.  
  
This has been broken for as long as we've had hashable SubPlans,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1549209182255-0.post@n3.nabble.com  

commit   : b7cc21c57d738b41f6116f46d566b9949a433747    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Aug 2020 17:33:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Aug 2020 17:33:31 -0400    

Parallel-restoring a foreign key that references a partitioned table  
with several levels of partitions can fail:  
  
pg_restore: while PROCESSING TOC:  
pg_restore: from TOC entry 6684; 2606 29166 FK CONSTRAINT fk fk_a_fkey postgres  
pg_restore: error: could not execute query: ERROR:  there is no unique constraint matching given keys for referenced table "pk"  
Command was: ALTER TABLE fkpart3.fk  
    ADD CONSTRAINT fk_a_fkey FOREIGN KEY (a) REFERENCES fkpart3.pk(a);  
  
This happens in parallel restore mode because some index partitions  
aren't yet attached to the topmost partitioned index that the FK uses,  
and so the index is still invalid.  The current code marks the FK as  
dependent on the first level of index-attach dump objects; the bug is  
fixed by recursively marking the FK on their children.  
  
Backpatch to 12, where FKs to partitioned tables were introduced.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/3170626.1594842723@sss.pgh.pa.us  
Backpatch: 12-master  

commit   : 1c6066fbdb70a92b10b8616652d25c4434cd222e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 13:26:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 13:26:57 -0400    

Up to now, upon receipt of a SIGTERM ("smart shutdown" command), the  
postmaster has immediately killed all "optional" background processes,  
and subsequently refused to launch new ones while it's waiting for  
foreground client processes to exit.  No doubt this seemed like an OK  
policy at some point; but it's a pretty bad one now, because it makes  
for a seriously degraded environment for the remaining clients:  
  
* Parallel queries are killed, and new ones fail to launch. (And our  
parallel-query infrastructure utterly fails to deal with the case  
in a reasonable way --- it just hangs waiting for workers that are  
not going to arrive.  There is more work needed in that area IMO.)  
  
* Autovacuum ceases to function.  We can tolerate that for awhile,  
but if bulk-update queries continue to run in the surviving client  
sessions, there's eventually going to be a mess.  In the worst case  
the system could reach a forced shutdown to prevent XID wraparound.  
  
* The bgwriter and walwriter are also stopped immediately, likely  
resulting in performance degradation.  
  
Hence, let's rearrange things so that the only immediate change in  
behavior is refusing to let in new normal connections.  Once the last  
normal connection is gone, shut everything down as though we'd received  
a "fast" shutdown.  To implement this, remove the PM_WAIT_BACKUP and  
PM_WAIT_READONLY states, instead staying in PM_RUN or PM_HOT_STANDBY  
while normal connections remain.  A subsidiary state variable tracks  
whether or not we're letting in new connections in those states.  
  
This also allows having just one copy of the logic for killing child  
processes in smart and fast shutdown modes.  I moved that logic into  
PostmasterStateMachine() by inventing a new state PM_STOP_BACKENDS.  
  
Back-patch to 9.6 where parallel query was added.  In principle  
this'd be a good idea in 9.5 as well, but the risk/reward ratio  
is not as good there, since lack of autovacuum is not a problem  
during typical uses of smart shutdown.  
  
Per report from Bharath Rupireddy.  
  
Patch by me, reviewed by Thomas Munro  
  
Discussion: https://postgr.es/m/CALj2ACXAZ5vKxT9P7P89D87i3MDO9bfS+_bjMHgnWJs8uwUOOw@mail.gmail.com  

commit   : cabec1dbdf405211c1a4d30f52a91e8de2cf7226    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Aug 2020 10:40:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Aug 2020 10:40:50 +0300    

commit   : 124772e3cac6d3bf6c1f6d32518209c6a3fdd3eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Aug 2020 20:00:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Aug 2020 20:00:39 -0400    

Make these examples self-contained by providing declarations of the  
user-defined row types they rely on.  There wasn't room to do this  
in the old doc format, but now there is, and I think it makes the  
examples a good bit less confusing.  

commit   : 2f29fd4cb2522dfd64888892f0442a0ead8c6dd0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2020 17:33:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2020 17:33:49 -0400    

When a table is scanned by heapam_index_build_range_scan (née  
IndexBuildHeapScan) and the table lock being held allows concurrent data  
changes, it is possible for new HOT chains to sprout in a page that were  
unknown when the scan of a page happened.  This leads to an error such  
as  
  ERROR:  failed to find parent tuple for heap-only tuple at (X,Y) in table "tbl"  
because the root tuple was not present when we first obtained the list  
of the page's root tuples.  This can be fixed by re-obtaining the list  
of root tuples, if we see that a heap-only tuple appears to point to a  
non-existing root.  
  
This was reported by Anastasia as occurring for BRIN summarization  
(which exists since 9.5), but I think it could theoretically also happen  
with CREATE INDEX CONCURRENTLY (much older) or REINDEX CONCURRENTLY  
(very recent).  It seems a happy coincidence that BRIN forces us to  
backpatch this all the way to 9.5.  
  
Reported-by: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Diagnosed-by: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Co-authored-by: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/602d8487-f0b2-5486-0088-0f372b2549fa@postgrespro.ru  
Backpatch: 9.5 - master  

commit   : 8782ea2f36a2468e08c227c8d7907a5a1a9f5e32    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Aug 2020 15:33:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Aug 2020 15:33:36 -0400    

If a page range is desummarized at just the right time concurrently with  
an index walk, BRIN would raise an error indicating index corruption.  
This is scary and unhelpful; silently returning that the page range is  
not summarized is sufficient reaction.  
  
This bug was introduced by commit 975ad4e602ff as additional protection  
against a bug whose actual fix was elsewhere.  Backpatch equally.  
  
Reported-By: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Diagnosed-By: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/2588667e-d07d-7e10-74e2-7e1e46194491@postgrespro.ru  
Backpatch: 9.5 - master  

commit   : 1754a71986e806330ac3ab9e8125c902286b829d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 17:12:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 17:12:51 -0400    

commit   : b601f24c875d79e747eb8b50a4b1555ac22cf8f9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

Back-patch to v10, which introduced logical replication.  
  
Security: CVE-2020-14349  

commit   : 412c5c4010c0bec294f60a10cd56929680d3f95b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

This is like CVE-2018-1058 commit  
582edc369cdbd348d68441fc50fa26a84afd0c1a.  Today, a malicious user of a  
publisher or subscriber database can invoke arbitrary SQL functions  
under an identity running replication, often a superuser.  This fix may  
cause "does not exist" or "no schema has been selected to create in"  
errors in a replication process.  After upgrading, consider watching  
server logs for these errors.  Objects accruing schema qualification in  
the wake of the earlier commit are unlikely to need further correction.  
Back-patch to v10, which introduced logical replication.  
  
Security: CVE-2020-14349  

commit   : 41dae35532d40041297ee728eac1f4584af05570    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

Any libpq client can use the header.  Clients include backend components  
postgres_fdw, dblink, and logical replication apply worker.  Back-patch  
to v10, because another fix needs this.  In released branches, just copy  
the header and keep the original.  

commit   : 98ca64899cec6a4bf3099481aff43b8777319c41    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 10:44:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 10:44:42 -0400    

Hostile objects located within the installation-time search_path could  
capture references in an extension's installation or upgrade script.  
If the extension is being installed with superuser privileges, this  
opens the door to privilege escalation.  While such hazards have existed  
all along, their urgency increases with the v13 "trusted extensions"  
feature, because that lets a non-superuser control the installation path  
for a superuser-privileged script.  Therefore, make a number of changes  
to make such situations more secure:  
  
* Tweak the construction of the installation-time search_path to ensure  
that references to objects in pg_catalog can't be subverted; and  
explicitly add pg_temp to the end of the path to prevent attacks using  
temporary objects.  
  
* Disable check_function_bodies within installation/upgrade scripts,  
so that any security gaps in SQL-language or PL-language function bodies  
cannot create a risk of unwanted installation-time code execution.  
  
* Adjust lookup of type input/receive functions and join estimator  
functions to complain if there are multiple candidate functions.  This  
prevents capture of references to functions whose signature is not the  
first one checked; and it's arguably more user-friendly anyway.  
  
* Modify various contrib upgrade scripts to ensure that catalog  
modification queries are executed with secure search paths.  (These  
are in-place modifications with no extension version changes, since  
it is the update process itself that is at issue, not the end result.)  
  
Extensions that depend on other extensions cannot be made fully secure  
by these methods alone; therefore, revert the "trusted" marking that  
commit eb67623c9 applied to earthdistance and hstore_plperl, pending  
some better solution to that set of issues.  
  
Also add documentation around these issues, to help extension authors  
write secure installation scripts.  
  
Patch by me, following an observation by Andres Freund; thanks  
to Noah Misch for review.  
  
Security: CVE-2020-14350  

commit   : 378bd1ed6e4314a8b8b32c555f73524c2283b016    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2020 15:15:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2020 15:15:50 +0200    

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

commit   : bc635dd16388015c72e47a4b90c4c3ceecebb0cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 16:59:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 16:59:53 -0400    

commit   : dd63a71ebe3937e0ec965248513fb71e45ee0ec8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 12:39:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 12:39:08 -0400    

Coverity pointed out, not unreasonably, that we checked fseeko's  
result at every other call site but these.  Failure to seek in the  
temp file (note this is NOT pg_dump's output file) seems quite  
unlikely, and even if it did happen the file length cross-check  
further down would probably detect the problem.  Still, that's a  
poor excuse for not checking the result of a system call.  

commit   : 900429d0c03668ac474770c01ba5911b15025dfb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 8 Aug 2020 12:31:55 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 8 Aug 2020 12:31:55 -0400    

Ashutosh Bapat noticed that when logical walsender needs to wait for  
WAL, and it realizes that it must send a keepalive message to  
walreceiver to update the sent-LSN, which *does not* request a reply  
from walreceiver, it wrongly sets the flag that it's going to wait for  
that reply.  That means that any future would-be sender of feedback  
messages ends up not sending a feedback message, because they all  
believe that a reply is expected.  
  
With built-in logical replication there's not much harm in this, because  
WalReceiverMain will send a ping-back every wal_receiver_timeout/2  
anyway; but with other logical replication systems (e.g. pglogical) it  
can cause significant pain.  
  
This problem was introduced in commit 41d5f8ad734, where the  
request-reply flag was changed from true to false to WalSndKeepalive,  
without at the same time removing the line that sets  
waiting_for_ping_response.  
  
Just removing that line would be a sufficient fix, but it seems better  
to shift the responsibility of setting the flag to WalSndKeepalive  
itself instead of requiring caller to do it; this is clearly less  
error-prone.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>  
Backpatch: 9.5 and up  
Discussion: https://postgr.es/m/20200806225558.GA22401@alvherre.pgsql  

commit   : f1c3a41bd695c4ba97d50ffa4b2ab2a72068bd3b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 7 Aug 2020 20:38:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 7 Aug 2020 20:38:55 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 13 development.  
  
current through 79a3ab1e98d6b5952e29ad91e07c0e9fc777cc0b  

commit   : 79a3ab1e98d6b5952e29ad91e07c0e9fc777cc0b    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2020 14:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2020 14:45:01 +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   : be9bdab983cfc44db1d7f8c06df7d7a7cbcb8128    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 15:25:47 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 15:25:47 -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   : 05dfb813245bf3b896b5317570a24a3d66e97a41    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 7 Aug 2020 10:22:08 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 7 Aug 2020 10:22:08 +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   : d0aa57d0e9441b9fab5de5dbed0cb0afd4fa756d    
  
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   : c43a36fa8fff380072d9fc745b1e27baf1a4d3f8    
  
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   : 565f1690264b5773c23b86303645cf11a0893cff    
  
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   : 1a01595cc2ffb20ef9f2bc1a92d39728b65e3797    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Aug 2020 14:36:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Aug 2020 14:36:09 +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   : e7a6cd5dcf24c6d4b04d036a4837c7af154c4b49    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 Aug 2020 17:01:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 Aug 2020 17:01:42 -0400    

Document that hash_mem_multiplier can get query behavior closer to the  
pre-PG 13 behavior of allowing hashing to use more memory.  
  
Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-Wzn3kwQm_pe6g2=ki+P7+ZRqH5GvFGn6SWfv_j7UUgcLdQ@mail.gmail.com  
  
Backpatch-through: 13 only  

commit   : 72ca61101ad4076941f175b50cc86e6372023034    
  
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   : 6d78f219e8afc57b6ca3765eb2dfa1b8fe095ddc    
  
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   : 44cd434ec4a70d2dfbc460492fc0574d08440250    
  
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   : f5293fb09e7346bb663f2f5c63081e8aabe61a8e    
  
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   : 719304a3043d9f60247df371f55236058a7f3caa    
  
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   : 22c105595fc736ae94ce3b806da16b0bd8e94fb8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 2 Aug 2020 14:23:57 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 2 Aug 2020 14:23:57 +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   : 725b43b9c3b3c25c60ac717c41047ad0dffb1312    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 31 Jul 2020 15:34:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 31 Jul 2020 15:34:26 -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   : 5c439f189bf4bdbb0ff75b2043ca713d76019528    
  
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   : 11dce63d6c3f676a9f1829eca96f085b6d935af0    
  
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   : 0d9b64fe8d2d98f8f074334f86aaaedfb2b5a1e1    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 31 Jul 2020 07:46:25 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 31 Jul 2020 07:46:25 +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   : 07cbcdd00c2465a844513f14b7a96232013d3129    
  
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   : e710f3b8e7da43de2ad8113ce7c7933928092656    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 15:48:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 15:48:52 +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   : 78530c8e7a5abe0b646b0b46527f8799f831e1e1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Jul 2020 14:14:57 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Jul 2020 14:14:57 -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   : 3a232a3183d517743acf232794fadc07f0944220    
  
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   : cdd7bd695bed552936e86b70ff1d234360bc5bea    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 17:59:14 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 17:59:14 -0700    

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

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

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

commit   : e362f469c50f6e671285640cc2087345ab55a9b2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 16:58:59 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Jul 2020 16:58:59 -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   : a57c837e5cdf601d6ec05e5e10a40d01f1d2b84e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 29 Jul 2020 11:43:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 29 Jul 2020 11:43:11 +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   : dc6f2fb4353508af27dde44bdf5cb14749ae73a1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 28 Jul 2020 22:52:43 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 28 Jul 2020 22:52:43 +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   : 128fd0a65ae54d97896cb6409fbc56d5da6319f1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 28 Jul 2020 11:23:02 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 28 Jul 2020 11:23:02 +0900    

Commit f5dff45962 renamed wal_keep_segments to wal_keep_size.  
This commit adds the mention to this change in the release note.  
  
Author: Fujii Masao  
Reviewed-by: David Steele  
Discussion: https://postgr.es/m/dc4768f2-1eff-d2fc-35ba-6b2985b7cb6c@oss.nttdata.com  

commit   : cebe10a5f307635e187f424d0dce700666ae58fd    
  
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   : 5a6cc6ffa914775e0184207686c2216998126549    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 27 Jul 2020 17:53:17 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 27 Jul 2020 17:53:17 -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   : 0caf1fc6e86a8985ef8b881a4dbb3488381ff976    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 15:58:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 15:58:54 +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   : ed4a9dc9cf69eee06f4e655ef5d175c5efa87dd7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 10:29:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Jul 2020 10:29:08 +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   : 7f5f2249b27a46a4d91d6be5aff188ca67719fa7    
  
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   : 21b0055359f036e3ba22402d14536431dd39242e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Jul 2020 16:32:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Jul 2020 16:32:20 +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   : b15367ae39402eb4eb8736f9c38c607995c82bb2    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 Jul 2020 10:31:19 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 Jul 2020 10:31:19 +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   : 70eca6a9a6df679a86f30442194cc6b858b82000    
  
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   : 92fe6895d66da93a3c920089cfbbe4eb2db2145e    
  
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   : 7dab4569d19341720316d139141f1c867ef438bf    
  
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   : dbd03482c626e7c5bb92dde983c4b9de6f623253    
  
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   : 6b366190d54a2cfc57782e11c62f05899e17b6ae    
  
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   : 9f5162ef43c52396c4365b9cabfdffb4e4bf716d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jul 2020 08:29:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 Jul 2020 08:29:14 +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   : 35e142202b14fa12f8edbd7e58b33c39d3c03c62    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jul 2020 14:52:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Jul 2020 14:52:36 +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   : cc4dd2a7af13b4759cd76074a932c8cf24e32bb2    
  
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   : ac25e7b039d5eacb8eb8fcc856a7ba4f14136b50    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2020 13:08:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2020 13:08:16 -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   : bca409e5b160f81ccd980bef2aeb32f8b731b0fd    
  
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   : e5372b48b94f17dcce5d8f3b26d55b0f182e4306    
  
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   : 2f1f189cf8806a02987dfa1759257b154162fac2    
  
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   : f5dff45962ec0a0daad443e45811d6c426be1237    
  
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   : 4a1ae21750cbf23d8317d565c55ac7bce46bf0f6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jul 2020 07:54:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jul 2020 07:54:04 +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   : 914d2383ae91918b359311a90d23c0d5862781ac    
  
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   : f2b65519e17d6de4cd95dfe1570ab1aca187b24d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 22:43:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 22:43:41 +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   : 580d8ac9b1ef2803f39b1e23d9da68fff9109c42    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 10:42:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jul 2020 10:42:46 +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   : 71e8e66f783c143b04d381566d7a2a61e8d7598f    
  
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   : 447cf2f8e9dcf9fd89c935f2daee13326a91630a    
  
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   : 49eb96852b02069600a4f6997dfb388fc37a2778    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 09:50:46 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Jul 2020 09:50:46 -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   : a220e345c87d5224d810584a7c4ef29ea7a6c1f1    
  
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   : 6bab40bf605665fc01b84a434127cbaec3b3d1de    
  
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   : e7240ccecd3001892880fd076a7ffd107b533afc    
  
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   : 35647ea9d214c8745922cb757424f11d791ed733    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2020 08:43:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 17 Jul 2020 08:43:06 +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   : beebbb39d932289b73fa7cab4037895675615a8d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jul 2020 15:52:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jul 2020 15:52:54 +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   : 6b5ca893f737184a8113aee33c6c10b1c3bbcd39    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2020 21:01:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jul 2020 21:01:29 +0200    

commit   : 5f89bb4cf0109bdb36eb8f78943f5b0f141c614a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 15:17:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jul 2020 15:17:32 +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   : e38705b5c7635644a70cf7c9eadb7a90bb8ea13b    
  
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   : b827304291aff8019cdd0cee68219fe43f064380    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Jul 2020 16:57:41 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 14 Jul 2020 16:57:41 +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   : 9678c08184a82deafac9297b9af0fc5cb07ab347    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2020 13:17:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jul 2020 13:17:31 +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   : 0734dbc45034540fec1d98b15c9f173ad1d4af02    
  
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   : 794e8e32bb5ae1b38a90cbae2a88895633797599    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jul 2020 13:49:50 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jul 2020 13:49:50 -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   : 8e6f134a9a8db52cbd2818ce8a60b9e5cdadfc8f    
  
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   : ae290059e1aa5bc2272a0345184bcf05407f69a4    
  
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   : d8a7ce245095e3a70a2ad738c17be95593f68996    
  
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   : 926ecf83c0bab7e985eaf5727bb69cdf8ce6b067    
  
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   : b074813d48bcd2a7e224b56a3aff6db9df745237    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jul 2020 08:27:40 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jul 2020 08:27:40 +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   : bc9aaac1a188cac11b1ebb04047de3db71257785    
  
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   : 89a0b1a7ca0af36818ed7076c12ac00bcf4f007d    
  
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   : b9a04a9bc6653183ed23532145325694fbc46002    
  
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   : 763a0b63a25c13ac940ce2c64b37b8446ccbf895    
  
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   : 8ff4d1277b8660de85e4a7d796ccc1b64187d80f    
  
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   : c3a79e71929a6b5cdd2416ab4976dab59736c937    
  
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   : 17b87b3049fa7e3ddc68bf9daaffa3b01d7b8be2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2020 17:38:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2020 17:38:52 -0400    

Back-patch commits 91bdf499b and ffb4cee43, so that all branches  
agree on when and how to do Windows CRLF conversion.  
  
This should close the referenced thread.  Thanks to Andrew Dunstan  
for discussion/review.  
  
Discussion: https://postgr.es/m/412ae8da-76bb-640f-039a-f3513499e53d@gmx.net  

commit   : 601d419b2b5def62a1867169e67c7ef876f0b886    
  
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   : 331da659bedbad2c4d649d70cccf9d87ca1a0b7e    
  
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   : 285da44a69ddcbe8aa955b5f863e02121f41c189    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2020 10:07:00 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 9 Jul 2020 10:07:00 +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   : a2b94693beb1d052f2b4935384dd6f7f47143669    
  
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   : ea5737889f0586c2d46738bc52b97b86369f03e2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2020 10:42:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jul 2020 10:42:15 +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   : c54b5891f415df36809de1aeb97e4574d5456d69    
  
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   : da6b6ff95bcaadc109ab248471527a2511e853d5    
  
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   : e163f3a2b1d987f83e291e86969ed4a91ded6abb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:36:58 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:36:58 +0530    

Backpatch-through: 13, where it was introduced  

commit   : f92c24ec9f61b3502007e2a9a6de4c236844254d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:24:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Jul 2020 08:24:12 +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   : ffb23488af5e6776935c46370465dcc1704e7540    
  
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   : 45f165b18b72abb1e4579a3cca0862a4e5cb8b6b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Jul 2020 19:36:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Jul 2020 19:36:12 +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   : 94e454cddfbae5e32ae7bb70fedd24f243cd486a    
  
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   : c536da177cbbc9e30de17a0a445b53d79a5bbe7f    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 13:47:07 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 13:47:07 -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   : 0025c3a2c295459002711e0b37e48e3b067a83ba    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 06:28:21 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 4 Jul 2020 06:28:21 -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   : 9233624b128b41fd410712a7223821878f1943b0    
  
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   : cfe89f5e6b7874e89dac7d9511b1894a7d033870    
  
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   : 1d94c3965450417ebb0e0fd73ea636df823feeed    
  
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   : 95a604eaebd145729d9f8c936b37703a212f27fd    
  
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   : 8d459762b10372e48845a49b305f4e1e165fe173    
  
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   : 83fa48c8cd26c9a8171a85e786bb6ae1c5b04139    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Jul 2020 08:06:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Jul 2020 08:06:00 +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   : 48d50ee9aff9be0817a175418e100b7d7fa55a0f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 10:47:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Jul 2020 10:47:29 +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   : d73e9a57bf5bd977d9bf36bc07c77a1acf45e35b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 1 Jul 2020 12:16:42 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 1 Jul 2020 12:16:42 +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   : 70dc45e8cb76e0c612648ccefc433b7fb2b16c2b    
  
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   : 0bddb3a95995008ed116858ddde9a89e01659dae    
  
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   : c7ff80ffaa933d26298ce2d4eb7bd90d56c16668    
  
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   : 21aac2ff96e37c75cc6814b86d4b55172090413c    
  
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   : b86be844a40c439e44ea6fc974df37b7c2c9c832    
  
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   : e5f63db995514473f7b3421bc80f8e7715cd6d35    
  
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   : e2bcd99be18c67fea575a9789ebafd650e6e1076    
  
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   : 16412c78403e8ebcb06e34ac1eb74ff8dd299495    
  
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   : 3b4b541777f0b85df7626623ef78df0ea48ca5dc    
  
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   : 1f601b14e3a7c5ca035cfb59575462004a8c3125    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 26 Jun 2020 18:24:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 26 Jun 2020 18:24:12 -0400    

Clarify --include-foreign-data option addition.  
  
Reported-by:  Masahiko Sawada, Alvaro Herrera  
  
Discussion: https://postgr.es/m/CA+fd4k62hYtce8VrEMGm6Y+1c24QBgCksXvOaH5kE8PbY+68sA@mail.gmail.com  
  
Backpatch-through: 13 only  

commit   : 098868b57687ef9c5e3cd9dff469594c6a1c6d10    
  
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   : 08671057e025b48136d4eed5477f287ffce217b0    
  
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   : 563ed36d5b4819066e13f5272bf1a02cf5dac0bf    
  
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   : 8c2010f12344ed8834c6f63406a78e5843ebec69    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 25 Jun 2020 10:55:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 25 Jun 2020 10:55:26 -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   : 185c6bc4aef1201b7d0f2c4e9c8893c4a663dfd4    
  
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   : 126c8fcec790652dd0cb755fdeedf2c02c8d8079    
  
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   : 086bef8ac8b3635e7af94ac41e92dfc016b87e90    
  
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   : 6f7a862bed3a49283c74c0adf207172002e3e03c    
  
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   : 12e52ba5a76e56aacdfbbb269e6b45c53d80c477    
  
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   : 411493d701e2f97e778dc1ff14fb7169eea2e94c    
  
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   : bc4d7817e0cbd26998ebaa682772bf6bc579c302    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jun 2020 17:16:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jun 2020 17:16:25 -0400    

commit   : d33f33539d7f90d024a1dcb73b74c15b07349be8    
  
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   : 57f8b9913b912f2bdfe24b73d44b9713e328ee2e    
  
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   : 793e5ad3cb7f8a8345881c7057618228546de3c6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jun 2020 14:08:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jun 2020 14:08:30 +0200    

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

commit   : 70004a2a0c52e05f4aa67541fb165715a3981204    
  
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   : f7e4989d1c65c376ca4aba2d39dc81cd1eaefe67    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jun 2020 17:34:06 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jun 2020 17:34:06 -0700    

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

commit   : b56d91ebd2bef20f9adbcc61c1279083a91bdf3e    
  
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   : 39aafc88c4b4ac281df8b2c2b8be72d4e4d99e9f    
  
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   : e6c6f427e356e3706ce2f0ae7e7e94e5501bbc13    
  
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   : e74559c9763049ff4d3edd26817bad58c13113a1    
  
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   : 577dcf890cdb2621cf21ded1a2b6c96c40441f3d    
  
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   : 91a890bd7fef1cd8bfe3c8832eea114290f16b02    
  
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   : dedb92d4a3adc6b5165a619383739ab05d24b24d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 19 Jun 2020 08:57:23 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 19 Jun 2020 08:57:23 -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   : 08aa3151e7308556130c644c237fa4b20dfd6eba    
  
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   : bdee4af8e07648008fe522fc5a562db453be5ad7    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 19 Jun 2020 17:25:07 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 19 Jun 2020 17:25:07 +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   : 5fffa8fce37b981e1a5bb79affce9a856e021265    
  
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   : 59225dcefef278415aef64c3b96f84616b95661e    
  
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   : c10dc2d11791cc18ceea78caa94eb4b651090259    
  
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   : 43e70addf5a65f1b99c286f82e2e4970b0c2fda7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2020 16:35:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jun 2020 16:35:29 +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   : f2236d087eb8df9f15c016c02c92aa2bed7c2889    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 18 Jun 2020 03:22:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 18 Jun 2020 03:22:26 +0200    

commit   : 484a57643e02b7df2bb9085603772b33511c6668    
  
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   : 6b296102920323f360d53457ecda5179284cca8c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 17 Jun 2020 15:23:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 17 Jun 2020 15:23:54 -0700    

Oversight in commit 0d861bbb.  

commit   : 276bdc93924afb2bd793627f49a9e7edd4172b63    
  
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   : 09bff91b316e90bf7f523593c1e8000c772cbe52    
  
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   : 7f932f77c7eb068772355c76cfa48bc5d0260e2f    
  
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   : 9c25a873d631036a92036394863eba1f4a3f3cd5    
  
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   : 3e0b08c404b2a7d799db78eb942a01534ac7926b    
  
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   : a2c72851a898170ee1f2e7c21c1bf9086dec2d5c    
  
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   : 4701efa9f741aa0ca38cfe922dfcaef1749b5b02    
  
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   : 33dd9bb3b0a88981f18a10d89720b4e40d8876ba    
  
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   : e745bcc00149fe3c35ba1123800e0beb948e3678    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 13 Jun 2020 09:33:31 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 13 Jun 2020 09:33:31 -0700    

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

commit   : 095f2d95c92704747d84d499a33b527af42bb08e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 13 Jun 2020 11:28:12 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 13 Jun 2020 11:28:12 +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   : 44eff28410598ef86d3d8bd812439aabf19f7ee0    
  
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   : db680fd82ede99d9a5224a1d316a64d763be1acc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:27:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:27:59 -0400    

xreflabels were removed in a previous commit  
  
Discussion: https://postgr.es/m/8315c0ca-7758-8823-fcb6-f37f9413e6b6@2ndquadrant.com  
  
Backpatch-through: 13 only  

commit   : c04612040165582f60cbcfe8ca1771598c9f3a05    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:25:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2020 18:25:46 -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   : 6fbfa4eb244eab47d67fba4258c4af777729f119    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 11 Jun 2020 14:44:31 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 11 Jun 2020 14:44:31 -0700    

Reported-by: Peter Geoghegan  

commit   : ee788ba99011c9d1e8f6f352acc0b0d19350fff6    
  
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   : 13e0fa7ae50cd0e91158877dba37098492b234e8    
  
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   : 6df7105e5d50460623421d00f24aaa46b66fa570    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 11 Jun 2020 10:09:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 11 Jun 2020 10:09:45 -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   : c4d5706db298f5a02ffd321c4605a7f8746b5428    
  
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   : 8d8b89266ca0328d78df319bacd1e809631f2acc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2020 15:48:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2020 15:48:56 +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   : d6d3f8bc8433f00a43eaf936e75c757bfd743702    
  
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   : 16a8d5cf0337724affc4bbb3e8ba07f748f00898    
  
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   : a5202889b4c78e8ffcdd8be35d59f0a7aa644f64    
  
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   : 4d655f154565662cbd11f1ce5c0e6a90cd6a8f56    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 9 Jun 2020 18:43:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 9 Jun 2020 18:43:58 +1200    

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

commit   : 6df8fb391b0b98efc917b5cc43de77cba785864a    
  
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   : 2174d40117f62099c7b11a2d43d163b7b9271d39    
  
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   : de4a25989611d960360d0513d00b970d3b6c52c7    
  
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   : acefa2cca6a2c2b9c0fd9f25d0c003595bed689e    
  
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   : a1c940cc58828b81cd72e04dd264fbc65e46f0de    
  
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   : 10ffe0fa72ed895a3c18aef2d3950b480e810e13    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2020 10:12:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2020 10:12:31 +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   : 9b5f85fb0a3e27040bc72451893d2dc35bb5d8bd    
  
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   : 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